No push notifications while locked, arrive instantly after unlock

anhedonia

Hello,

I'm trying to diagnose an issue on my Pixel 7 where notifications for Gmail, Discord, etc. are seemingly not arriving at all while the phone is locked and has been stationary for a few minutes. They appear almost immediately AFTER I unlock the phone. I've missed notifications that were over an hour old due to this. I've run a specific test and captured logs that seem to pinpoint the behavior, and I'm hoping someone has insights.

19:47:30: I locked the phone and placed it on a desk. The logs show the device beginning to enter a sleep state.

I PowerManagerService: Going to sleep due to power_button...
I device_idle: [state=1,reason=no activity]

By 19:50:10, before the email was sent, the logs confirm the device had entered a deeper idle state because it was stationary.

I device_idle: [state=5,reason=s:stationary]

19:51:00: I sent an email to my Gmail account from my PC. The phone remained locked and untouched. No notification arrived.

At 19:51:01, while the phone was locked and the notification was still undelivered, the logs show GCM heartbeat activity (happened before at 19:49:31 too, about 90s earlier, but this was the last one observed during the test)

09-09 19:51:01.956  2787 12154 I AlarmManager: setExactAndAllowWhileIdle [name: GCM_HB_ALARM type: 2 triggerAtMillis: 2560494]
09-09 19:51:01.980  2787 11889 I c2dm    : [packet_type=-7,,stream_id=10,last_stream_id=7]

19:53:00: After waiting two minutes, I tapped the screen to wake it, but did not unlock it. The lock screen was visible. I repeatedly woke the screen this way for a full minute. The notification for the email did not appear.

19:54:00: I unlocked the screen with my fingerprint. The logs show the device exiting its idle state because of the unlock.

I device_idle: [state=0,reason=unlocked]

At 19:54:01.169, GmsCompat requests to start a service for Gmail:

D TempServiceBinding:6: create: pkgName com.google.android.gm, duration: 20000, reason: normal-prio FCM, reasonCode: PUSH_MESSAGING_DEFERRABLE

The system immediately unfreezes the Gmail process:

19:54:01.180 I am_unfreeze: [Pid=6825,Process Name=com.google.android.gm,6]

19:54:03: Approximately 3 seconds after unlocking, the phone vibrated and the notification banner for the email sent at 19:51:00 appeared.

I notification_alert: [key=0|com.google.android.gm...buzz=1,beep=0,blink=0...]

There is no logged activity related to the incoming notification between the time it was sent (19:51:00) and the moment the phone was unlocked (19:54:00). The entire process for handling and displaying the notification appears to begin only after the device is unlocked.

I have already tried:

setting unrestricted battery for all relevant apps,
disabling private DNS,
testing on both Wi-Fi and LTE.

To see if it was an issue with my setup, I also created a new user profile (new Google account and only Google Play Services, Google Play and Gmail installed) and was able to observe the same behavior, which meanns it might not be specific to my main profile's configuration.

I'm posting these specific details in case anyone has seen this before or can offer an interpretation of this behavior.

Thanks for reading.

pxlkng

anhedonia setting unrestricted battery for all relevant apps

Only Play Services needs unrestricted battery to deliver FCM push notifications, not the apps which receive them, they'll be woken up by Play Services.

user20583982

I've had the exact same issue with other apps. For instance, I've been using medicine tracking app and thought it would deliver notification when I need to take meds. Unfortunately, it delivers notifications only after I unlock the device. The app is offline, so it shouldn't be due to push notification stuff. I don't really like it to always run in the background but probably it's the only solution. Or are there any advice how this can be fixed?

user20583982

pxlkng That's been my understanding about the workings of push notification. However, I don't really understand how notification delivery works for offline/local apps. This has been the problem for me at least.

anhedonia

pxlkng

pxlkng Only Play Services needs unrestricted battery to deliver FCM push notifications, not the apps which receive them, they'll be woken up by Play Services.

Sorry, I should've been more specific. One of the first things I did was set Play Services to unrestricted, when that didn't resolve the issue, I set it for other apps as well in hopes of getting it to work, to no avail.

pxlkng

More information:
https://grapheneos.org/usage#sandboxed-google-play-installation

pxlkng

user20583982

FCM is Googles push notification mechanism and requires network. Apps can have their own push implementations.

In the case of your offline app, it probably needs unrestricted itself due to being offline/local and likely just scheduling the notifications itself.

anhedonia

Just to follow up on this, I've confirmed that all notifications come through immediately while the phone is charging.

This pretty much proves it's happening when the phone goes into a deep sleep state when it's idle on battery. I've already set Play Services and my apps to "Unrestricted" battery, which I thought was supposed to solve this. It feels like a fundamental feature of a smartphone is broken if I'm missing messages from WhatsApp, Discord, etc., simply because my phone has been sitting on a desk. This is a potential deal-breaker for me.

