Status Update
No update yet.
Comments
ja...@google.com
Great, thank you for the update and analysis.
https://issuetracker.google.com/issues/122098785
pe...@gmail.com
Not only new restrictions are being introduced year by year, but in addition OEMs maintain app whitelists which are highly anti-competitive and even more damaging for smaller developers..
The only education for the users on what is happening now comes from the
ja...@google.com
Hello
pe...@gmail.com
I think issue
But now in 2021 the issue has grown immensely. We see this is a major issue with even non-Chinese OEMs with huge global market shares like Samsung. And their approach to process management which is devastating for many very useful apps and use-cases and for smaller devs is becoming a "defacto" standard.
ja...@google.com
Thank you for the update.
We’ve shared your update with our product and engineering teams. Please provide any updates within the issue
sm...@gmail.com
Take it more seriously. Are the covid tracker app not enough shame for you?
co...@gmail.com
[Deleted User] <[Deleted User]> Restricted
sa...@google.com
lb...@gmail.com
It's many times breaking behaviors by default, having their own made-up rules and permissions, and sometimes even against clear documentations on the Android website.
Example here:
And this is on a relatively new Android version, and I'm sure it still exist on Android 11, and soon on Android 12.
ad...@google.com
Could you please share with us a use-case where your app needs to be in the foreground and retrieve the accelerometer data under Doze?
se...@gmail.com
My use-case is the use of accelerometer data to do accurate transport mode classification (i.e. walking, running, driving, etc.) using a machine learning model. Additionally, I use accelerometer data along with other sensors to analyze driving behaviour (e.g. harsh breaking, turning, etc.).
To clarify, apart from the intermittent short idle states that the user might be in (e.g. stopped at a traffic signal), I generally do not collect accelerometer data when the user is completely idle for long periods of time. My application works fine on Pixel devices for example, which activate doze mode as expected. My problem is with OEM devices that active it (or a variant of it) in an overly aggressive manner.
br...@gmail.com
help me
pe...@gmail.com
Unfortunately Doze mode killed the option to use sensor batching to solve this use case as the frequency cap on alarms no more allows to get the data from the sensor batch queue ion the time needed.. (and some devices do not support sensor batching)..
So the only option left is Wake Lock + Foreground service + AccelManager..
se...@gmail.com
ka...@gmail.com
The issue was fixed relatively shortly. But as our app was crashing at start because of the native crash in Android WebView, Samsung did automatically put it on the Sleeping app list - this is probably one of their non-standard battery optimization policies. Also the app was put on the sleeping app list even the user already remved the app from that list n the past. And of course the user did not get any notice of the fact the the system crippled the app.
So even Google did fix the WebView issue relatively quickly, we are still fighting with the WebVeiw
pe...@gmail.com
tz...@gmail.com
getReason returns REASON_OTHER
getDescription returns Chimera #0 / Chimera #1 / Chimera #2 / Chimera PMM
I am also getting multiple REASON_LOW_MEMORY reports mainly on Pixel devices, although my app is very moderate with the memory.
Android 11 is currently the worst Android version in my books.
ji...@google.com
@sebouh00@gmail.com, can I share the files attached in #1 with Samsung for review?
se...@gmail.com
Yes, please do.
ji...@google.com
thanks! shared with Samsung for analysis
me...@gmail.com
mi...@gmail.com
mi...@gmail.com
di...@gmail.com
sa...@gmail.com
gr...@gmail.com
I just wanted to say that i'm another victim of ChimeraPolicyHandler, which occasionally killing my foreground service,even after disabling possibly everything associated with battery saving policy (all steps from
Is anyone working on this issue ?
ad...@gmail.com
te...@gmail.com
ra...@gmail.com
[Deleted User] <[Deleted User]>
I cannot believe Google allow companies like Samsung to tarnish their name in this way. When people think of Android they think of Samsung, and when people think of Samsung they think 'broken notifications'. Not only is this issue frustrating for Android developers like myself, it's frustrating for millions of Android users around the world.
Fix this, or continue to be the inferior product to iOS, where basic functionality like notifications 'Just Works'.
gr...@kochaniak.com
"Regarding screen off, this is not a bug, this is a normal behavior according to the policy. We have communicated with the respective team regarding this. According to their feedback, this is tough for the team to change the policy currently. They recommend you to use foreground service instead of background service in this case. We hope you will understand the current situation and our limitations."
Well, the advice to use "foreground service" is useless - my app uses it for many years now... My final response to them, sent also today, is just a helpless venting of frustration, I guess...
"I already do everything that is necessary, including using the foreground service. This situation simply sucks. You are unable to detect the legitimate, user approved situation (listening to the app reading aloud with screen off), and kill the process, or put it to sleep. It is very hard to reach all the users and explain to them all the hidden and convoluted settings, different on each phone and each version of Android system. It is simply careless, stupid and a complete lack of respect on your part towards your users and app developers. Oh well, what was I expecting – typical behavior of big bullies, no matter if they are called Google, Samsung or whatever else."
Greg
[Deleted User] <[Deleted User]>
gr...@kochaniak.com
an...@gmail.com
lo...@gmail.com
Are you also holding a partial wakelock while your foreground service is running?
ch...@gmail.com
So, even if you modified the system settings - as found at
Since Google has not forcefully enforced the "standard" surrounding killing of apps running foreground or background services, OEMs like Samsung has had a "carte blanche" approach towards their Android mobile devices and do what they damn please. And, since that's the case, any sort of innovation coming from third-party Android developers have been all but stifled!
That's truly disgusting behaviour from Samsung... et al!
ng...@gmail.com
br...@xovation.com
I am an Android dev. My latest app, We Ski & Snowboard Tracker, records the user's session on the mountain with GPS data. I developed it for both Android and iOS.
No problems at all with the iOS version. It works as expected.
The Android version has a properly configured Foreground Service and holds a Partial Wakelock. It also coaches the user to disable Battery Optimization. But it still gets terminated or dozed at random by the OS. Samsung devices are the worst in that regard.
Android is essentially an unstable platform for apps that need to continue running while the screen is turned off.
gr...@kochaniak.com
ad...@google.com
1. Which OEM device do you observe the FSA issue?
2. Which model and build number?
3. Is the issue reproducible with this OEM's latest updates/builds?
4. Which region(s) did you observe the issue?
5. Which Android OS version?
6. Affected API
7. Issue Summary
8. Steps to reproduce
9. Repro on other devices (if any)
10. Affected APK / the app name on PlayStore
ad...@google.com
em...@gmail.com
ad...@google.com
ad...@google.com
ad...@google.com
gm...@gmail.com
Well, since nobody else is volunteering information, I'll try to add my two cents.
We have a taxi driver's app with a foreground service to track device location (for getting nearby orders, calculating ride distance and so on). There is an explicit menu item to stop this service and exit the app. During the ride, our app is often in the background, because we don't have a built-in navigator (we pass target coordinates to Google Maps or similar apps instead). The drivers are instructed to disable any "battery optimizations". Typically the device is constantly connected to charger, with the screen turned on.
We mostly see three types of issues:
Type 1: App is silently killed, despite the foreground service. And it's not that the user swiped it off the Recents screen (we track this event separately). This affects approximately 2/3 of our users, with various devices (see below).
We currently track only the most critical scenario (app was killed during the actual ride, screen was never off), to avoid being overwhelmed by thousands of reports, and it's still ~12% of total sessions.
Type 2: App is alive, but we don't get locations anymore. This is mostly Huawei (42%).
Type 3: App is alive, but our foreground service is stopped. This is only Samsung, mostly Galaxy A01 (81%).
Next points are for issue type 1, which is most relevant to the topic discussed here:
- 44% Samsung, 34% Xiaomi (similar to our general device distribution)
- By popularity: Galaxy Tab A, Galaxy A10, Galaxy A11, Redmi 9, Redmi Note 9, Redmi 7A and dozens of other models. Not only low-level devices: the same happens on Galaxy S20 FE and Xiaomi Mi Mix 3, but these are not typical for taxi drivers.
- Probably yes, but low-level devices don't get that many updates
- Moscow region, where our users reside
- 50% Android 11 (higher compared to its 34% in total user base), 22% Android 10, 6% Android 12
Service.startForeground()(not sure if I got the question right)- App is killed, see above for more details
- This is complicated in our specific case, because currently only the employees of some taxi companies can log into the app, and it does not have English localization yet.
- See #2
MultiPassme
uf...@gmail.com
Samsung Galaxy m52 5G
2. Which model and build number?
m52 5G - SP1A.210812.016.M526BRXXU1BVC4
3. Is the issue reproducible with this OEM's latest updates/builds?
Yes, I updated it from 11 to 12. The issue still exists.
4. Which region(s) did you observe the issue?
Turkey
5. Which Android OS version?
12
6. Affected API
I don't know.
7. Issue Summary
Device kills Dropsync and Volume Styles apps in a couple of hours
8. Steps to reproduce
Left my phone on the table for 2-3 hours.
And check.
9. Repro on other devices (if any)
I don't know.
10. Affected APK / the app name on PlayStore
Dropsync
Volume Styles
vi...@google.com
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Note: Please avoid uploading directly to the issue using attachments. Please upload to google drive and share the folder to android-bugreport@google.com, then share the link here.
gm...@gmail.com
To simplify reproducing the issue, I've run
vi...@google.com
Re-
ta...@gmail.com Restricted+
ta...@gmail.com
ta...@gmail.com
va...@gmail.com
to...@gmail.com
vi...@google.com
gm...@gmail.com
Sure.
I didn't make a screen record, because there seems to be nothing to record: our foreground notification is shown, but after a while (sometimes 15 minutes, sometimes about an hour) it's just gone.
We have a plain foreground service, no wakelocks. All energy saving settings are on default values.
vi...@google.com
ba...@gmail.com
10 t0 android 12 software update my phone
ha...@gmail.com
ge...@gmail.com
Wow, y'all I knew so eone was in my account and I have been on Google for 2 years and ... BAM... TODAY I GOT SMART AND FOUND THE ANDROID STUDIO AND THIS ON THE GOOGLE CLOUD! IM VERY MAD AND GOOGLE YOU NEED TO DO SOMETHING ABOUT IT!!! NOW
te...@gmail.com
Jeff
Jeffrey Polansky
13 Dorlyn Rd
Albany, NY 12205
TechValleyJeff@gmail.com
518-779-6625
On Fri, Jul 29, 2022, 2:31 PM <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]>
I have created a related topic about background execution on Samsungs compared with pixel with evidence and the sample app. Maybe it would be helpful.
Here is a link:
vi...@google.com
We shared the issue with Xiaomi but it was not reproducible. Could you please share the exact reproduction steps with us and if it's possible, share with us whether it can be replicated on an Android 10+ devices.
vi...@google.com
In addition to the above comment,
-
If the issue is reproducible, please share a bugreport for further investigation.
-
Can you please check if the issue can be solved by setting the App Info > Battery Saver option to No Restrictions?
sa...@google.com
tz...@gmail.com
Just info:
In some cases this battery optimization causing the DeadSystemException. Especially on Samsung, Android 10.
I get multiple reports from a foreground service
Non-fatal Exception: java.lang.RuntimeException: android.os.DeadSystemException
at android.app.ApplicationPackageManager.queryIntentActivitiesAsUser(ApplicationPackageManager.java:1271)
at android.app.ApplicationPackageManager.queryIntentActivities(ApplicationPackageManager.java:1234)
So basically the system is running, the app is running, but it sees the system as dead.
I stopped getting this exception after the user disabled battery optimization as described here
vi...@google.com
Re-
tz...@gmail.com
I can't. It happened on user's phone
vi...@google.com
kr...@gmail.com
vi...@google.com
We couldn't replicate the issue, as mentioned in
vi...@google.com
ad...@google.com
vi...@google.com
In order to move forward, we need the impacted users to check the problem on an Android 10+ smartphone, and if it's repeatable, we need them to submit a bug report with the necessary reproduction instructions. Thanks.
fl...@gmail.com
vi...@google.com
Re-
In addition, please check if the issue can be solved by setting the App Info > Battery Saver option to No Restrictions.
tz...@gmail.com
Two years you're unable to get a dozen of OEM phones and run a full scale test? This is ridiculous. We should sue you.
fl...@gmail.com
ba...@gmail.com
But this. This issue is still a thorn in my side. I would argue it is _the_ thorn in my side. In my personal and professional projects. You don't need someone to submit a repro case. Buy a Samsung, Huawei, OnePlus, or Xiamoi device. And use it. Or read forums. Or just ask any developer.
I wish Android banned manufacturers from adding custom background restrictions or killing background processes, and that this ban was enforced by the CTS. It makes Android look bad. App developers get blamed for this behavior because users don't know what is causing it, and the behavior varies not only by manufacturer, but by Android version. Every time a manufacturer updates their devices, e.g. from Android 12 -> 13, they change their bespoke battery saving behavior, it breaks our apps, and then we get 1-star ratings and annoyed support emails. It shouldn't be our job to educate users about their manufacturer's garbage customizations, but that is what the majority of my support e-mails are about.
fa...@hotmail.com
Yes
ul...@antavi.ch
This is a problem and yet no workaround, no solution that is just mediocre is offered? I got 100.000 users sitting on my neck because of non-standard approaches to app states that basically lead to non-deterministic behavior.
That hurts users and developers.
Example: How can I keep an app running as a foreground service asking every 10min for a location?
Is that possible across *all* Android OEMs? Yes or no.
fa...@hotmail.com
ch...@gmail.com
The reason I'm not submitting any more technical info to Google's IssueTracker is NOTHING EVER GET FIXED, period! It's pointless for myself- or any other developers for that matter- to submit anything to Google to fix since we already can guess Google's responses:
- "Working as intended"; or
- "Obsolete"; or
- "Sorry, we weren't able to replicate the technical issue on our end", and so on, and so on!...
Your LAB testing to replicate Android issues is NOT THE SAME as FIELD testing the same issues on active Android mobile devices circulating in the production Android ecosystem. So, of course, you will NEVER be able to replicate the issue- that much is obvious.
If Google really want Android to thrive, then first scrap and rebuild your CTS acceptance testing procedure and actively enforce whatever "standards" you need towards OEMs regarding Android- clearly, your CTS procedure is NOT WORKING AS INTENDED! Do it not, then you're just wasting developers' times with your careless unethical approach. Sure, my words may sting a bit, but someone needs to speak up about Google's business practices that is destroying a promising open(?) mobile operating system build on top of Linux.
Regards,
C.
vi...@google.com
vi...@google.com
The drive link provided in
ye...@gmail.com
ja...@gmail.com
Pienso que esta bien
ne...@gmail.com
and now you are complaining with google because it doesn't allow it? is this the case?
mi...@gmail.com
Android beta decypt
ti...@gmail.com
Per comment
We do NOT see the issue when we disable battery optimization. Battery Optimization freezing an active VPN while it is in the background is problematic.
[Deleted User] <[Deleted User]>
دانلود بهترین های پورنو
[Deleted User] <[Deleted User]>
عشق واقعی💞
fa...@hotmail.com
👨💻
le...@gmail.com
si...@gmail.com
be...@gmail.com
pu...@gmail.com
What's tragic is that some manufacturers are breaking Android as it is documented with their clever 'save the battery' customization. This should have been addressed like 10 years ago with a hammer to prevent them from doing that but here we are... It results in broken app, angry users and developers, and the existence of dontkillmyapp which is just band aid and not even 100% complete.
co...@gmail.com
[Deleted User] <[Deleted User]>
ma...@gmail.com
Kiero que funcione
aa...@gmail.com
fa...@gmail.com
تل
fa...@gmail.com
de...@gmail.com
co...@gmail.com
hakkınızda savcılık suc duyurusu verildi
ro...@gmail.com
af...@gmail.com
Over 3 years later and this issue still exists.
I run an S21FE with android 14 and despite ensuring I've given all of the accessible options to exclude the app I need from battery saving methods Samsung continues to break functionality and as such I am unable to gather and process valuable information.
This issue was less prevalent with my previous LG devices.
Android team needs to tell OEMs either allow users to exempt any app of their choosing from any task killing/battery saving methods of we choose or revoke any and all licenses to that OEM to use Android
I'm sick of being dictated as to what I can do with my device by a manufacture when it has the inherent capability.
Wake up team or watch us all tell android to GF itself.
I will be suspending all Android development going forward with my partners until this issue is fixed.
si...@gmail.com
@sintayew Gashaw
jo...@gmail.com
vida
pl...@gmail.com
pl...@gmail.com
ni...@gmail.com
lo...@gmail.com
You might want to use AtomicFile or SQLite + frequent saves (e.g. after each action) to be shutdown resilient.
ma...@gmail.com
in...@gmail.com
ro...@gmail.com
sh...@gmail.com
Ima caom be ke foru you karten pu the assignment of daakley
Description
2 years ago, I created an issue here on how certain OEMs were altering core Android components for the sake of battery optimization, while breaking basic functionality that developers rely upon (
I am here to try and reach out to the Android team again, and request you to properly address this matter. About 7 months ago, this issue was the most voted topic in the Android 11 Reddit AMA, and we received a number less than adequate replies from the team. One of these was how Google will be updating the CDD to enforce OEMs to be transparent about their restrictions. To quote:
Unfortunately, this seems to have fallen on deaf OEM ears. My Samsung Galaxy S10e device recently got updated to Android 11, and lo and behold, Samsung continues to run these shady practices by disabling wake-locks and broadcast messages without user or developer consent.
Attached, you will find a test app that I used to collect accelerometer data, by running a foreground service. It's a simple app that logs the timestamps of the sampled data, alongside the system time when the data was delivered. When the device is unplugged and set aside with the screen off, after 3 minutes, the app stops receiving accelerometer data. After a few minutes, I plug in the device to extract the data, and the app resumes receiving the data (80 seconds of data in a short burst), however there is a large gap in the data, plus there are intermittent out-of-order values (i.e. the timestamps are not always monotonically increasing). You can find the result attached as well.
Looking into the device logs (attached), it is clear that at the exact moment when the app stopped receiving data, the power manager service decided to "freeze" the app, disabling its wakelock. The app is "unfrozen" again after plugging the USB cable.
The only way I am able to avoid this issue is by disabling Android's battery optimization. However, as you know, this action is generally forbidden in Google Play's policy and can result in my app getting removed from Google Play.
This is just one example. I am sure the community can come up with thousands, for different OEMs.
I would like to know if Google plans to solve this long standing issue, and if so, how and when. If Google does not enforce strict policies that OEMs must abide by, and we don't see the situation improving, it will no longer be feasible for us to build products for Android.