Fix ttl
and related current time logic
#1528
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
One Line Summary
Add
ttl
andsentTime
(andsmallIcon
) to an OSNotification constructor and change usages ofcurrentThreadTimeMillis
(time thread has been active) tocurrentTimeMillis
(epoch time) instead.Details
Motivation
This PR is related to some features of #1479.
The
protected OSNotification(OSNotification notification)
constructor was missingttl
andsentTime
so that when the NSE is used along with the foreground handler, and the NSE passes on amutableCopy()
, the notification that is processed by the foreground handler next hasttl
andsentTime
missing, and thus defaulted to0
, which ends up not displaying due toisNotificationWithinTTL()
check returningfalse
erroneously.Unrelated, but
smallIcon
was also missing so I added it as well.While making the above changes, I noticed that the
currentTimeInSeconds
forisNotificationWithinTTL()
would be close to zero. When we checkisNotificationWithinTTL()
to determine if we should display it, we should usecurrentTimeMillis
(milliseconds since epoch) instead ofcurrentThreadTimeMillis
(the time a thread has been active) to determine the current time that will be used in the logic. Note that thegoogle.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 whengoogle.sent_time
was not in the payload.Testing
Unit testing
Added test
testNotificationProcessingAndForegroundHandler_callCompleteWithMutableNotification_displays()
and handlerRemoteNotificationReceivedHandler_notificationReceivedCallCompleteWithMutableNotification
. The test NSE callscomplete()
with amutableCopy()
of the notification that is used by the foreground handler later. We test that the notification will display.The two tests
notShowNotificationPastTTL
andshouldSetExpireTimeCorrectlyWhenMissingFromPayload
are now failing because they were using thread time. I modified these to use current non-thread time and they now 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
andcurrentTimeInSeconds
throughout testing.Affected code checklist
Checklist
Overview
Testing
Final pass
This change is