Develop Reference

Exclude Android app from being put into standby bucket

With Android 9 battery optimization has been pushed further and apps are classified into standby buckets depending on how much the user has recently interacted with the app (see Android documentation). The system limits the device resources available to each app based on which bucket the app is in.
How can I keep my app in the "working set" bucket, even if the user does not interact with it? (I do not find any permission or similar that allows to override this power management feature.)
More specifically, I have a PeriodicWorkRequest that must run once every 30 minutes with a flexibility of 10 minutes. However, if I understand the table of imposed power restrictions such a work request could be deferred up to 24 hours, if my app is put into the "rare" bucket. (Under the hood, the Work library uses the job scheduler.)
Further Details on the Scenario
The app is safety critical and not intended for public use but only meaningful to a restricted set of users. However, if anyone else uses this app nothing bad happens, but the app does not serve any purpose for him/her.
More precisely, the app is connected to the central fire alarm station of a specific building. All employees are asked to install the app on their smartphone. If the central fire alarm station of that building detects an event, it sends a push notification (via FCM) to all registered smartphones and the app plays an alarm sound. This implies nothing happens for (hopefully) a long time and the user has no intention to interact with the app in any way. The app itself does not provide any interaction, it only illustrates the current state (which is either a green "OK" sign or a red "ALERT" sign) and waits in the background for the rest of the time.
As the app is safety critical, the fault condition that the app looses the connection to the server must be detected. To this end, the server actually sends messages in the background periodically, i.e. a sequence idle, idle, idle, idle, alarm, alarm, alarm, alarm, idle, idle, idle, ... Normally, messages are broadcasted with low FCM-priority every 5 minutes. If the state changes, an additional message is immediately sent with high FCM-priority (cp. bold letters).
The app implements a watchdog using PeriodicWorkRequest as mentioned in the question above. This watchdog does twofold: Wake up the device and make the device receive all (low priority) FCM-messages that have been postponed and then check if the most recent message is not older than 1.5*5min. If this fails, the app tries to re-register itself with the server and waits if state messages start to come in again. If this fails too, the app presents a warning to the user.
Everything works fine so far. The only problem is the new kind of battery optimization which slows down the watchdog at some point of time. Of course, I could hand out a standing regulation that forces all employees to open the app once in a while and simply look at it, but that is a little bit silly.
I could re-phrase the question above: I totally understand why Android is pushing battery optimization to an edge. There are a lot of (insane) apps that have misused periodic tasks for purposes that should have been solved differently. And the web is still full of "idiotic" programming advises, like checking a specific webpage for modifications every 5secs. However, how am I expected to write safety critical apps that require a watchdog for legitimated purposes if battery optimization becomes more and more an obstacle. Google's thumb of rule "if the user does not use your app, it is obviously unimportant to him/her" does not apply here.

How can I keep my app in the "working set" bucket, even if the user does not interact with it?
You can't and you shouldn't. That same documentation says:
Do not try to manipulate the system into putting your app into one bucket or another. The system's bucketing methods can change, and every device manufacturer could choose to write their own bucketing app with its own algorithm. Instead, make sure your app behaves appropriately no matter which bucket it's in.
Even whitelisting won't work in your case because:
the whitelisted app’s jobs and syncs are deferred
There's this too:
Note: Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected.

If your app is site-specific and not distributed from the play store, you can ask your users to disable battery optimization for your app. That will exempt your app from the standby app bucketing system. Obviously it's not a great user experience to have to go through a bunch of menus to disable some obscure feature, but given that you are considering forcing users to open the app manually, disabling battery optimization would be preferable.

How to deal with Huawei's and Xiaomi's "battery optimizations"

I have an app that listens for notifications via NotificationListenerService. My app survives both the Doze mode and app stand by on almost any phone (if properly set-up e.g. exception or a foreground service).
Then come the Huawei and Xiaomi with their own modifications of Android to "improve battery life". These can mess with background running apps so badly that after a week or two the app must be reinstalled. Even clearing data will not "unfreeze" the app. Even exceptions to their own "optimizations" does not reliably fix this. Only completely disabling all their optimizations e.g. enabling "high performance mode" might fix this. But users do not want to disable these options.
How do you deal with these cases? And how can we stop manufacturers to stop messing with core Android? Not to mention the funny ANRs & crashes in Zygote :(

Then come the Huawei and Xiaomi with their own modifications of Android to "improve battery life".
Yes Xiaomi, Huawei and a few other manufacturers have their own layer of "Battery Saver" or "Security" that kills or restricts background running apps in order to improve security/battery backup, unless user white-lists your app in the relevant device settings.
What i found out about Xiaomi is that they white-list well known apps like Facebook, Whatsapp, etc. But you cannot request Xiaomi to white-list your app.
These can mess with background running apps so badly that after a week or two the app must be reinstalled. Even clearing data will not "unfreeze" the app.
These manufacturer apps simply terminate your app process. So your app should behave in such a way that termination at any moment should not create inconsistent state.
Also, you can always show a popup to user after installation asking him/her to go and white-list your app in battery saver. In Xiaomi, the user will need to select 'Do not restrict background activity' and also enable 'Auto Start' for your app. As far as i know, there is no other solution.
Let me know if you find one ;)

