Notifications are firing but each one says "8:45am" in its time

[fetching]

I set my phone to April 8 at different times in the morning in order to see if Notifications would fire. I am seeing the notifications fire but the time the notifications quotes in the system UI says 8:45am for all of them. I think changing my phone clock is a legitimate test since travelers from other time zones will likely do the same?

Here are two examples:

1. This one you can see my phone clock is 10:55am and the notification text says "Destination navigation..." which does start at 11:00am. So the firing time of the notification is correct. However, notice that it says "Droidcon Boston 8:45am"

2. This one shows "Grab your lunch" at 11:51am where lunch is in 9 minutes at 12 noon. But the notification again refers to 8:45am:

[fetching]

Maybe it can be something goofy from me changing my phone time? It was 12:52pm and I set my clock to 1:48pm and these notifications fired. They all say 12:51pm.

I will try to set my clock again tomorrow and let notifications occur over time to see what time they say.

[CCorrado]

I think the notifications are all push notifications, and they get sent in batches when the device becomes "available". If we were scheduling Alarms via AlarmManager, i think it would show the times at which the alarm was scheduled for...but since its push, they will get sent from Firebase when the device is available at a time after the notification was scheduled for.

[fetching]

@CCorrado here is the experiment that I did last night and what I observed for notifications. Do you think the setup is legit?

1. Installed the build on my tablet. (I installed before the very latest build came out last night)

2. Tap and all talks from Day 1 so that I'll get notified before they start

3. Go to Settings->General Management->Date and Time and disable Automatic Date and Time so that the tablet won't inherit the date and time from anywhere 3a. Time zone is set to GMT-04:00 Eastern Daylight Time which should be correct for this timeframe

4. Set Date to April 8

5. Set Time to 9:30am

6. Restart the tablet

7. Start our app

8. Let the tablet idle to see what kinds of notifications I get.

9. At 9:32am (probably my tablet restarted at this time) I get notified about Community Addiction which is at 9:45 and at 9:40am I get notified for the one talk at 10am and the two talks at 11am:

10. I left the tablet running overnight, emulating the day of April 8, and waited to see what notifications came in over the next 8 hours.

11. I had 19 notifications in all which is great since that's all the sessions. Expanding the stack of notifications I can see the latest ones:

a. At 2:54pm I am notified for the 3:30pm, 4:00pm, 4:30pm and 5:00pm sessions

b. At 2:08pm I am notified for two 3:00pm talks and another 4pm talk (but this 4pm talk might have a bug and be tagged for 3pm). So all pretty good.

12. I opened a bunch of notifications so that I could expand the earlier ones in the stack.

a. At 12:57pm I'm notified for a 1:30pm and two talks at 2pm b. At 12:09pm I'm notified for two 1pm talks. c. At 11:52am I'm notified for the 12:15pm. So that's good. d. At 10:55am I'm notified for the 12pm lunch. A little less good.

[kenyee]

what OS version does the tablet have? That's pretty bizarre behavior...the notifications use the alarm manager and the event ID which is unique (it's the firebase ID)

[kenyee]

It'd also help if you did this "adb shell dumpsys alarm" it dumps all the alarms that are pending and how far away each one is. I can try replicating this later when I get home...

Some versions will also batch notifications, though the alarm manager is supposed to be immune to this behavior....

[fetching]

@kenyee my tablet is running Android v7.1.1. I will deploy the app and run the ads command tomorrow and see what it says.

[CCorrado]

Sorry, this has been a hectic week for me. I've had a lot of weird experiences with AlarmManager... It depends on how notifications are actually scheduled... With Nougat Google changed the behavior of AlarmManager a little bit. I wrote a little library internally (I haven't open sourced it.... yet) to handle local notifications. Its also still in Java...its one of those things we wrote once and it works for our needs. I'll make it a 2019 goal to polish it up :)

This is how we schedule stuff.

private static void scheduleAlerts(Context context, List<Reminder> reminders, DateTime when) {
        //Only schedule the alert if the filtered reminder to set is active.
        if (reminders != null && !reminders.isEmpty() && reminders.get(0).isActive() && when != null) {
            Log.d(TAG, "Scheduling alarm for " + DateUtil.formatDateAtTime(context, when));
            AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
            Intent intent = new Intent(context, AlarmManagerUtil.class);
            intent.setAction(AlarmManagerUtil.SET_NOTIFICATION_INTENT);
            saveReminderToPrefs(context, when.getMillis(), reminders);
            PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
            if (alarmManager != null) {
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
                    //We want to send offline reminders even in Doze mode.
                    alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, when.getMillis(), pendingIntent);
                } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
                    alarmManager.setExact(AlarmManager.RTC_WAKEUP, when.getMillis(), pendingIntent);
                } else {
                    alarmManager.set(AlarmManager.RTC_WAKEUP, when.getMillis(), pendingIntent);
                }
            }
        }
    }

It really does depend on how and when the notifications get scheduled. Time traveling, in my experience, has been ineffective to test the true experience. It is very valid when considering IF/WHEN the notifications fire. So as long as the notifications are getting dumped into your tray after time traveling, I think that is a valid pass.

[fetching]

Hey @CCorrado thanks for this update and bonus code. 💯 @kenyee and I were discussing that I "favorited" the sessions prior to changing the clock and that will account for weird behavior. I agree time traveling is not sufficient or at least has to be careful in its flow. I think we can close this as I obviously do get the notifications in my tray.