Fix ttl and related current time logic

[nan-li]

Description

One Line Summary

Add ttl and sentTime (and smallIcon) to an OSNotification constructor and change usages of currentThreadTimeMillis (time thread has been active) to currentTimeMillis (epoch time) instead.

Details

Motivation

This PR is related to some features of #1479.

The protected OSNotification(OSNotification notification) constructor was missing ttl and sentTime so that when the NSE is used along with the foreground handler, and the NSE passes on a mutableCopy(), the notification that is processed by the foreground handler next has ttl and sentTime missing, and thus defaulted to 0, which ends up not displaying due to isNotificationWithinTTL() check returning false erroneously.

Unrelated, but smallIcon was also missing so I added it as well.

While making the above changes, I noticed that the currentTimeInSeconds for isNotificationWithinTTL() would be close to zero. When we check isNotificationWithinTTL() to determine if we should display it, we should use currentTimeMillis (milliseconds since epoch) instead of currentThreadTimeMillis (the time a thread has been active) to determine the current time that will be used in the logic. Note that the google.sent_time is also in milliseconds since epoch.

While working on this, I looked at other places that used thread time inaccurately and changed to using currentTimeMillis instead.

Scope

I think using currentThreadTimeMillis was not a problem in the past because it was only the backup value when google.sent_time was not in the payload.

Testing

Unit testing

Added test testNotificationProcessingAndForegroundHandler_callCompleteWithMutableNotification_displays() and handler RemoteNotificationReceivedHandler_notificationReceivedCallCompleteWithMutableNotification. The test NSE calls complete() with a mutableCopy() of the notification that is used by the foreground handler later. We test that the notification will display.

The two tests notShowNotificationPastTTL and shouldSetExpireTimeCorrectlyWhenMissingFromPayload are now failing because they were using thread time. I modified these to use current non-thread time and they now pass.

• All unit tests pass

Manual testing

Tested using Android emulator Pixel 5 on API 30 with the demo app in the SDK. Sent notification to the device in the foreground and it didn't display before. Now it displays. Also regularly checked values of sentTime, ttl and currentTimeInSeconds throughout testing.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

---

This change is 

[jkasten2]

Code changes look good to me! Made one comment on a test improvement, feel free to make the fix and merge without another approval.

Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @nan-li)

---

OneSignalSDK/unittest/src/test/java/com/test/onesignal/GenerateNotificationRunner.java, line 1990 at r1 (raw file):

   public void testNotificationProcessingAndForegroundHandler_callCompleteWithMutableNotification_displays() throws Exception {
      // 1. Setup correct notification extension service class
      startRemoteNotificationReceivedHandlerService("com.test.onesignal.GenerateNotificationRunner$" +

Recommend using a hard reference to this class so if any code refactor is done in the future this will be a compile error instead of a failed test.

startRemoteNotificationReceivedHandlerService(RemoteNotificationReceivedHandler_notificationReceivedCallCompleteWithMutableNotification.getClass().getCanonicalName());