IssueTracker

Information redacted by Android Beta Feedback.

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Please upgrade to the latest release from the link V-QPR.If the issue still persists, please capture the new bug report along with the screen record or screen shot and share it here.

Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Thanks for reporting this issue.

1. We are handling "No more paying via Wallet because the system is not up to date" wallet issue here.

2. Please file a separate ticket for "Upgrade was never offered to install android 16" with details.

This is happening to my company's app consistently on a broad scale, and via our analytics we can tell that it specifically happens with users who have upgraded to Android 15, and they didn't have problems before. The issues is as follows for our messaging app:

1. User receives a FCM data push notification
2. App wakes up and begins to do work
3. We attempt to make a network call to fetch message data
4. Our networking library reports an error of operation not permitted
5. The user receives no notification for their message, because despite retries, the OS doesn't let us have network access in the background
6. The user gets mad, files a support ticket, and leaves us a bad review on the Play Store

This type of aggressive optimization is observable even in a simple test - our app operates via a "long polling" scheme, where we leave a network request open for 20 to 30 seconds to receive information. We have a loop that runs this request while the app is foregrounded. On Android versions prior to 15, our loop could run when the app was backgrounded, and be eventually stopped by the OS when the app was killed or slept in the background with no activity. However, on Android 15:

1. User has app open and is interacting with app
2. User backgrounds the app
3. We can observe in logs that our ability to interact with the network is immediately revoked - the moment the app is background our network request loop fails with operation not permitted reported

Now, we've done our best to make changes and be responsible with the user's app and battery in this backgrounding case, and respect limitations imposed by the OS. Note, all of the above happens on high end, Pixel & Samsung devices.

However, despite our best efforts, there isn't anything we can do to fix the missing notifications case. This is a P0 for a messaging app, so I am begging anyone at Google to take this report seriously. We can't reliably reproduce the notification problem, so I don't know if my own bug report would be helpful, but I'm more than happy to share graphs of our analytics showing this happening specifically upon broader adoption of Android 15 for thousands of users.

Devices entering Doze mode is known to cause delays in FCM push notifications for messages with Normal Priority, and it is expected and intended by FCM per doze-standby doc. If the messages should be delivered immediately instead of being delayed in doze mode, the app developer should send the messages as High Priority. The doc also mentioned how to partially exempt apps from Doze and App Standby optimizations.

Hi @si....

For comment #8, the delay seems to be caused by doze mode as explained above, because you received message as soon as you woke up the device, which is when device exited doze mode.

Hi @jo...

For comment #9, we need more information such as a bug report.

Hi @las..

For comment #10, it looks like the app developer needs to keep network alive for their periodic polling.

As explained, doze mode will cause delays in delivery delays for normal priority messages.

Please try a scenario by sending Mail to your device and immediately capture a bug report and share it here?

What

More information

Bug report right after sending an email to myself

When

Time and frequency

Time when bug report was triggered: Jan 7, 2025 12:48 PM GMT-05:00

Where

Build and device data

- Build Number: google/shiba_beta/shiba:15/BP11.241121.010/12780007:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
- SoC Revision: Zuma B1

Debugging information
Google Play services
com.google.android.gms
Version 244933035 (24.49.33 (260400-705592033))
System App (Updated)

Android System WebView
com.google.android.webview
Version 677813533 (131.0.6778.135)
System App (Updated)

Network operator: T-Mobile
SIM operator: T-Mobile

Filed by Android Beta Feedback. Version (Updated): 2.46-betterbug.external_20241023_RC01 (DOGFOOD)
To learn more about our feedback process, please visit https://developer.android.com/preview/feedback#feedback-app.

Information redacted by Android Beta Feedback.

Thanks for the response.

Hey @pu...

Regarding comment #10 / comment #11 - I am the app developer.

A few notes:

• We are using FCM high priority messages
• We log the priority metadata (priority and originalPriority) and validate that our messages are always high priority

But, most importantly,

• There is never a delay receiving FCM messages

FCM messages always work as designed, and we get them promptly. The issue is that the device behaves as if it does not have internet access. The app is behaving as if the "Background data" setting is turned off, when it is on.

I'm specifically making noise about this issue because nothing changed in our code to cause this issue -> we have specifically seen user reports & failure analyytics increase tenfold after a broader public rollout of Android 15. We're eager to comply with whatever changes may need to be made on our end, but we can't figure out what any of those are, as there isn't anything described in the Behavior Changes Doc that points towards restricting background network usage (we do not use any dataSync foreground services)

Anyway, I'll try to get a system bug report, but like I said, the behavior is sporadic.

Hi @las...,

Please create a seperate ticket for comment#15.

Hi jap...

Reg comment #12:

Could you please let us know if the mail was received/never received/received with a delay?

I logged another bug report similar to this. For me, the notifications are not displayed when received, but some minutes later sometimes up to 45 minutes.

Seems to happen randomly, as some apps might work fine and then have a delayed notification. As I've noticed, notifications are not shown until I dismiss some other visible notifications. Then the "missing" ones will pop up, with the timer specifying "45 minutes ago".

My bug report is 391250926.