Fixed
Status Update
No update yet.
Comments
au...@hexmode.org
Great, thank you for the update and analysis.
https://issuetracker.google.com/issues/122098785
ju...@gmail.com
I can just second this. This is the far most pressing issue of the Android ecosystem for developers and users and despite the Android's team promise to force OEM into being more transparent about the non-standard restrictions they are doing, nothing is really happening and the situation is worst and worst year a over year (with the only bright exception of Nokia)..
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 thehttps://dontkillmyapp.com/ project and in most cases it reaches them ex post when they are already angry with their developers.
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
gg...@google.com
Hello
ab...@gmail.com
Hello, big thanks for paying attention to this issue and to update internal reports! This is very much appreciated.
I think issuehttps://issuetracker.google.com/issues/122098785 should be updated. Maybe back in 2018 the issue was mainly with Chinese vendors (see issue title), probably due to the missing regulatory effect of Play Store causing lower app quality in that region.
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.
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.
ra...@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
br...@gmail.com
'still being investigated' can be just a joke. It's a 2-3 years issue and getting worse and worse. I'm also thinking I'd rather develop for iOS.
Take it more seriously. Are the covid tracker app not enough shame for you?
Take it more seriously. Are the covid tracker app not enough shame for you?
ad...@riftergames.com
"is currently still being investigated" hahahahaahahahaahahahaa
br...@gmail.com
redacted
[Deleted User] <[Deleted User]>
@6 Google, remember that it's not just things related to battery optimizations and killing of processes in weird situations. It has become way beyond this topic.
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:
https://issuetracker.google.com/issues/150627645
And this is on a relatively new Android version, and I'm sure it still exist on Android 11, and soon on Android 12.
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.
[Deleted User] <[Deleted User]>
Regarding
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?
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?
fm...@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.
fm...@gmail.com
help me
tr...@gmail.com
My use-case for foreground service with accelerometric data is Sleep tracking - tracking body activity - including tossing and turning and breathing during sleep and calculating sleep quality for the user. For that the app needs all ~100ms data from the sensor for the whole night..
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..
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..
ad...@riftergames.com
ra...@google.com
BTW there is an interesting consequence to the Samsung's non-standard Sleeping apps list implementation. Now most of us Devs have been fighting with the recent Android WebView crash introduced by the recent update of the WebView by Google.
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
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
tg...@gmail.com
Hello, there is growing evidence that Samsung uses ChimeraPolicyHandler to kill foreground services which are supposed to run in Android 11. Please check
https://github.com/urbandroid-team/dont-kill-my-app/issues/307
re...@gmail.com
After implementing the ApplicationExitInfo I am getting abnormal numbers of daily reports of my foreground service being killed by Chimera on Samsung devices.
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.
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.
sc...@gmail.com
@sebouh00@gmail.com, can I share the files attached in #1 with Samsung for review?
aw...@gmail.com
Yes, please do.
se...@gmail.com
thanks! shared with Samsung for analysis
Description
There's claims that people are clicking on ads on their android apps, which results in the advertised ad getting installed without their knowledge or consent. Such claim says that the google play install popup is never displayed, and that such mechanism is built into the OS itself.
I don't want to get into discussion if such mechanism exists intentionally or not, or what kinds of benefits it may or may not bring. Suffice to say, installing apps from ads without clear user knowledge is outrageous and undermines the perception of security of all android devices, impacted or not by this supposed back door.
Here's what patent 20190265958 is all about:
Pls see relevant thread onhttps://www.reddit.com/r/androiddev/comments/q4nltn/ads_are_now_able_to_bypass_google_play_to_install/
There's been enough speculation and little facts thrown into this issue. As such, I'm not able to provide any more information than presented in the reddit thread. I don't know how to get attention from Google's security team, but I'm confident they will be interested in finding a way to reproduce/exploit it and confirm it, or dispell and state that this is not a thing.