Status Update
Comments
ad...@google.com <ad...@google.com> #2
Can you share a bug report, after reproducing the issue ?
Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)
Android bug report
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method:
After reproducing the issue, navigate to developer settings, ensure ‘USB debugging’ is enabled, then enable ‘Bug report shortcut’. To take bug report, hold the power button and select the ‘Take bug report’ option.
NOTE: Please upload the files to Google Drive and share the folder to android-bugreport@google.com, then share the link here.
se...@gmail.com <se...@gmail.com> #3
*
*
gu...@gmail.com <gu...@gmail.com> #4
[Deleted User] <[Deleted User]> #5
ad...@google.com <ad...@google.com> #6
ad...@google.com <ad...@google.com> #7
What use cases you want supported without having to get white-listed from battery optimizations?
se...@gmail.com <se...@gmail.com> #8
Here are some use cases that are not possible today without explicit whitelisting (tested on Huawei P20 Lite running Android 8):
* Receiving a geofence exit from Google Play Services (the broadcast is dropped since it is proxied via Huawei's powerginie manager).
* Requesting sensor data using a foreground service (wakelocks are proxied as well and released upon screen off).
* Receiving activity transition events from Google Play Services (again, broadcasts are dropped).
* Requesting location fixes via Google Play Services by running a foreground service (wakelock and broadcast issues).
Huawei uses powerginie to proxy all broadcasts and wakelocks through its service as soon the screen goes off, and selectively permits apps based on package name whitelisting, app type (email, instant messaging, clock), network connectivity, etc.
in...@appyhapps.nl <in...@appyhapps.nl> #9
It is impossible to explain to all app users on Huawei (or other phone models with similar agressive background killing behavior) to manually set the launch mode. Apps that respect the latest Android rules for doze and background processes, won't work correctly. This has nothing to do with the white-listing from battery optimizations. Even that white-listing won't work if the launch mode isn't set correctly.
The main point is not that some apps' core functionality is broken, the main point is that Android functionality isn't working as described in the specifications if the end user doesn't arrange certain settings manually.
For Huawei this applies to the devices with Android 8 and Android 9.
ma...@gmail.com <ma...@gmail.com> #10
For example, some Nokia devices kill every background process and cancel all AlarmManager alarms after screen has been off for 20 minutes, even if that process runs as foreground service. This includes apps like alarm clocks, which is really bad (it prevents 3rd party alarm clocks from even waking you up in the morning). I think that things like this should definitely not pass the CTS.
pu...@gmail.com <pu...@gmail.com> #11
Android is becoming a free-for-all. Google, please do something with manufacturers so Android work as you document it !
Why do we have to endure that mess:
Manufacturers have FORKED Android regarding background processes behavior.
lb...@gmail.com <lb...@gmail.com> #12
The bad thing here, is that by default, they don't allow apps to auto-start themselves.
I wrote about it here:
se...@gmail.com <se...@gmail.com> #13
al...@gmail.com <al...@gmail.com> #14
Only OEM`s own app or popular app can run stable in background by default. API Guide? they dont care.
I can only give a tip for user, tell them: Be careful with the background restrictions of your phone. Want`s more? Ask the phone factory customer service. I dont have the money to buy lots of phone from differnet OEM.
Most normal user can not use the background app well. There are too many steps! They just know: This is a bad app...
lu...@gmail.com <lu...@gmail.com> #15
It can be a security problem if the APIs were modified with a backdoor and passed CTS, in that case one cannot be certain if Android can be trusted to banking apps.
For manufacturers who modified the Android APIs to not behave as documented officially should not be tolerated in the first place.
lb...@gmail.com <lb...@gmail.com> #16
Not exactly what I was hoping for, but I hope other Chinese companies will either follow the rules (both of privacy and of Android framework) or not have Google services at all.
co...@gmail.com <co...@gmail.com> #17
Manufacturers, instead of working on new better and enhanced batteries, are working on sleeping the device as much as possible. Smartphones are turning back into dumbphones.
pu...@gmail.com <pu...@gmail.com> #18
on their shitty battery saving measures breaking apps left and right.
si...@gmail.com <si...@gmail.com> #19
There are a lot of scientific studies, which rely on apps to generate crowdscourced data sets.
Most of these apps need to run in the background and the users know that (and it is shown via a notification).
The approach of the mentioned chinese OEMs is unacceptable and Google needs to change that.
je...@beartoothradio.com <je...@beartoothradio.com> #20
ro...@gmail.com <ro...@gmail.com> #21
je...@beartoothradio.com <je...@beartoothradio.com> #22
co...@gmail.com <co...@gmail.com> #23
Any more information about this big problem?
Android Q is coming right now. Will it have this same problem that you are aware of since 2018?
lb...@gmail.com <lb...@gmail.com> #24
"
We acknowledge the issue and take it very seriously. We have been actively working with device manufacturers to fix their implementations and seen some positive outcomes.
While manufacturers are allowed to do battery saving by meeting all requirements listed under Section 8.3, it’s highly likely the issues you described here are against the Android Compatibility Definition Document (CDD) requirements (e.g. “MUST NOT alter the lifecycle of system component” as described in Section 3.5/C-0-2.
To help with the situation, we’ve added a CTS test in Android Q to ensure that an app is not killed upon being swiped from Recents. However, as you noted, device manufacturers have various implementations and it is extremely difficult to create an automated test to capture all wrong implementations that are against CDD requirements.
Lastly, can you please share more details on the issues you described via DM? (i.e. APK names, repro process, device name, version and Android OS version). We’d like to look into it more. Thank you!
"
I don't think it's enough, but at least something...
I guess it's hard to add those tests.
Even Samsung got to the bad list these days:
and indeed I got a complaint about my app recently that can't respond to Intents (even though it has a foreground service and the Activity is focused!) on Galaxy device with Android 9, after my app was "optimized" .
Sadly they don't intend to write there anymore (thread locked), and they didn't answer most of the questions either, let alone comments to what they wrote (like the most popular complaint/worry about storage permission restrictions) ...
je...@beartoothradio.com <je...@beartoothradio.com> #25
This is a serious problem though and if it goes unchecked it will do harm the Android and Google brands. It will also do harm to any brand behind an app that relies on background activity.
This is not hard to fix, and the engineering team pretending as if it's some daunting task is infuriating. Hire some real human bodies for compliance testing. You have the money. Stop letting OEMs do whatever they want because you're afraid they'll use Tizen instead.
lb...@gmail.com <lb...@gmail.com> #26
he...@gmail.com <he...@gmail.com> #27
lb...@gmail.com <lb...@gmail.com> #28
Google for some reason just marked it as "Status: Won't Fix (Obsolete)" , without any explanation.
What I'm talking about is putting intent-filter in the manifest (example: phone calls intents), receiving intents there as normal, till the user removes the app from the recent-tasks.
The manufacturer has "auto-start" toggle for each app. For some popular apps it's turned on by default. For most of the apps on the Play Store, it's not.
When it's not, nothing will trigger the app to start again, except for the normal launching of the app.
Also, to them, it's not a "bug" as the manufacturer intended it. It's a "feature" in their eyes.
Just a terrible one, as it breaks expected behavior, not a standard, and doesn't have any official way to handle.
ce...@gmail.com <ce...@gmail.com> #29
CTS has recently forbidden OEMs to kill apps if the task is swiped away.
Customized approaches other than google's own machining learning based algorithm, except this behavior are still allowed, and I believe it is a good thing to kill an app solely based on user's will.
lb...@gmail.com <lb...@gmail.com> #30
Do you think it's good how the OEMs treat what happens by removing from recent tasks?
It does much more than kill the process (which also shouldn't occur in 100% of the cases).
It semi-disables the app.
They created a "auto-start" setting, which means that apps won't be able to receive intents in this case.
So imagine you've made any app that listens to some global intent (like a phone call) and acts accordingly. Maybe even show something to the user.
Now your app won't work this way anymore just because the user removed it from the recent tasks.
And users still remove apps from recent tasks very often.
How could this be a good thing?
It causes a lot of complaints by users already, and developers can't do anything about it, other than requesting permissions they don't really need (or other weird workarounds), just to let the apps stay alive.
mi...@gmail.com <mi...@gmail.com> #31
What do you plan to do with this problem? How do you plan to solve this issue?
co...@gmail.com <co...@gmail.com> #32
hw...@gmail.com <hw...@gmail.com> #33
vi...@google.com <vi...@google.com> #34
lb...@gmail.com <lb...@gmail.com> #35
I'm not saying they shouldn't add features. I say they shouldn't cause apps to break so easily and especially by default.
It's not just Chinese OEMs anymore:
ro...@gmail.com <ro...@gmail.com> #36
I think we all want to know, what exactly blocks this important issue, but I'm getting "access denied" when trying to open that link
Just delaying solution are only makes thing worse. There is already millions of devices, that won't be ever updated. And now even Samsung started to roll such "battery savers" in updates and new devices (S9, S10, etc)
an...@gmail.com <an...@gmail.com> #37
How about this issue? Our apps is alarm for prayer times, in my country Indonesia 80% Android devices is Chinese ROM, all Chinese Roms will kill alarm, schedule jobs, work-manager. Why you made functions of alarm, work-manager if not working on 80% populations Android device in the world?
an...@gmail.com <an...@gmail.com> #38
You must to buy one of the latest Xiaomi devices, and please make a repetition alarm application, for example: create an alarm with notifications every 5 o'clock in the morning, (and don't open the application), and you won't get notifications tomorrow at 5 o'clock in the morning. YOUR APP KILLED BY XIAOMI SYSTEM.
su...@gmail.com <su...@gmail.com> #39
ma...@gmail.com <ma...@gmail.com> #40
[Deleted User] <[Deleted User]> #41
Example: A Prayer times apps installed by users at 4 am, and user turn on the alarm function from my app for get notification for prayer times for every day at 5 am, and then in that day the user will get notification at 5 am (here the alarm function still working). But at tomorrow the user never got a notification at 5 am (here the OS has been killed my app, WorkManager, AlarmManager, Jobs).
I hope Google can provide justice for small developers like us.
Thanks.
[Deleted User] <[Deleted User]> #42
ab...@gmail.com <ab...@gmail.com> #43
re...@gmail.com <re...@gmail.com> #44
I understand, that it's hard to make an automated test for detection of all that mess, that these stupidiot manufacturers making with Android APIs responsible for background and foreground services.
These manufacturers care only about their profits, neither about their users or app developers.
But You need to overcome this no matter how hard it is and enforce manufacturers to not turn on by default any battery saving feature they have. You have resources for this - You are one of the largest international IT companies worldwide.
As a result, even if You will not completely deny all this shit, there will be surely a noticeable positive outcome.
re...@gmail.com <re...@gmail.com> #45
su...@gmail.com <su...@gmail.com> #46
lb...@gmail.com <lb...@gmail.com> #48
vi...@google.com <vi...@google.com>
en...@gmail.com <en...@gmail.com> #49
re...@gmail.com <re...@gmail.com> #50
an...@gmail.com <an...@gmail.com> #51
an...@gmail.com <an...@gmail.com> #52
re...@gmail.com <re...@gmail.com> #53
[Deleted User] <[Deleted User]> #54
[Deleted User] <[Deleted User]> #55
mu...@gmail.com <mu...@gmail.com> #56
st...@gmail.com <st...@gmail.com> #57
lb...@gmail.com <lb...@gmail.com> #58
de...@gmail.com <de...@gmail.com> #59
Would like to know if a petition or something similar can be started, and if it can also act as an awareness campaign for even a small fraction of our customers, it would be something.
Just to share my experience, when I faced this issue, I tried a workaround of relying on FCM data messages to trigger my jobs (only partially successful so far). However, this will only work for non-time critical applications (syncing data with server, updating local cache etc.). If the task is time-critical, still hopeless.
Whitelisting specific apps at OS level is utter BS and highly likely unlawful too.
to...@gmail.com <to...@gmail.com> #60
Good
to...@gmail.com <to...@gmail.com> #61
Godddddf
cc...@google.com <cc...@google.com> #62
lb...@gmail.com <lb...@gmail.com> #63
And which of the issues?
I've found both "auto-start" permission (almost disables apps by default when removing from recent tasks, not allowing to start again via various Intents) and "show a pop-up in the background" (not following the docs about the excluded cases of allowing apps to appear "out of nowhere") on Xiaomi Redmi 8 with Android 9 build PKQ1.190319.001.
Both issues also appear on Xiaomi mi 9t with Android 10, as we've found, and Xiaomi Redmi Note 6 (Android 8.1.0) and Xiaomi Redmi 6A (Android 8.1.0) .
So, just take any Xiaomi device that was made over the past years that has Android 8,9 or 10, and you will notice a bunch of made up permissions that break apps, usually by default.
And I'm sure Xiaomi isn't the only OEM that makes a mess.
si...@gmail.com <si...@gmail.com> #64
P20 (HWEML) Android 9
OnePlus5T (OnePlus5T) Android 9
co...@gmail.com <co...@gmail.com> #65
da...@wikiloc.com <da...@wikiloc.com> #66
We've faced this issue mostly with Huawei, OnePlus, Xiaomi and Samsung, in no particular order. Other brands, like Oppo and Honor pop up in customer support from time to time as well.
A bit of context:
In our case, we have a Foreground Service to continuously track the GPS location of the user (we're an outdoor sports tracker app). If the app is not manually whitelisted by the user against the OEM's own battery optimizer, it gets killed by the system after a while, usually while in background. Sometimes, whitelisting is not enough and the app gets killed anyway.
lb...@gmail.com <lb...@gmail.com> #67
Sadly, Google should set strict rules about this matter: apps being killed, OEMs not following even the docs, made up permissions (some are even set by default) that break behavior...
Usually I'm against that Google will restrict things, but here the OEMs went way too far.
Really hate all this mess that each OEM makes its own behavior. There is almost always nothing developers can do, and users will complain about it to the developers and not the OEM, as if it's a bug on the app, and that's even though the app works fine on Vanilla (Pixel devices, for example) ...
pu...@gmail.com <pu...@gmail.com> #68
Xiaomi: Android 9 and 10
Meizu: Android 5.1 to 9
TCL: Android 9
BLU: Android 9
Blackberry
The only case where bindService() does not fail on these device is if the process we want to bind to is already running prior bindService().
co...@gmail.com <co...@gmail.com> #69
an...@gmail.com <an...@gmail.com> #70
The users drop a poor rating because these stupid OEMs aggressively kills the services in background (even though the service is extremely lightweight). I frequently receive soo many feedbacks mentioning that the app is not working on their phone, and when I ask them about the manufacturer, it is always the once mentioned below.
Even if you guide the users to enable to "OEM Specific" battery savers blacklist (Auto start, Battery saver, or whatever each of them call it), the problem remains the same. Even after blacklisting from oem specific battery savers, THE BACKGROUND SERVICES ARE KILLED ALMOST ALL THE TIME.
OEMs from Huawei, Honor, Xiaomi, Oppo, Vivo, Nokia, OnePlus and more are affected. No specific model or build or android version. All of them have there custom android skins/builds, and they have built it within their Roms to kill background tasks. You can see
I request Google to please do something regarding this. Even though devs are not at fault, the users think that our app is at fault, and drop poor ratings.
Also, this is not expected from Android, that their own framework tools are not guaranteed to work across all the devices. It is a failure on part of Google.
I request Google to make changes in the test suite before granting a license to such OEMs devices.
The phones like Pixel, custom ROMS for other OEMs, dont have this problem. So it is not an issue with AOSP. It is something OEMs themselves have created in a evil attempt to boost their device performance, and shift the blame on app developers.
in...@appyhapps.nl <in...@appyhapps.nl> #71
- autostart in the background not allowed
- alarm scheduler not working
- pausing background processing (using a foreground service with notification and partial wakelock enabled)
- fcm data message processing not working (maybe due to autostart issue, or just no background operation allowed)
My app synchronizes data with Samsung Health and I often see on Huawei devices that the Samsung Health service can't be started in the background neither. So I have to explain users to change the settings not only for my app, but also for Samsung Health.
Android is causing a bad experience for users when useful and legitimate apps that follow the Google recommendations and policies don't work by default, but only after changing phone settings that many users don't understand.
mi...@gmail.com <mi...@gmail.com> #72
Works flawlessly on Pixel devices
On Huawei/OPPO/Some other brands, it works for a while, and then stops working.
fa...@gmail.com <fa...@gmail.com> #73
to...@gtempaccount.com <to...@gtempaccount.com> #74
I for one can attest that this is becoming a serious pain point for developers. For weeks now my team and I have been trying to get background schedulers to work consistently on these devices! We are now on month 3 with no end in sight. We have tried the following Background APIs to perform work in the background and none of them work as the Android Documentation say they will. We followed all the guides and Android Developer Videos to make sure we are doing this right but to no avail. We also contacted other Android Development companies and they are in a similar situation.
- WorkManager -Works for 1-3 days and stops
- SyncAdapter -Works for 1-3 days and stops
- Firebase Dispatcher - Works for 1-3 days and stops
- JobScheduler - Works for 1-3 days and stops
- Alarms & Broadcasts - Works for 1-3 days and stops
- Firebase High Priority pushes - The messages do not get demotes because we only send 1 a day. They FirebaseMessagingService is never called!
- Foreground Service - Gets terminated a few minutes after user exists the app
You name it! We have tried it! From our 3 months of testing it seems that these device manufacturer do the following to avoid compliance. When the app is newly installed, the background tasks will work for some hours to about 4 days. After that, the Custom Rom Devices will completely prevent any application component from running. This includes Broadcast Receivers, JobServices, Remote Pushes.
Note: Popular apps are exempt: Facebook, Instagram, Twitter, Spotify, Tinder and all the other tops.
In order to get Jobs working correctly, We have to explain to users that they must disable battery optimizations and other manufacturer battery saving features in order to provide them the best possible experience. This defeats the whole Battery Saving Initiative!
I for one support Doze Mode and App Standby buckets. What I don't support is Custom Rom manufacturer who prevent any component in the app from launching so they can look good on battery saving marketing charts. Google pleassseeee this is hurting so many developers. We cannot provide innovation or the best quality of service to users on the platform if we cannot even refresh our app at least once a day.
Many of the apps that use background services and depends on their consistency are LIFE SAVING Apps: Medical apps, fitness apps, location aware apps. This is no longer about saving battery. It's about saving lives.
What I would Recommend
All device manufacturers should not limit the JobService or WorkManagers service androidx.work.impl.background.systemjob.SystemJobService
and its components. This should be applied to all devices still receiving security patches or older if possible.
Supporting Evidence:
A list of violating devices can be found here:
Slack:
VLC:
Flock:
Notification History Log:
Circuit App:
Avast:
bitbucket:
Other Resources:
an...@gmail.com <an...@gmail.com> #75
I tested on Huawei -Android9 and Xiaomi-Android9 only able to run a maximum of 1 day, after that they will always kill my application without mercy.
uw...@gmail.com <uw...@gmail.com> #76
My app has 500,000+ installs, ~100,000 of them active. But I'm really tired of getting downvoted and blamed for issues that cannot be solved on my side. So if the foreground service solution does not help I'm going to withdraw my app from Google Play Store.
My personal device is an Android One device - if things work on this device I expect them to work on every Android device. And my app works perfectly well on this Android One device, BTW it's a Chinese one ;-).
en...@gmail.com <en...@gmail.com> #77
While I can see some app able to get it work like telegram,
Should we handle that with OS layer directly instead of using OEMs OS layer ? (Sort of)
lb...@gmail.com <lb...@gmail.com> #78
You could encourage them to go there during the first screens of the app if you detect that their device is one of the problematic ones.
co...@gmail.com <co...@gmail.com> #79
lb...@gmail.com <lb...@gmail.com> #80
There is no official API for any of the made up stuff the OEMs have made, and they don't even have a website to go to for users.
It won't help blame others (and it's their fault). You want to handle it, so that's what's possible.
That's why we have this post, to tell Google to stop this behavior.
If there was no issue, we wouldn't have written about it.
fe...@googlemail.com <fe...@googlemail.com> #81
App (70k active installs) in store, which serves as a emergency notification system.
We're fighting Huawei's (and other's) restrictions for years.
1* results, disappointed users, you name it.
I won't repeat what you stated.
Google must force OEM's to comply with vanilla Android energy management. White listing must make apps running without further action.
Ordinary people (not technically interested) do not know how to deep dive in the Android system to set the switches necessary for apps to work.
Please Google. Hear us!
mr...@gmail.com <mr...@gmail.com> #82
Google have allowed Android to go to sh** and they really don't seem to care how it affects the third party developers that made Android successful.
Googlers should be ashamed of what they have allowed Android to become. It's embarrassing.
ja...@gmail.com <ja...@gmail.com> #83
It's also drastically unfair as we all know some apps are whitelisted by the likes of Huawei so a new developer can never compete with an established player who has made it onto the whitelist.
The lack of any useful feedback from Google on such a fundamental issue that effects so many developers (and users) is hardly surprising but still beggars belief. Is anything being done to prevent this in the future, and if so what? Please give us something to hope for!
an...@gmail.com <an...@gmail.com> #84
bs...@gmail.com <bs...@gmail.com> #85
Optional
[Deleted User] <[Deleted User]> #86
br...@gmail.com <br...@gmail.com> #87
ci...@gmail.com <ci...@gmail.com> #88
I know that if our personal privacy is not involved you don't care at all, but at least, ease us not to hate our day-to-day usage.
I'm a developer, so I think I can understand this thread, but I'm now talking as an user of a just-open mobile phone (Oukitel with Stock Android 9): It is a madness that I spent the full afternoon just configuring one-by-one all the apps because after a while .. just disappeared.
If I'm just "a developer that can understand this thread", let me suppose that you, working at Google, have a GIANT IDEA of what is going on with this, no? So, after 1.5 years do you think is still not enough to fix this? Of course you're developing lot of developable developments, but come on, this one is not that big developishmentish no?
If you think I'm wrong, please me explain how "Google Discover" and all my stored behaviours are shown without my intervention since the beginning each millisecond, and Termux is closed no matter how I configure it? Termux is not the type of application you want us to have, no?
If I just want not to mess with the phone, and, as a simple end-user, use it ... is not possible? I will be forced to root + rom it? Oh wait, a rooted phone cannot use Pay services ... damn Google, it seems like you putting a knife on our throats: Use a good system, or use common services like to pay with NFC ... but not both! Now let's talk about phone warranty if you play with it in any other way that the end-user case ....
Google, you already use and abuse our data, so please, at least, take our requests into any kind of minimal consideration
ma...@gmail.com <ma...@gmail.com> #89
* Do not allow OEMs to equip their phones with their own custom "battery optimization" apps. Android has its own battery optimization that is well documented and works as expected (e.g. no GPS with turned-off screen unless there's a foreground location service).
* Add an API to Android that lets apps check whether they are being subject to custom "battery optimization" and allows users turn the setting on/off. OEMs will need to expose their settings to that API. That way my app can check whether it's being "optimized" and send the user to the appropriate screen (or show a dialog) where they can turn off optimization. Right now there's a dev-maintained list of phone models and Intents that can be used to send the user to the appropriate setting screen where they can turn off battery optimization, but that's a terrible hack.
I'm working on a GPS tracking app and it's frustrating to get negative feedback from users every day because they cannot use our app properly unless they fix their OEM's settings. Worst of all, Redmi resets the setting every once in a while. And the cherry on top of all of that: very popular apps are exempt from optimization.
co...@gmail.com <co...@gmail.com> #90
fa...@gmail.com <fa...@gmail.com> #91
@Google: Are these Apps killed by the system or is the Google Play Service providing the Android Contact Tracing API excluded from getting killed? If so could Google Play Services just provide a dummy Service/API to keep our Apps also alive?
ma...@gmail.com <ma...@gmail.com> #92
en...@gmail.com <en...@gmail.com> #93
to...@gtempaccount.com <to...@gtempaccount.com> #94
Yesterday I read a very interesting article about how this issue is largely affecting developers in Africa. Here is a link:
Africa's smartphone market is saturated with custom android devices that do not work properly in the background because of manufacturers restrictions to save battery. How is Google going to bring and keep the next billion online if those devices do not work properly in the background.
What I would recommend Google to do as suggested by #91 is to have a way for Google Play Services to wake up the WorkManager Service/ Component. Developers would have to opt into this option in their manifest. It would work like the Firebase Messaging Service. As of now, this would be the only reliable solution for developers.
The long term fix would be for Google to provide a permeant fix. In the meantime, we will take any help we can get!
co...@gmail.com <co...@gmail.com> #96
lb...@gmail.com <lb...@gmail.com> #97
jo...@gmail.com <jo...@gmail.com> #98
More than 80% of my company's user base use a Chinese manufactured device (Xiaomi, Oppo, Vivo) and this has been a very big problem for us even today. There is no workaround solution that will work for this issue. The question is not about what workaround can get this to work, but why isn't Google stepping in to handle this?
From what I've experienced, these Chinese OEMs have now started to monetize over this problem. In order to get your app whitelisted, one needs to shell out millions($). This is ridiculous and it's high time Google intervenes.
I think companies and devs out there wouldn't mind paying a few extra bucks to get Cloud Messaging under a paid plan, but also ensures that these OEM issues are taken care of. I mean, I'd rather pay Google and have an SLA for reliable and guaranteed services than paying Chinese OEMs. One of the reasons why I think Cloud Messaging is still free is because it cannot offer a 100% delivery rate and it's mainly because of these OEM modifications.
One other thing is that these OEMs are now also coming up with their own push messaging services. Xiaomi for instance offers a "Mi Push services" (free and paid) which is not just a pain to register and integrate, but also cannot be trusted for privacy, service reliability and customer support.
The only option that we are currently left with is to ask our users to manually whitelist our app from being battery optimised from System Settings, which is a painful experience for an end user especially who does not understand technology as much.
pe...@gmail.com <pe...@gmail.com> #99
pe...@gmail.com <pe...@gmail.com> #100
Just commenting for the sake of the 100th comment on this issue.
ja...@gmail.com <ja...@gmail.com> #101
pu...@gmail.com <pu...@gmail.com> #102
As the author of an app that streams media (audio, video) to playback devices with Android device's creen off and possibly for a long time, I can attest that this issue is the #1 reason for support requests, and a cause for support nightmare and bad ratings... It's sad that some manufacturers are breaking Android to this level.
lb...@gmail.com <lb...@gmail.com> #103
Someone (not me) wrote about this here:
Please consider starring this question about this matter. I hope Google will answer there.
ap...@gmail.com <ap...@gmail.com> #104
Voted and added a comment
en...@gmail.com <en...@gmail.com> #105
di...@gmail.com <di...@gmail.com> #106
ra...@gmail.com <ra...@gmail.com> #107
Or Still Sleeping ?
lb...@gmail.com <lb...@gmail.com> #109
They don't talk about various made up stuff by the OEMs.
For example, this is a clear violation of the docs:
Not quite related to battery optimization.
I've also found various official Intents that OEMs cause a crash if you try to use them.
Those should all be in CTS rules.
Google should not have let OEMs such freedom for messing around with how Android works.
It makes the documentation useless. The documentation isn't reliable at all.
And it's not like in the past that those OEMs weren't even popular. They became very popular...
ka...@gmail.com <ka...@gmail.com> #110
lb...@gmail.com <lb...@gmail.com> #111
Google might not notice a comment out of the hundreds here.
di...@gmail.com <di...@gmail.com> #112
cc...@google.com <cc...@google.com>
ub...@googlemail.com <ub...@googlemail.com> #113
ap...@gmail.com <ap...@gmail.com> #114
In Germany it's been in many newspapers. (Maybe all?)
Manufacturers must feel the rising pressure and adapt Google's Android 11 guidelines.
This nightmare must end...
We developers deserve better.
tz...@gmail.com <tz...@gmail.com> #115
The existence and popularity of this site:
I had to disable some of device models, because of bad reviews. But then I started to receive emails from users who paid for my app and managed to get over these manufacturer restrictions:
- I paid for the app, why can't I download it.
- Well, I disabled your phone, because of bad reviews, and I don't have an option in Play Console to let users who already paid for the app download it.
- I want a refund and after that, I am going over every app you've made which I can download and will leave a bad review there!
True story.
se...@gmail.com <se...@gmail.com> #116
My only fear is that such a solution by Google may be deemed by OEMs as an official blessing to continue with these detrimental changes, so I would advise Google to severely limit what OEMs can and cannot do.
az...@gmail.com <az...@gmail.com> #117
sm...@gmail.com <sm...@gmail.com> #118
P3 priotity that apps cannot run as thay should... Shame
ch...@msn.com <ch...@msn.com> #119
to...@gmail.com <to...@gmail.com> #120
Is Android on the Google Graveyard list?
Do you even get how Android sucks in the European media if millions of taxpayer money are spent on some Corona alerting apps, but all of them do not reliably work because Google gives a shit about this feature?
vp...@gmail.com <vp...@gmail.com> #121
sh...@gmail.com <sh...@gmail.com> #122
am...@gmail.com <am...@gmail.com> #123
And here is mine
tz...@gmail.com <tz...@gmail.com> #124
[Deleted User] <[Deleted User]> #125
sh...@gmail.com <sh...@gmail.com> #126
su...@gmail.com <su...@gmail.com> #127
Suy Nop
aj...@gmail.com <aj...@gmail.com> #129
se...@gmail.com <se...@gmail.com> #130
ch...@gmail.com <ch...@gmail.com> #131
This is a major problem for us developers working on connected products. For example, we have a medical device that needs to periodically communicate with our app so we can display certain health information to the user every day without them having to launch the app manually. The way we're doing this now is via a foreground service. However, on almost all OEMs with adaptive battery, our app is automatically killed even with a foreground service running (implicitly already telling the user "hey we're running in the background!").
If we have a foreground service running, our app process shouldn't ever be killed, period.
pe...@gmail.com <pe...@gmail.com> #132
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 (due to OEM whitelists) is becoming a "defacto" standard.
See issue
This issue is already described at
ja...@google.com <ja...@google.com> #133
Thank you for the update. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.
lb...@gmail.com <lb...@gmail.com> #134
Here, various things on Samsung devices that might be related:
1. Fatal Exception: java.lang.InternalError: Thread starting during runtime shutdown
2. Caused by android.app.RemoteServiceException: Bad notification for startForeground
3. Caused by java.lang.RuntimeException: android.os.DeadSystemException
4. IllegalStateException: Not allowed to start service Intent
sm...@gmail.com <sm...@gmail.com> #136
Does your team has/had trouble understanding the problem or what needs to be investigated for years?
The severity and the priority of the issue suggest that your team does not understand the problem.. Or we don't know anything..
I (and lots of developers) would like to understand why there isn't any progress... and the problem is more and more serious.. the biggest fail related to this issue was notification and running problem of the official covid tracker apps some month ago. It's a shame. Before Android 11... and you are still investigate the problem.. No so problematic/serious enough? There may not be a manufacturer android where a simple notification works without workarounds.
What makes it acceptable for google that android works so differently depending on the manufacturers and it's not possible to make a simple and reliable app? I really don't understand
lb...@gmail.com <lb...@gmail.com> #137
Samsung
And Android 12 is making it even worse, encouraging the OEMs to continue with this terrible trend of reducing more and more what apps are allowed to do:
Why instead of making apps more capable, reduce the need for various workaround from users&developers, and punishing OEMs, you actually do the opposite, encourage them by adding more and more restrictions to Android, built in, "by design" ?
Please stop this behavior. Stop restricting Android and breaking apps (either directly or indirectly, by Google or by other OEMs) in the name of battery/privacy/security.
ja...@google.com <ja...@google.com> #138
Thank you for the update. We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.
da...@gmail.com <da...@gmail.com> #139
lb...@gmail.com <lb...@gmail.com> #140
Here, you can start on the famous website showing the list:
@139 Funny thing is that for IOS they improve and make more APIs to help with background operations, no? At least there you know what to expect, no? When documentation says something, it probably means that's the definite rule.
And on Android we see the opposite.
OEMs are encouraged to ruin how Android is supposed to work, and some of them are breaking the rules that are written right on the docs (see here:
What OEMs would say ? Probably: "Hey, Google does it too, so we want to make it better, reducing battery usage further".
co...@gmail.com <co...@gmail.com> #141
ku...@gmail.com <ku...@gmail.com> #142
Literally no strict quality standards on android. APIs change on every update, new android version every year with no improvements. And then just ignoring the issues which have been running since years.
lb...@gmail.com <lb...@gmail.com> #143
Here the companies do whatever they wish to the OS, ruining how it's supposed to work, having OS bugs by-design, and many times by-default, without any official way for developers to handle them. Even worse: Sometimes they don't offer users to do anything about it.
ts...@shipt.com <ts...@shipt.com> #144
lb...@gmail.com <lb...@gmail.com> #145
And as Google adds restrictions, OEMs say "why not", and add their own unofficial stuff that nobody can adjust to properly.
Google's own restrictions are hard enough to adjust to. Each new Android version has new restrictions for quite some time.
gr...@kochaniak.com <gr...@kochaniak.com> #146
If the "great battery life" is the holies of holy cows for Android device makers, why bother killing apps? Just turn off the phone and the battery will last forever! Oh, right, you need to get phone calls and texts, so instead make 1990s dumb phones!
Don't get me started on the new restrictions in each new Android version... "Scoped storage" anyone? I would boil in oil the person who invented this B.S.
so...@gmail.com <so...@gmail.com> #147
Where can i get finally the vr steam and Get download my buckup
tz...@gmail.com <tz...@gmail.com> #148
gr...@kochaniak.com <gr...@kochaniak.com> #149
Google support for app developers is NON EXISTANT. Keep it in mind, if you ask them a question, the reply will only cause aggravation, psychological trauma, disgust. Forget it, you will be worse off if you get their reply, than if you never asked. Expect in the best case only quote from their "policies". The technician will not even read your question, beyond the subject line, before replying.
And still, there is nothing better for mobile development than Android... I really don't want to be closed in Apples golden cage.
ka...@gmail.com <ka...@gmail.com> #150
I don't care anymore. Thanks just disconnect the damn thing.
On Sat, Mar 13, 2021, 2:57 AM <buganizer-system@google.com> wrote:
lb...@gmail.com <lb...@gmail.com> #151
It seems even on Samsung devices with Android 11, foreground services can be targeted:
mu...@gmail.com <mu...@gmail.com> #152
Sistem güncelleme hata veriyor
td...@gmail.com <td...@gmail.com> #153
Meanwhile famous apps like FB, Whatsapp, etc. seem to be whitelisted by default.
This reliability problem means that most of users are quick to move all their conversations to one of the famous platforms, which has heavily impacted our user retention on the app. "The messaging on this app is unreliable let's switch to famous_app". Users will often leave bad reviews, abandon the app and say things like "my other apps are working just fine why can't you guys notify me correctly".
It would be good for Google to better enforce FCM functionality on these OEMs, or at least provide some kind of notification to the users that their notifications aren't being delivered and a way to manually toggle it. We have tried doing it ourselves for a bunch of devices but it seems like a pain point a lot of people are facing at the moment.
To make things worse, it looks like some of these manufacturers are now rolling out their own "more reliable" notifications SDK. However, many of these non-FCM servers are in countries with significantly different privacy policies, which makes them non-starters.
la...@gmail.com <la...@gmail.com> #154
When I moved our mobile app development to Android and iOS nearly 10 years ago, I disliked iOS for being so restrictive about how it handled local notifications. Now, I love it. Not because it less restrictive, but just because it actually works consistently.
What is so difficult about introducing a permission that has to be confirmed by users (and that the app can prompt the user with as with other permissions), if this odyssey is about power management? If the user confirms the usage, than there should be no battery restrictions applied at all. Make it part of all android development/usage contracts to conform with the behavior, resulting in lawsuits against OEMs and device banning from all google services, if being violated.
Pretty simple to implement, to use and also very effective.
lb...@gmail.com <lb...@gmail.com> #155
This is just terrible...
tz...@gmail.com <tz...@gmail.com> #156
ad...@google.com <ad...@google.com> #157
Regarding
lb...@gmail.com <lb...@gmail.com> #158
di...@gmail.com <di...@gmail.com> #160
I don't know if it's specifically related to Chinese OEMs, but I often have issues with non-Google devices killing my app in the background even when a foreground service is running, and the mic is in use (i.e. the user clearly wants the app to not be killed!) It would be really great if this could be covered by CTS.
Thanks, I filled out the form as this still happens often. We've noticed significant quality problems on many non-AOSP devices with the microphone disconnecting or the app being force-closed after 30 minutes or other various timeframes. This does not happen commonly with Pixel devices (though I have noticed some mic-silence issues on those as well).
lb...@gmail.com <lb...@gmail.com> #161
Didn't expect it to reach XDA.
How cool
:)
Hopefully this will eventually mean that we won't need the website of
st...@drivequant.com <st...@drivequant.com> #162
I can confirm that many manufacturers (Xiaomi, Huawei, Oppo, Samsung, etc.) break apps running in background by killing foreground services.
Furthermore, Xiaomi also automatically declined REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
. Here is an example :
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
try {
val intent = Intent()
val packageName = activity.packageName
intent.action = Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
intent.data = Uri.parse("package:$packageName")
activity.startActivityForResult(intent, REQUEST_BATTERY_OPTIMIZATION)
} catch (e: ActivityNotFoundException) {
// Catch crashes on some Samsung devices
}
}
}
[...]
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
super.onActivityResult(requestCode, resultCode, data)
// UI System nevers prompts, resultCode is always 0 (equals cancelled user action)
}
mi...@gmail.com <mi...@gmail.com> #163
lb...@gmail.com <lb...@gmail.com> #164
Fatal Exception: java.lang.RuntimeException: Unable to start receiver ...: java.lang.SecurityException: Not allowed to start service Intent { cmp=... (has extras) } without permission Background bind not allowed
Here is one place that has complained about it:
se...@gmail.com <se...@gmail.com> #165
[Deleted User] <[Deleted User]> #166
sv...@gmail.com <sv...@gmail.com> #167
hu...@gmail.com <hu...@gmail.com> #168
ab...@gmail.com <ab...@gmail.com> #169
access
be...@gmail.com <be...@gmail.com> #170
ze...@gmail.com <ze...@gmail.com> #171
Please allow lol
ha...@gmail.com <ha...@gmail.com> #172
di...@gmail.com <di...@gmail.com> #173
I can confirm that Xiaomi devices in particular will silently remove and terminate an app that has started a foreground service as a result of a widget interaction. That completely breaks the app and goes against Android's guarantees...
[Deleted User] <[Deleted User]> #174
ti...@gmail.com <ti...@gmail.com> #175
Hello
ke...@gmail.com <ke...@gmail.com> #176
ro...@posteo.net <ro...@posteo.net> #177
Additionally, could apps detect whether they are running on a Xiaomi device and give a corresponding warning message at startup?
gr...@kochaniak.com <gr...@kochaniak.com> #178
di...@gmail.com <di...@gmail.com> #179
Adding a warning like that would only hurt app developers -- whenever anything goes wrong with an app, regardless of if it's the device's fault or not, users will blame the app first. Whenever there's issues I do send users to
kp...@gmail.com <kp...@gmail.com> #180
to...@gmail.com <to...@gmail.com> #181
tz...@gmail.com <tz...@gmail.com> #182
du...@gmail.com <du...@gmail.com> #183
gotei
ka...@gmail.com <ka...@gmail.com> #184
ka...@gmail.com <ka...@gmail.com> #185
bo...@gmail.com <bo...@gmail.com> #186
Welcome
bo...@gmail.com <bo...@gmail.com> #187
gr...@kochaniak.com <gr...@kochaniak.com> #188
we...@gmail.com <we...@gmail.com> #189
at...@gmail.com <at...@gmail.com> #190
ak...@gmail.com <ak...@gmail.com> #191
Meral Akkuş
di...@gmail.com <di...@gmail.com> #192
concerned?? Please let me know, I appreciate your immediate response to
this matter. Thank you!
On Thu, Oct 28, 2021, 1:21 PM <buganizer-system@google.com> wrote:
at...@gmail.com <at...@gmail.com> #193
concerned?? Please let me know, I appreciate your immediate response to
this matter. Thank you!
r/android
sh...@gmail.com <sh...@gmail.com> #194
al...@gmail.com <al...@gmail.com> #195
ru...@gmail.com <ru...@gmail.com> #196
.
pi...@gmail.com <pi...@gmail.com> #197
Jan 5, 2022 14:22am
ma...@gmail.com <ma...@gmail.com> #198
ch...@gmail.com <ch...@gmail.com> #199
in...@appyhapps.nl <in...@appyhapps.nl> #200
kh...@gmail.com <kh...@gmail.com> #201
iv...@gmail.com <iv...@gmail.com> #202
Noise
an...@gmail.com <an...@gmail.com> #203
concerned?? Please let me know, I appreciate your immediate response to
this matter. Thank you!
pl...@gmail.com <pl...@gmail.com> #204
ch...@gmail.com <ch...@gmail.com> #205
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!
so...@gmail.com <so...@gmail.com> #206
nu...@gmail.com <nu...@gmail.com> #207
un...@gmail.com <un...@gmail.com> #208
i try to record and save my Clipboard own handy and local storage for keep and save later in. permission kategory options
Android OS 10. Xperia from Sony 10. III
App Link:
ni...@gmail.com <ni...@gmail.com> #209
Im not a robot
mu...@gmail.com <mu...@gmail.com> #210
ng...@gmail.com <ng...@gmail.com> #211
lb...@gmail.com <lb...@gmail.com> #212
Documentation says that setting an app to be default CallerID on Android 11 will also grant it SAW permission, but on Xiaomi it doesn't do it.
Reported here:
ra...@gmail.com <ra...@gmail.com> #213
nu...@gmail.com <nu...@gmail.com> #214
ap...@gmail.com <ap...@gmail.com> #215
Hi
ap...@gmail.com <ap...@gmail.com> #216
Hi
am...@gmail.com <am...@gmail.com> #217
di...@gmail.com <di...@gmail.com> #218
Samsung devices are killing foreground apps, even when they have a foreground service and are recording from the mic, even on Android 12.
For some reason, getHistoricalProcessExitReasons only returns a record for the web view. The system killing the web view process also kills the entire app?
ApplicationExitInfo(timestamp=2022-04-06, 9:08 a.m. pid=20757 realUid=99039 packageUid=10283 definingUid=10283 user=0 process=com.google.android.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:0 reason=13 (OTHER KILLS BY SYSTEM) subreason=17 (ISOLATED NOT NEEDED) status=0 importance=300 pss=28MB rss=105MB description=isolated not needed state=empty trace=null
Example device that is doing this:
Board: msmnile
Brand: samsung
CPU ABI: [arm64-v8a, armeabi-v7a, armeabi]
Device: beyond1q
Manufacturer: samsung
Model: SM-G973W
Product: beyond1qltecs
Version codename: REL
Version incremental: G973WVLS6HVA1
Version release: 12
Version code: 31
lo...@gmail.com <lo...@gmail.com> #219
ha...@gmail.com <ha...@gmail.com> #220
-------- Pesan asli --------Dari: buganizer-system@google.com Tanggal: 22/04/22 21.45 (GMT+07:00) Ke: b-system+-1060464858@google.com Cc: hariono28061989@gmail.com Subjek: Re:
Changed
lo...@gmail.com added
Пчл науй
_______________________________
Reference Info: 122098785 Chinese OEMs constantly violating Android compliance
component: Android Public Tracker
status: Accepted
reporter: se...@gmail.com
assignee: cc...@google.com
cc: ad...@google.com, ja...@google.com, sa...@google.com, and 3 more
type: Bug
priority: P3
severity: S3
blocked by: 122246986, 191146997, 191148995, 193900967
duplicate issue: 123653024, 148005702, 151898476, 161008180, 161008181, 161096877
hotlist: [AOSP] assigned, adexe s nau
retention: Component default
ReportedBy: Developer
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
ko...@gmail.com <ko...@gmail.com> #221
Teşekkür ederim güzel bir uygulama Tebrikler çok güzel menmunum
ko...@gmail.com <ko...@gmail.com> #222
Teşekkür ederim güzel bir uygulama Tebrikler çok memnunum tavsiye ederim
ko...@gmail.com <ko...@gmail.com> #223
Teşekkür ederim ilgilenmiyorum
mu...@gmail.com <mu...@gmail.com> #224
by...@gmail.com <by...@gmail.com> #225
ro...@gmail.com <ro...@gmail.com> #226
Deleted
ch...@gmail.com <ch...@gmail.com> #227
da...@gmail.com <da...@gmail.com> #228
There is progress. It's just slower than you would like.
Google just announced at Google IO 2022 that Android 13 will have new features for restricting background usage to take what OEMs have been doing and take it into the platform.
There's even an unrestricted mode for apps that user can select, but it's their choice if they do. They have control and they have tools to check how much battery has been used.
This isn't something google can fix quickly. It's the OEMs fault and they did a lot starting from jobs scheduler, than work manager and now this.
Please stop complaining if you don't have anything useful to add, everyone gets notifications when you do.
Instead start to read documentation on how to write apps for background usage.
lb...@gmail.com <lb...@gmail.com> #229
There are just many made-up behaviors that break what's on Android from OEMs.
I know of Xiaomi, and even there it's too much. I'm sure there are many of other companies.
Here's what I've found so far for Xiaomi:
1. Auto-start:
2. show a pop-up in the background:
3. Default CallerID doesn't get to have SAW permission:
la...@gmail.com <la...@gmail.com> #230
lb...@gmail.com <lb...@gmail.com> #231
I hope these tests will include all the weird issues we all have faced.
My list is all of Xiaomi, as it's the only one that I've managed to notice:
I'm sure there are plenty of weird breaking of the rules on Android (by default), and killing of things that shouldn't be killed.
lb...@gmail.com <lb...@gmail.com> #232
te...@gmail.com <te...@gmail.com> #233
Regarding the article about CTS-D, there's a small detail in there: "Google also advises OEMs to utilize CTS-D to identify and reduce issues more quickly, although it's not a requirement that they pass these tests." I'm really skeptical that at least one troublesome manufacturer is going to utilize CTS-D.
lb...@gmail.com <lb...@gmail.com> #234
Still, it's better than nothing.
If anyone here finds the time and effort to make it, please submit and share links...
There are plenty of issues that developers have found of OEMs breaking behavior. Not always related to killing apps, even.
lb...@gmail.com <lb...@gmail.com> #235
Some notes about this:
1. Sadly foreground services are just one of many issues
2. I don't know if this test covers various kinds of foreground processes (NotificationListenerService, AccessibilityService,...) or just a normal foreground service. Probably just the normal one.
3. I don't know for how long the test works. Maybe an hour would be enough? For example, apps that encodes video files could reach such a long duration. Even longer. And they perform much more than increasing a counter...
4. Sadly according to what was written, this doesn't force OEMs to pass this test.
5. I hope there will be "hall of shame" for OEMs (or devices) that don't pass such tests. Maybe will be added to the dontkillmyapp website.
sw...@gmail.com <sw...@gmail.com> #236
[Deleted User] <[Deleted User]> #237
مودى محمد
ph...@gmail.com <ph...@gmail.com> #238
From
on 8/9/2022: issue 123653024
From
on 12/28/2018: issue 122098785
Which app are you using? Please share its Play Store link. Also mention the steps to be followed for reproducing the issue with the given app.
Can you share a bug report, after reproducing the issue ?
Frequency How frequently does this issue occur? (e.g 100% of the time, 10% of the time)
Android bug report After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method: After reproducing the issue, navigate to developer settings, ensure ‘USB debugging’ is enabled, then enable ‘Bug report shortcut’. To take bug report, hold the power button and select the ‘Take bug report’ option.
NOTE: Please upload the files to Google Drive and share the folder to
lb...@gmail.com <lb...@gmail.com> #239
tt...@gmail.com <tt...@gmail.com> #240
mh...@gmail.com <mh...@gmail.com> #241
Brand: Infinix Mobile
Device Name: Infinix NOTE 11
Model: Infinix X663B
Android OS: 11 (their AOSP fork is named "XOS", version V10.0.0)
THE ENTIRETY OF BOUND SERVICES IN THIS CRAPPY PHONE DON'T WORK NO MATTER WHAT YOU CHANGE YOUR PHONE'S BATTERY OPTIMIZATION/BACKGROUND PROCESS LIMIT(WHY IS THIS SETTING EVEN A THING?) SETTINGS TO.
If Google's goal is to make Android developers consider switching to iOS dev then it's working.
ch...@gmail.com <ch...@gmail.com> #242
am...@gmail.com <am...@gmail.com> #243
an...@gmail.com <an...@gmail.com> #244
Colleagues, I see many applications that have bypassed the murders. For example:
rk...@gmail.com <rk...@gmail.com> #245
Please take steps on it lot of people are affected with this problem this needs to be prioritized.
rk...@gmail.com <rk...@gmail.com> #246
bi...@mail.de <bi...@mail.de> #247
Why don't you guys not developing an battery saver as a part of android OS?
#245
They already do. It's there.
Manual settings for the user + permission model for the devs. Still kinda managable and both will know when they screwed up (either by restricting the app to much or forgetting to update to the latest permission model for (background-) services)
But OEMs be like: nah, we'll build our own, we can do better. We think the user doesn't know how to use it, so we'll force it onto them and use the strictes battery saving possible (oh that breaks apps? When they notice broken apps, they'll just blame the app devs. YAY!)
Same with other things yet to be discovered.
lb...@gmail.com <lb...@gmail.com> #248
Instead of restrictions to the platform, Google should add restrictions to OEMs.
sa...@gmail.com <sa...@gmail.com> #249
ab...@gmail.com <ab...@gmail.com> #250
آريد استعادة المبلغ المسحوب لأجل الاشتراك
ar...@gmail.com <ar...@gmail.com>
il...@gmail.com <il...@gmail.com> #251
I have only ran some basic tests and only on Xiaomi devices (not Oppp, Vivo etc yet) but this is a terrible scenario. Our app which is used in the health space collects some basic data using JobScheduler a couple of times per day. It does not consume any detectable battery when running on a Pixel phone and there it works 100% ok.
Our app is not a high-frequency use app so it might be days or even a couple of weeks between App usages by the user and if an update takes place during this time, all data between the update and the next time the user opens the app is completely lost because JobScheduler is killed by the update.
I suggested a CTS-D for this scenario but I have little hope it will change things.
he...@gmail.com <he...@gmail.com> #252
he...@gmail.com <he...@gmail.com> #253
is...@gmail.com <is...@gmail.com> #254
Isadora
ma...@gmail.com <ma...@gmail.com> #255
re...@gmail.com <re...@gmail.com> #256
vi...@google.com <vi...@google.com> #257
We recommend Xiaomi users to check the issue after updating their devices with the most recent OTA and Android OS version. If you are still experiencing the issue, please share a bug report and a screen recording.
lb...@gmail.com <lb...@gmail.com> #258
Users also can't notice what's wrong because they have no knowledge of how things are supposed to work on the apps. They are unaware of the documentation of Android.
Also it's not just one issue, and not just Xiaomi.
Just check it out. They've created their own made-up permissions , made up behavior, and as I've shown you, they also contradict what's documented on the Android website.
I've given you multiple examples. You can start with them.
su...@gmail.com <su...@gmail.com> #259
is...@gmail.com <is...@gmail.com> #260
Isadora
is...@gmail.com <is...@gmail.com> #261
Isadoracntonha2004
es...@gmail.com <es...@gmail.com> #263
mu...@gmail.com <mu...@gmail.com> #264
Hi
is...@gmail.com <is...@gmail.com> #265
Isadorasardinha66
is...@gmail.com <is...@gmail.com> #266
is...@gmail.com <is...@gmail.com> #268
Isadora 2
pa...@gmail.com <pa...@gmail.com> #269
ma...@gmail.com <ma...@gmail.com> #270
ma...@gmail.com <ma...@gmail.com> #271
en...@gmail.com <en...@gmail.com> #272
ca...@gmail.com <ca...@gmail.com> #274
sa...@google.com <sa...@google.com> #275
de...@gmail.com <de...@gmail.com> #276
This issue would be my #1 argument honestly if I'm trying to convince someone to go with an iPhone instead
da...@gmail.com <da...@gmail.com> #277
vi...@google.com <vi...@google.com> #278
Steps to reproduce
What steps are needed to reproduce this issue? Explain a bit more in detail.
Please share the details of the Chime app like play store link or the package name. If the app is not released on the play store then you can share a sample app/apk to replicate the bug.
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Screen record of the issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
sw...@gmail.com <sw...@gmail.com> #279
vi...@google.com <vi...@google.com> #280
Re-
vi...@gmail.com <vi...@gmail.com> #281
vi...@gmail.com <vi...@gmail.com> #282
Re-
Are you guys saying there's no way you could reproduce this issue at Google?
There are dedicated websites to offer a workaround for these issues. - I mean it in the nicest way, please get serious and introduce policies for OEMs who have their skins on top of Android. This issue is highly critical for everyone working on the Android platform. We had to work our way around into checking if battery optimization or app launch to show alerts inside the app to ensure they can still use it. The worst part is that our app is compared with WhatsApp, FB, and Instagram (which are whitelisted by the OEMs).
en...@gmail.com <en...@gmail.com> #283
they are aware of this issue, they just don't care.
lots of issues are open for several years and no action is made.
this issuetracker is just there to make you think, they care about, they just don't. it's a masquerade.
you just have vi...@gmail.com and some other, who just copy/paste the same responses over and over, they are either bots or employees who have no clue about what is android and development.
So no need to waste your time here.
fe...@googlemail.com <fe...@googlemail.com> #284
That's why I unstar this issue now. Watched it for years.
All the best to you, and will one day this issue be solved :-)
lb...@gmail.com <lb...@gmail.com> #285
ol...@gmail.com <ol...@gmail.com> #286
the net result both times was insulin delivery stopped and I slipped into Hyperglycemia in my sleep and woke up (fortunately) to alarms from high blood sugar. Not only is there some aggressive app killing going on, but it's somehow subverting my explicit "Do not optimise" configuration.
Additionally, Samsung doesn't expose the system bluetooth app (like they used to). So I can't apply the same settings to that. My system needs BT to be working 100% of the time.
Finally... there's no clear way to debug this so I'm left with trial and error with very little way to reproduce or confirm app killing via logs or alerts.
vi...@google.com <vi...@google.com> #287
Re-
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. You may upload to google drive and share the folder to
ma...@gmail.com <ma...@gmail.com> #288
I can face this problem on your app
vi...@google.com <vi...@google.com> #289
Re-
[Deleted User] <[Deleted User]> #290
wl...@gmail.com <wl...@gmail.com> #291
adb shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
is...@gmail.com <is...@gmail.com> #292 Restricted+
is...@gmail.com <is...@gmail.com> #293
Isadoracntonha
is...@gmail.com <is...@gmail.com> #294
Notm
da...@gmail.com <da...@gmail.com> #295
Ok, but how to solve it and use the app normally?
lb...@gmail.com <lb...@gmail.com> #296
This time with a simple thing, tested on "Honor magic 4 pro" with Android 13:
When you start the Intent of ACTION_APP_LOCALE_SETTINGS for your app, it just shows "Settings" and nothing is shown in it. No list of the languages you've set that works fine on other devices.
Please fix this too.
Add tests to gain license for each Intent that should be supported.
bo...@gmail.com <bo...@gmail.com> #297
pi...@gmail.com <pi...@gmail.com> #298
Го работать
lb...@gmail.com <lb...@gmail.com> #299
ACCESSIBILITY_DETAILS_SETTINGS, ACTION_ADD_DEVICE_ADMIN, USAGE_ACCESS_SETTINGS, USAGE_ACCESS_SETTINGS, APPLICATION_DETAIL_SETTINGS , ACTION_INSTALL_PACKAGE , REQUEST_APP_INSTALL , ...
And many more.
All can cause various exceptions.
ng...@gmail.com <ng...@gmail.com> #300
ng...@gmail.com <ng...@gmail.com> #301
ge...@gmail.com <ge...@gmail.com> #302
Ne vzat
om...@gmail.com <om...@gmail.com> #303
Tt
sh...@gmail.com <sh...@gmail.com> #304
ri...@gmail.com <ri...@gmail.com> #305
di...@gmail.com <di...@gmail.com> #306
How am I supposed to give them solution so that my app can work smoothly.
OPPO and VIVO phones are terrible for running a background service. They just kill your app don't even consider REQUEST_IGNORE_BATTERY_OPTIMIZATION optimization status of your application.
lb...@gmail.com <lb...@gmail.com> #307
Xiaomi has those made up permissions even on Android 14: "Auto start" , "Show on lock screen" , "open new windows while running in background", and so on...
Those need to be removed!
They need to follow the official documentation of Android.
They don't even provide their own API for them.
Countless of examples, and the more new restrictions Google adds officially, the more OEMs will make it even worse, unofficially .
sa...@gmail.com <sa...@gmail.com> #308
pu...@gmail.com <pu...@gmail.com> #309
Please start my YouTube
sh...@gmail.com <sh...@gmail.com> #310
You tube
de...@gmail.com <de...@gmail.com> #311
kg...@gmail.com <kg...@gmail.com> #312
Thanks for this ticket.
S3 is not enough , from my point of view.
Personal experience : Just received a Xiaomi Redmi 12 phone. With MIUI 14 based on Android 13.
Factory Reset > Enter my Android account. after 36 hours , I just realised that my Calendar notifications do not work consistently !
This is basic behaviour that anyone using Calendar would expect.
Thanks Xiaomi.
pa...@gmail.com <pa...@gmail.com> #313
Whats the point of WorkManger then if the devices kill the apps and can't run on background. I've tried to run a persistent background work and it stops working and does not work.
jo...@gmail.com <jo...@gmail.com> #314
za...@gmail.com <za...@gmail.com> #315 Restricted+
cr...@gmail.com <cr...@gmail.com> #316
N8
er...@gmail.com <er...@gmail.com> #317
N8
ca...@gmail.com <ca...@gmail.com> #318
It caused me a 1 star in one of my applications because they are a fundamental part of the app... which I took for granted, like, how come timers can stop silently? Android is a solid platform, right?
Welp, now we have such issues as this one, lol.
Also, this interferes with JobScheduler and AlarmManager, but the system apps work flawlessly because they exclude themselves from such restrictions.
So yeah,
Thank you Android, very thoughtful 🤙
jp...@gmail.com <jp...@gmail.com> #319
JP Rock
rc...@gmail.com <rc...@gmail.com> #321
on the issue?
Sincerely,
Randall Scott Colitz
On Wed, Jul 24, 2024, 07:45 <buganizer-system@google.com> wrote:
se...@gmail.com <se...@gmail.com> #322
al...@gmail.com <al...@gmail.com> #323
120
od...@gmail.com <od...@gmail.com> #324
oke
sa...@gmail.com <sa...@gmail.com> #325
Hello
sa...@gmail.com <sa...@gmail.com> #326
Hello
pe...@gmail.com <pe...@gmail.com> #327
I hope this message finds you well.
I am a developer at Truetym and I am reaching out regarding an issue we are facing with our time-sensitive background task, which is a core functionality of our product. Despite following the best practices outlined in your documentation—utilizing foreground services, AlarmManager, and other non-time-sensitive deferrable APIs such as WorkManager and JobScheduler—the task behaves inconsistently. Sometimes it runs as expected, but at other times, it does not execute as intended.
Given the critical nature of this functionality for our app, I would like to know if there is a more reliable solution for my use case or if it is necessary to consider removing this feature from our application.
I would appreciate any insights or recommendations you can provide to help us resolve this issue effectively.
Thank you for your attention to this matter. I look forward to your prompt response.
gp...@gmail.com <gp...@gmail.com> #328
Anyway I share my reason why I came here. I purchased an app (famous app )that is supposed to help learn and control phone usage. The App's floating timer & fixed notification doesnt work. I've tried bunch of settings to avoid battery restriction. I guess its skinned ROM breaking basic API, based on reading prior comments.
Since a device/OS intentionly breaking apps functionality why its playstore certified when clearly playstore apps cant function, certainly its not developers fault. My recommendation is to enforce this through playstore certification since thats something OEM cant modify and distribute. If google is afraid OEM will roll out own playstore, then win through competition not monopoly
ra...@google.com <ra...@google.com> #329
Reply to
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Thanks for the information. Please help us to fully understand the issue by providing the information below:
-
APK/App Name that you're developing and affected by this issue (*Required)
-
Device Make, Model (*Required)
-
Build Name
-
Android OS version (*Required)
-
Related API or developer doc (*Required)
-
Corresponding CDD/CTS info (if you have this info)
-
Description - What is the issue and how did it affect your app’s core functionality? Please include technical details and attach bugreports, logs, screenshots, etc. to help us identify the root cause.
-
Region - If applicable, in what region is the device-specific behavior affecting your app?
-
Steps to reproduce - Please provide the detailed steps to reproduce the issue on the device(s) listed above, as well as the expected result and observed result.
-
Expected behavior - If applicable, which section of the relevant Android CDD describes the behavior you were expecting? If the device does not properly support a public API or system behavior, please link to the documentation that describes the expected behavior.
-
Repro on other devices - Were you able to reproduce the issue on a Pixel device or other device running the same platform version as the device above? Which device?
-
Regression - Is the issue a recent regression from a previous working state?
-
Mitigation - What steps (if any) did you take to resolve or mitigate the issue?
-
Related issues - Is this issue already filed with an OEM? If so, what is the tracking number?
Please share bugreports and screenshots from Google Drive. Share files with
ro...@gmail.com <ro...@gmail.com> #330
I recommend that all responses posing an anecdote (rather than a response to one) include all of the information described in that template. Currently, few responses have been actionable.
tc...@gmail.com <tc...@gmail.com> #331
I am an Android Developer. I am reaching out regarding an issue we are facing with our time-sensitive background task, which is an important functionality of our Android Application, I have used foreground services to upload the files at server side using a server side API call, irrespective of Android App is in foreground state or background state or killed from the device back-stack.
In all other devices Foreground service is keep running though Android application is in killed state except the Chinese OEMs device, to be specific Xiaomi/Redmi device.
Specifically I have observed in Xiaomi/Redmi device when the Application is in foreground state or background state in those cases Foreground service is keeps running normally and notification is also displayed to intimate the user in device notification drawer.
But when the Application is killed from device back stack then immediately Foreground Service is getting stopped and Notification is gone from device notification drawer.
I have also used the Work Manager API with OneTimeWorkRequest but same observations have seen for Xiaomi/Redmi device.
Given the critical nature of this functionality for our app, I would like to know if there is a more reliable solution for my use case or if it is necessary to consider removing this feature from our application.
Thank you for your attention to this matter. I look forward to your prompt response.
Based on reply #329, required details furnished below:
APK/App Name: Liberty Stream On
Device Make, Model: Xiaomi 11 Lite NE
Android OS version: 13
Related API or developer doc:
ra...@google.com <ra...@google.com> #332
Reply on
Thank you for reporting this issue. For us to further investigate this issue, please provide the requested information mentioned in
sa...@gmail.com <sa...@gmail.com> #333
Thank you for reporting this issue. For us to further investigate this issue, please provide the requested information mentioned in
yc...@gmail.com <yc...@gmail.com> #334
Quiero eliminar el root
Description
As a company, we develop a library that collects sensor and location data from the device, sends it to our platform, and transforms it into meaningful information about the user (user habits, routines, etc.).
Over the past years, it has been painfully difficult to support Chinese OEM devices (Huawei, Xiaomi, etc.). These OEMs are modifying Android in ways that break core functionality. The default behavior of these devices is to forbid newly installed apps to send/receive broadcasts, acquire wakelocks, start services, set alarms, etc. in certain conditions (e.g. screen off), unless the user explicitly whitelists the app.
The problem with this approach is that users are not very savvy and unaware of this. The blame is therefore directed to developers. We explicitly need to detect the manufacturer, and guide the user to whitelist their app. Maintaining this for all manufacturers is a nightmare.
Additionally, these OEMs preload (and remotely configure) a whitelist of packages that are allowed to freely perform said actions. How is this fair to the rest of us?
Honestly, how is Google certifying these devices when the core functionality does not work out of the box?