WAI
Status Update
Comments
am...@google.com <am...@google.com>
am...@google.com <am...@google.com> #2
Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
am...@google.com <am...@google.com> #3
We've deferred this to a future release, but leaving this open for now.
s....@gmail.com <s....@gmail.com> #4
"We've deferred this to a future release, but leaving this open for now." - Whats the meaning ? will you update on this or known bug?
am...@google.com <am...@google.com> #5
For the first issue mentioned in the comment#1 here, is operating as per the design. Since, this only happened in doze mode. The FLP log bears this out. It appears the request is made, and almost immediately the phone is put into doze mode. As expected, no locations are delivered until the phone wakes up, and then the request is removed. The phone wake up happens after 5 minutes, which corresponds to the message delay used in the service handler. The handler is causing a wakeup, which would be because the phone keeps sleeping until manually woke up.
For the 2nd issue, location not delivered in doze mode is by design. When doze mode is active we do best effort location delivery, i.e, we deliver location if the phone wakes up anyways for some other reason, but otherwise we will not wake up the phone just to deliver location.
For the 2nd issue, location not delivered in doze mode is by design. When doze mode is active we do best effort location delivery, i.e, we deliver location if the phone wakes up anyways for some other reason, but otherwise we will not wake up the phone just to deliver location.
er...@spotangels.com <er...@spotangels.com> #6
Thanks for the feedback. I'm confused as to why the behavior is different when specifying an interval (2nd example), and in addition why is it inconsistent from one phone to the other. Shouldn't all phones receive at least one update when an interval is specified, considering they always receive one when it's not?
rk...@gmail.com <rk...@gmail.com> #7
But the Documentation says Doze mode doesnt affects Foreground service with Location notification. But the location just stops delivering still. In our App we have to keep an eye on User using our scooters and inform him, if user is in no ride zone or some other city council defined zones. With this restriction we are not able to do comply with the city laws . Is there any work around other than asking for white listing our app ? We are still targeting 28 . It only had problem with Pixel phones so far.
sc...@gmail.com <sc...@gmail.com> #8
I'm facing the same issue: no location updates are delivered when the device is in Doze Mode (using the Fused Location Provider API).
Is it still by design that location updates are not delivered in Doze Mode if using a Foreground Service when:
- the application is added to the Doze Mode whitelist
- the foreground service has acquired a partial wake lock to keep the CPU awake
?
I also tried disabling Battery Optimisations manually from the settings, still the location updates are not delivered.
I tested with API 26 (real device), API 28-29 (emulator, forcing the device into Doze Mode).
Is there still a way to receive consistent location updates starting from Android 8.0 (API Level 26) when the device is in Doze Mode ?
Thanks in advance,
Is it still by design that location updates are not delivered in Doze Mode if using a Foreground Service when:
- the application is added to the Doze Mode whitelist
- the foreground service has acquired a partial wake lock to keep the CPU awake
?
I also tried disabling Battery Optimisations manually from the settings, still the location updates are not delivered.
I tested with API 26 (real device), API 28-29 (emulator, forcing the device into Doze Mode).
Is there still a way to receive consistent location updates starting from Android 8.0 (API Level 26) when the device is in Doze Mode ?
Thanks in advance,
ch...@gmail.com <ch...@gmail.com> #9
How this can be behaving as per the design. In the documentation, it is clearly mentioned that if an app has Foreground Service running, the app itself considered as in the foreground. And for the app running in the foreground, no background limitations apply (Doze). See the attached screenshot of documentation which clearly says this.
Can you please either fix this or help us with how we can get location updates reliably in the background?
Can you please either fix this or help us with how we can get location updates reliably in the background?
ch...@gmail.com <ch...@gmail.com> #10
Whitelisting the app is also not an option as doing so also does not trigger any location updates in doze mode.
sy...@gmail.com <sy...@gmail.com> #11
How do spotify and other music streaming apps work around doze mode, their app use network even when phone is in doze mode. or is this a privilege?
Because for me nothing seems to work :
1 Wake Locks
2 White listing
3 Foreground service separate process (the services lives its task location tracking gets killed)
Because for me nothing seems to work :
1 Wake Locks
2 White listing
3 Foreground service separate process (the services lives its task location tracking gets killed)
an...@gmail.com <an...@gmail.com> #12
I'd like to have some answers too, this is driving mi nuts. I need to perform periodic network calls 24/7 for a research purpose app on wear os, it is not going to be published on the store. On a huawei watch 2 I can run it using a foreground service on a separate process and wakelocks, the same app on a ticwatch (we need to change model since the huawei watch 2 is discontinued) does not work in doze.
mn...@gmail.com <mn...@gmail.com> #13
ma...@gmail.com <ma...@gmail.com> #14
This really needs to be fixed, I have about 100 support tickets from users complaining that our radio station app stops playing between 2 and 20 minutes. We should be able to request a permission to disable doze mode for the app when they launch it. This has taken my app from a 5 star to a 2.5 star. My previous app was built with a much older version (no longer supported) and it didn't have this issue.
ma...@gmail.com <ma...@gmail.com> #15
This problem needs to be resolved by the google team or at least provide some workaround to solve this issue.
Thanks in advance..
Thanks in advance..
[Deleted User] <[Deleted User]> #16
I am only now, in the last few months since updating to target API 33, seeing issues here.
As more and more of my users move to newer API levels more and more of them are having this issue.
In my case it is even worse than just the background location updates not firing.
Even after opening the app up again manually while the foreground service is still running and should be sending updates, the app never sees a new location and my users are blocked from making any action in the app due to being outside of a set area.
As more and more of my users move to newer API levels more and more of them are having this issue.
In my case it is even worse than just the background location updates not firing.
Even after opening the app up again manually while the foreground service is still running and should be sending updates, the app never sees a new location and my users are blocked from making any action in the app due to being outside of a set area.
an...@neodigital.de <an...@neodigital.de> #17
Comment has been deleted.
ka...@gmail.com <ka...@gmail.com> #18
[Deleted User] <[Deleted User]> #19
6 Years and still no reply from Google.
Seems smaller apps with this issue are not considered worth it enough to warrant any action.
We follow all docs and best practices yet get the default response which is contradictory to the docs we follow and do not get the same performance as the big companies.
Seems smaller apps with this issue are not considered worth it enough to warrant any action.
We follow all docs and best practices yet get the default response which is contradictory to the docs we follow and do not get the same performance as the big companies.
Description
Test process:
Run a foreground service with a persistent notification.
Put the phone in deep sleep using ADB.
After a few seconds the service requests location updates using FusedLocationProviderClient with high accuracy.
When the phone is awake, location updates are received in time. When the phone is in deep sleep, at most one update is received, and in some cases none. Here are the issues I'm facing:
* First issue:
When doing a basic high accuracy request (all other parameters left unchanged) from a foreground service, only one update is received on a Nexus 6P (Android O DP3), a Nexus 5 (Android 6.0.1) and a Pixel (Android 7.1.2). No other update is sent in the next 5 minutes, even with a smallest displacement of 0.
* Second issue:
When I specify an interval for the request, no update is received at all on the Nexus 6P (Android O DP3) and the Nexus 5 (Android 6.0.1), regardless of the duration of the interval and even with a max wait time.
On the Pixel (Android 7.1.2), one single update is received pretty quickly (similar to when no interval is specified), and then nothing else.
GPS was on on all phones during testing. Everything works well when the phone is awake. Behavior seems identical when targeting api levels 25 and 26.
Reading all the documentation regarding location updates and deep sleep, it seems that a foreground service should get the updates as reliably whether the phone is in deep sleep or not, especially with intervals specified, so this behavior doesn't seem to be intentional, especially since other things like network access still work properly.
I enclosed a test project where you can start a foreground service that requests location updates after 15 seconds (leaving some time to put the phone in deep sleep) and logs the results.