Fixed
Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #2
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 android-bugreport@google.com, then share the link here.
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.
as...@gmail.com <as...@gmail.com> #3
With all due respect, I do not have additional data to share. I can only point you to one of many complaints already made regarding this issue:
*https://www.theverge.com/2018/7/25/17614014/vlc-blacklisting-recent-huawei-devices-negative-app-reviews
*https://twitter.com/videolan/status/1022354204025860097
*
*
ta...@gmail.com <ta...@gmail.com> #4
Global developer
ma...@gmail.com <ma...@gmail.com> #5
Why are you fuck tards in my account. I’m sick of it. Did you get a good look at all my nude photos, as well as my children’s photos. Stop going through my private information. Especially my photos of my children, when they were just little babies and were nude. You make me sick. Apple Google. Suddenlink. Sprint. And the rest of you sick perverts. Stay off my 9 year olds phone. Sickening
ma...@gmail.com <ma...@gmail.com> #6
We have passed this to the development team and will update this issue with more information as it becomes available.
en...@gmail.com <en...@gmail.com> #7
We have CTS that OEMs pass in order to ensure compatibility, we are not sure if this request is for better CTS or just a complaint that aggressive battery management breaks some apps' core functionalities.
What use cases you want supported without having to get white-listed from battery optimizations?
What use cases you want supported without having to get white-listed from battery optimizations?
ma...@gmail.com <ma...@gmail.com> #8
This is a request for a better CTS to ensure OS core functionality is not selectively broken out of the box. If users chooses to limit certain functionality (running in the background, requesting locations, etc.), they can do so from the OEM's battery optimization settings. But having it disabled by default for a newly installed app reflects poorly on the app and the developer. Additionally, exclusive whitelisting of popular apps is poor practice and should be reprimanded by Google. There must be a policy ensuring that all apps are treated equally.
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.
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.
ar...@gmail.com <ar...@gmail.com> #9
For example: Huawei uses a launch mode for apps, by default automatically handled by Huawei. The default automatic launch mode prevents starting in the background (as foreground service), disables the working of the AlarmManager. Basic functionally correctly present in an app according to the Android specifications won't work without an explicit action of the end user to set the launch mode to manual and allow starting in the background, running in the background and starting other apps in the background (the last one for accessing another app service).
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.
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.
zi...@gmail.com <zi...@gmail.com> #10
Someone has made a site that documents all of the transgressions of various OEMs:
https://dontkillmyapp.com/
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.
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.
rc...@gmail.com <rc...@gmail.com> #11
More of that this absolute terrible situation for both users (seemingly broken apps) and developers (support nightmare).
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:
https://dontkillmyapp.com/
https://get.slack.help/hc/en-us/articles/360001562747-Known-issues-with-Android-notifications
https://bitbucket.org/copluk/acr/issues/607
https://news.ycombinator.com/item?id=18901006
https://hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a
Manufacturers have FORKED Android regarding background processes behavior.
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.
[Deleted User] <[Deleted User]> #12
Hi, just to add more. Here's about auto-start and opening of apps:
https://stackoverflow.com/questions/39366231/how-to-check-miui-autostart-permission-programmatically
http://nine-faq.9folders.com/articles/8772-how-to-manage-autostart-service-on-the-xiaomi-devices
http://en.miui.com/thread-1829332-1-1.html
https://stackoverflow.com/questions/42996646/how-to-enable-autostart-for-my-app-in-xiaomi-devices
The bad thing here, is that by default, they don't allow apps to auto-start themselves.
I wrote about it here:
https://issuetracker.google.com/issues/123653024
The bad thing here, is that by default, they don't allow apps to auto-start themselves.
I wrote about it here:
ra...@google.com <ra...@google.com> #13
Can we get some feedback from Google on this please?
ad...@gmail.com <ad...@gmail.com> #14
I`m a independent developer in China. It`s so hard to development any background app. Almost all OEMs change the Standard API Behavior. No tips to tell the users, No docs(or Intent for Setting) for developer. They just kill you.
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...
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...
ca...@gmail.com <ca...@gmail.com> #15
CTS certification should be revoked for phones with modified Android API behaviors.
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.
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.
Description
In the "Build media apps for cars" developer documentation the following code is presented for use in detecting if a phone is connected to an Android Auto head unit:
See:https://developer.android.com/training/cars/media#alarm
This code always returns false in Android 12. I have tested this across multiple devices with both the "Android Auto - Desktop Head Unit" and real head units.
Here is a repository with a very simple example using all of the latest and greatest dependencies:https://github.com/jaredandrews/Android12AndroidAutoDetectionFailureExample
The sample code simply launches an activity, runs
isCarUiMode
and prints the result to logcat. If you run this app on a device with OS < 12 andlogcat | grep TEST
you will see a correct log when you are connected or disconnected to an Android Auto Head Unit. If you run this app on a device OS == 12, it will always print "Running in a non-Car mode" regardless of Head Unit connection status.