Fixes for pre-6 androids

[aurimasc]

Three fixes for Android:

• case 1423875 - unguarded call of API added in Android 6 (M)
• notification status reporting for pre-6 (previously unimplemented at all)
• removal of cached notifications, introduced in previous release

In Android 6 an API was introduced to query for notifications, displayed in status bar. This PR implements our own tracking for older versions by putting an ID into set and setting an intent to be invoked on deletion. Not adding this for 6 and later (makes code more complex, but saves resources and will be simpler to remove once we drop support for Android 6 some day, also, querying Androids status bar gives more reliable data than our own tracking). Implementation of our own tracking of sent notifications allowed to also implement notification status check, that previously only worked on 6 and later. In previous release the caching of scheduled notifications was introduced, but notifications are kept in it forever (unless you kill the app). This PR adds removal for them in the housekeeping (also required thread synchronization to be added, since scheduling and housekeeping happens on different threads).

QA request:

• In-package test project has new button in "Modify" section to cancel the notification. Works with explicit ID notification, cancels only that single notification. Internally this also triggers housekeeping, where the Android 6 API was called.
• Need testing:
  • Actual device with Android lower than 6 (I don't have one at hand); I tested the code by commenting out Android version checks, but that's not the same.
  • AndroidNotificationCenter.CheckScheduledNotificationStatus() should work for pre-6 (documentation for it still needs update about it); Q: maybe I should add a button for that in test project?
  • Scheduling and cancelling drills should trigger all relevant code paths, so we know both 6+ and older androids work
  • If you have a notification in status bar, pressing it should launch the app and AndroidNotificationCenter.GetLastNotificationIntent should give it to you, regardless of whether you have app in foreground, background or killed before notification arrived or after it arrived.
  • Only basic sending & canceling is affected, no need to test all those fancy variants of notifications
  • Tested on Samsung Galaxy S7 (7.0); in reality this isn't device specific and Android version only matters whether it's <6 or 6+.

[aurimasc]

Looks fine. I am wondering though, what if you would have a project/test which would have Target SDK set to 23, would it possible to then cover your Android 6 code ?

Has nothing to do with Target SDK. It's the actual Android version on the device that matters (and what those checks are checking).

[vaidasma]

Verified: • Checked wheter pending / shown notifications can be cancelled • Checked whether several different notification types are able to be schedulled and received • Checked whether Notification application is brought back to foreground when clicking on received notification, regardless of the current status of the app • Checked whether explict notifications can be received / modified / cancelled / promptet for status via CheckScheduledNotificationStatus()

Tested on devices: • VLNQA00140 - Samsung Galaxy S4 (GT-I9505), CPU: Snapdragon S4 Plus MSM8960, GPU: Adreno 320, OS: 5.0.1 • VLNQA00011 - Xiaomi Mi 5s (MI 5s), CPU: Snapdragon 820 MSM8996, GPU: Adreno 530, OS: 6.0.1 (device had specific to it issues where arrived Notifications disappear if the app is closed, seems unrelated to any Notifications Package releases)

Sanity testing on higher Android just in case something got broken: • VLNQA00267 - Samsung Galaxy S10+ (SM-G975F), CPU: Exynos 9 9820, GPU: Mali-G76, OS: 11

Also added button for checking Scheduled Notification Status