No push notifications while locked, arrive instantly after unlock

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

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.