Fixed
Status Update
No update yet.
Comments
hu...@gmail.com
cm...@google.com
sl...@gmail.com
Great, thank you for the update and analysis.
https://issuetracker.google.com/issues/122098785
da...@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
xa...@google.com
ye...@gmail.com
Hello
ps...@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.
jo...@takealot.com
Thank you for the update.
We’ve shared your update with our product and engineering teams. Please provide any updates within the issue
da...@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?
fa...@gmail.com
"is currently still being investigated" hahahahaahahahaahahahaa
ak...@twophotonresearch.com
redacted
sr...@google.com
@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.
sr...@google.com
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?
ni...@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.
sr...@google.com
help me
ma...@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..
so...@gmail.com
sa...@gmail.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
mn...@upv.edu.mx
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
sa...@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.
ch...@gmail.com
@sebouh00@gmail.com, can I share the files attached in #1 with Samsung for review?
[Deleted User] <[Deleted User]>
Yes, please do.
sr...@google.com
thanks! shared with Samsung for analysis
Description
Importing OpenCV Android SDK (4.5.3) as a module is not possible in Android Studio Arctic Fox, while it works fine in Android Studio 4.2.2.
Problem and how to reproduce:
Problem: the Next and Finish buttons stay disabled. Only Cancel is enabled. The dialog cannot be submitted, hence the module cannot be imported. See screenshot_arctic_fox.
Arctic Fox info
Build: AI-203.7717.56.2031.7583922, 202107261959,
AI-203.7717.56.2031.7583922, JRE 11.0.10+0-b96-7281165x64 JetBrains s.r.o., OS Mac OS X(x86_64) v10.14.6, screens 6016.0x3384.0; Retina
AS: Arctic Fox | 2020.3.1; Kotlin plugin: 203-1.5.20-release-289-AS7717.8; Android Gradle Plugin: 7.0.0; Gradle: 7.0.2; Gradle JDK: version 1.8.0_181; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: 3.19.2
4.2.2 info