Android Gps Tracker not getting timely updates

I have an open source gps tracking application that has been around for many years. Recently, I have been getting complaints that in android nougat, instead of getting updates once a minute, people are getting updates from the phone once every five minutes when the phone is unplugged.
There is something going on with the power saver mode even though we tried turning it off.
Is there a way to force a phone to get gps updates at a specified time when unplugged?
Here is the code if anyone wants to see it but I don't think it's a problem with the code. It has been very stable for years.
https://github.com/nickfox/GpsTracker/blob/master/phoneClients/android/app/src/main/java/com/websmithing/gpstracker/LocationService.java
thanks.

One change in Android 7/Nougat was that the Doze is now "more aggressive". In Android 6/Marshmallow the doze mode kicked in when the screen was off, the device was running on battery and it was stationary.
(This is documented in Optimizing for Doze and App Standby)
Now in Android 7 the conditions are just screen off and running on battery.
(This is documented in Android 7.0 Behavior Changes)
Apps can be white-listed to be exempt of the restrictions if they break the core functionalility of it. In your case they do as the GPS tracker needs to record coordinates in real time.
There's a list of Acceptable Use Cases for Whitelisting
This includes:
Task automation app | App's core function is scheduling automated
actions, such as for instant messaging, voice calling, new photo
management, or location actions.
Users can white list an app manually on their own in the device settings or whitelisting can be requested by the app and approved or rejected by the user.
This is covered in Support for Other Use Cases
Quoting:
An app can fire the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent
to take the user directly to the Battery Optimization, where they can
add the app.
An app holding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission can
trigger a system dialog to let the user add the app to the whitelist
directly, without going to settings. The app fires a
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intent to trigger the
dialog.
The user can manually remove apps from the whitelist as needed.
The last point is important of course, but luckily the whitelisting status can be checked programmatically:
An app can check whether it is currently on the exemption whitelist by
calling isIgnoringBatteryOptimizations().
So, dealing with the Doze mode is one thing to study at least.
Another issue is keeping the Service running in general. But the Service getting killed by the system might result in more random time intervals. There are of course the classic things like using START_STICKY or running as a foreground service.

How does doze mode affect background/foreground services, with/without partial/full wakelocks?

This is a simple question, seeing that there is a huge post about this on G+ (here), and lack of information on official docs (here ):
What happens to the app's services when the device goes to "doze" mode?
What does it do to background/foreground services (bound/unbound, started/not-started), with/without partial/full wakelocks?
What would you do, for example, in order to create a service that plays an audio stream while the device's screen is turned off? What if the audio stream is not from a local file, but from the network?
Seeing that there was a claim by Google developer:
Apps that have been running foreground services (with the associated
notification) are not restricted by doze.
-yet a lot of discussion after that, claiming this is not entirely true, I think it's quite confusing to know what special background-operations apps should do.

Processes which have a current running foreground service are supposed to be unaffected by Doze. Bound/unbound, started/not-started, and wakelocks do not affect this whitelisting process.
However, there is an issue on Android M devices where foreground services are not properly whitelisted when the foreground service is the in the same process as the top activity and improperly dozed.
The fix is available on AOSP and will be included in builds of Android N. It would be up to OEMs to integrate that patch into any Android M builds they produce.

Doze app state implications for a voice recording app

I have an android app which records voice using a service - and a thread inside the service(obviously the app can record while in background..)
The app will be affected by the new Doze app state?
https://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases
I don't have a phone with 6.0 yet and the simulator cannot record voice in general...

If your service is running in the foreground (with an associated notification) when the device enters Doze mode, it should not be affected according to a comment by Dianne Hackborn to this post. See a documented experience that seems to prove this behavior here.
On the other hand, tests show, that access to certain sensors like GPS are restricted in Doze mode, so this might also apply to the microphone.
Since Doze mode is poorly documented up to now, unfortunately at this point you probably do not get around running your own tests on a physical device.

Yes, every app can be "killed" by Doze. If your service runs in foreground you can avoid App Standby however. Remember that asking to the user to put the app in the whitelist it's prohibited from Google Terms of services, so you can't do it. If you want to do something like that you need to add a permission to your manifest and with cross fingers hope in the Google review of your app.