Is this aggressive battery saving just the expected behavior on GrapheneOS, or is something not working right?

ron

anhedonia This ist not the expected behaviour. I recieve all the notifications, no matter if the phone is charging or not.

ron

anhedonia might be a stupid question, but I'll ask anyways:
Did you reboot your phone yet?
Do Google play services have unrestricted battery and network + sensors permission?

In addition to that, Google play services have to be installed before the other apps get installed.

pxlkng

anhedonia Is this aggressive battery saving just the expected behavior on GrapheneOS, or is something not working right?

GrapheneOS inherits battery management from AOSP, which usually is known to be among the easiest/least aggressive ones.
If an app is set to unrestricted battery, the battery manager should just leave it alone.

The issue is likely something else.

pxlkng

ron sensors permission

Sensors permission is not required for FCM to work. Play Services and Play Store don't need Sensors.
I recommend against granting Sensors.

anhedonia

Thanks to everyone for getting involved in this discussion.

I've collected some more data. After installing ntfy for better control of FCM, I can confirm that High and Max priority notifications work fine while in Doze, while Normal or lower priority exhibits this same behavior.

I also realized that i had microG Services installed (to use Revanced Youtube), and thought it might've been conflicting with how Play Services handles notifications in some way. I uninstalled it, cleared storage for Google Play Services, Play Store, uninstalled Gmail, then rebooted my phone, logged back into my accounts and reinstalled Gmail from Play Store. Now I'm not getting notifications at all from Gmail anymore.

It feels I've left my phone in this dirty state and the only way to really isolate the issue is to perform a factory reset. It sucks, but I don't know what else to do. I will report back with results when I have time to do this.

Meanwhile, can anyone confirm that Normal priority notifications get pushed immediately (or close to it) while the device is left discharging and stationary for several minutes (in Doze)? Or is it only supposed to happen during the normal Doze maintenance windows?

From Android's official docs:

For messages that don't result in notifications, such as keeping app content up to date in the background or initiating data syncs, use normal priority FCM messages. Normal priority messages are delivered immediately if the device isn't in Doze. If the device is in Doze mode, they are delivered during the periodic Doze maintenance windows or as soon as the user wakes the device.

It seems this lines up with what I've been seeing on GrapheneOS, but I haven't observed this on other Android devices I've used. Even if they're supposed to be delivered during maintenance windows, I don't think that explains why I've been seeing 1h+ old notifications delivered only when I've unlocked the phone. I wonder if these windows get so infrequent for this to happen, or if the way maintenance works is broken on my setup.

Either way, this seems wrong. A phone should be able to notify me when something happens, not wait until I explicitly unlock it.

anhedonia

anhedonia I wonder if these windows get so infrequent for this to happen

Turns out, yes.

After running adb shell dumpsys deviceidle:

Settings:
    ...
    idle_to=+1h0m0s0ms
    max_idle_to=+6h0m0s0ms
    idle_factor=2.0
    ...
    wait_for_unlock=true
  Idling history:
      deep-idle: -1h32m7s212ms
     deep-maint: -32m6s610ms
      deep-idle: -31m36s547ms

The system's default constants confirm this behavior is intentional, and the idling history shows it's true.

idle_to=+1h0m0s0ms: the first maintenance window only happens an HOUR after entering deep Doze.
idle_factor=2.0: after the first window, it uses an exponential backoff, doubling the wait time for each subsequent window (1 hr, then 2 hrs, then 4 hrs) up to the max_idle_to limit (6 hours, in this case. You can be oblivious to a notification for 6 whole hours.)
wait_for_unlock=true: this explains my initial test. The phone does not leave doze just because the screen woke up, it waits for a full unlock.

Based on this, I've confirmed that forcing more frequent maintenance windows with adb does work as a solution for getting Normal priority notifications in a timely manner. I used the following command to set a fixed 5-minute interval (will have to do battery life testing and further tuning for this, also maybe disable wait_for_unlock):
adb shell settings put global device_idle_constants idle_to=300000,max_idle_to=300000,min_time_to_alarm=300000

The obvious downside is impact on standby battery life from forcing the radio to wake up more often, and the fact that this setting resets on reboot.

This feels like a heavy-handed workaround for a problem that stems from apps like Gmail using Normal priority FCM for what are clearly user-facing notifications. Forcing the entire system to wake up frequently is inefficient.

It would be nice if you could just make the system treat Normal priority messages as High priority for select apps. That would solve the problem efficiently, using the network's paging system as intended, without the battery penalty of constant, device-initiated wake-ups. Unfortunately, this is controlled by app developers and Google, I don't think this is something the OS can override.

This is my current understanding based on the evidence, but I'm open to correction if a factory reset or future findings reveal something new.