I have an app which updates the location to a web service every 10 seconds. However, on devices with API level 23 or greater, when doze mode kicks in after 15 minutes to inactivity, the network connectivity is lost, and the app becomes unable to send further location updates to my web service.
Other than whitelisting the app by asking for user permission to ignore battery optimizations, which only allows a location update once every 15 minutes, what are my other options to keep getting GPS location updates and be able to send them to my web service?
Though it is highly immoral to overcome doze mode, if the app can explain the issue with the battery to the user then it is better to whitelist the app.
The other option is to keep the screen on to avoid doze mode from getting triggered.
getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
This piece of code will keep the screen on. Make sure to create a black or empty layout like what battery saver in pokemon go does.
The Official Doze documentation allows whitelisting for your use case. Check it here.
You're running way too often to begin with. There's no phone that even updates location that fast- normal would be once every 30 to 60 seconds. So 2/3 to 5/6 of your updates are pointless. Ignoring that- if you're in a car going 60 mph you aren't going to change by more than 14 feet in 10 seconds. There's absolutely nothing you're doing on the server that needs to be accurate to 14 feet- the typical GPS in a phone is only accurate to 10 meters (over 30 feet). That's one of the reasons why GPS doesn't update more frequently.
But no, there isn't. They implemented Doze for a reason. It saves battery. They set it up so you can't get around it without asking the user if they want to burn that battery. I definitely understand why 15 minutes is too slow, but then you ask the user and let them decide if your app is worth it.
Related
I have been following https://developer.android.com/guide/topics/connectivity/wifi-scan guide in order to create a Wi-Fi scanner. I am using a foreground service with a handler to call wifiMananger.startScan(); every 30 seconds (I tried with 15 minutes).
Everything works great for about 2 hours then suddenly WifiManager.EXTRA_RESULTS_UPDATED boolean returns false and the wifiManager.getScanResults() are not getting updated. Then as soon as the phone is plugged in it starts sending results again. (No, it is not low on battery)
I have battery optimization turned off. I have all of the required permissions allowed. Locations is turned on with Wi-Fi scanning enabled. The device I'm testing on is a Samsung S7 Edge running Android 8. So I know it's not the new OS. (I also tested with a Nokia 5.1 running Android 10 with pretty much the same results).
Does anyone know why this is happening or has anyone encountered this issue before?
Thanks in advance.
Updated: In case of your problem, since you are using exactly 30 seconds due to some problem there might be more than 4 time in a 2 minutes period, make it like 35 seconds and test the result.
Original Answer: From this WifiManager startScan throttled in P Beta (Developer Preview 2) :
"Call Limitations - Throttling
We are further limiting the number of scans apps can request to improve network performance and improve battery life.
The WifiManager.startScan() usage is limited to:
Each foreground app is restricted to 4 scans every 2 minutes.
All background apps combined are restricted to one scan every 30 minutes."
It is said that this restriction is due to the battery drain, so it is normal to remove the restriction while charging.
Read more about throttling in official documentation.
This is because Android OS enters the infamous "Doze mode". I recommend you to look through the official documentation/explanation.
Unfortunately, there is no way around this. It will also affect any kind of a foreground service and pause it for longer periods. Doze mode will only trigger if the screen is locked and the device is not plugged in.
I encountered the same issue on my project and we implemented a periodic check. If the screen is locked and device not plugged in for a longer period of time, we show a notification asking the user to either plug the device in or open the app so the service could keep working. The implementation is a bit lengthy, but if it is what you decide to go with, I can update the answer with some of the code (using the AlarmManager within a BroadcastReceiver to achieve this).
Premise
The user should always be informed of the use of his sensitive data (like collecting the location in the background), this question aims to better understand the latest limitations introduced on Android use of location and background operations.
Problem
Is it still possible (on Android latest versions) to create a location tracking service that would keep tracking the device location no matter the application state (foreground / background) nor the device state (doze or standby mode, app buckets) in order to be able to collect location in a consistent way ?
Assuming that the GPS and internet connection are enabled and available, is it possible to collect the location, let's say every 10 minutes, or the device going to doze mode or standby will anyway restrict the app possibilities after some time and defer the operations (like network operations), making it impossible to keep getting regular location updates ?
On latest android versions, starting from Android 8.0 (API 26), new ways to improve battery performance and secure the users privacy have been introduced:
Background limitations
Background location limits
App standby buckets
What I tried
From my understanding, a foreground service looks like the best option:
keep informing the user (notification)
the system does not kill the service after a few seconds (as for background services starting from API 26)
less likely to get stopped by the system (START_STICKY flag to restart otherwise)
can acquire a wake lock
Still it seems that the app needs to be whitelisted to avoid battery optimisations and even battery optimisation need to be disabled in order for the service not to be stopped/deferred.
Expected result
Receive location updates at regular intervals, every 10 minutes for instance
You have to use FusedLocationProviderClient in a service to give you location in specified time intervals or distances. If you choose distances you have to watch location accuracy as well. See this article.
My service records the location of the user and sends it to Firebase every X minutes. I have tried changing X from 1 minute to 5 minutes, however the change in battery drain was less than 1 percent. In both cases it works out at about 5% used by the app every 3 hours.
I am trying to understand how increasing the GPS interval by 500% had little or no impact on the battery life. Not only is the GPS firing 1/5 of the time, but there is also 1/5 of the data being sent/received to Firebase.
When the watching location is turned off, battery drain is 0.
Any ideas as to what is causing the drain? Also, what kind of battery drain should I be looking at for getting a GPS location every 5 mins and sending about 50 bytes of data with it?
An immediate concern is how you connect to Firebase. Keep in mind that Firebase will keep an open connection to the server from the moment you call new Firebase(...). If you only want to periodically send/listen for data, you'll needlessly be draining the battery.
You can programmatically manage the connection state with goOffline()/goOnline().
If you're only sending updates, you can use the Firebase REST API to write the updates. This won't keep an open connection, or at least leaves it up to Android to determine when to close the connection.
Turned out the major cause was the mobile data. As soon as I made it require wifi to use firebase the battery drain dropped from 20% a day to 2%.
I'm trying to develop an Android app that among other things, uses location services to get user location and sends it to a remote server. The user can turn this feature on and off according to his own will, but as long as it's turned on, it will get user location periodically (maybe each 30 seconds, don't know it for sure yet). Also, while it is turned on, it must keep tracking the user even if the application is closed.
So far I've considered 2 options:
Option 1 - Use Service, call startForeground to make sure Android don't kill it (the sticky notification is not an issue to me) and use a LocationListener with the said interval, but this seems rather inefficient as the service would be doing nothing most of the time, I mean, the listener would be called each 30 seconds, send the location to the server and the service itself would spend the next 29.9 seconds or whatever just waiting for the next location.
Option 2 - Doing some research, I've seen some approaches using AlarmManager to trigger some background service (like seen in this post), but I'm concerned that using alarms that often (every 30 seconds) might not be good for the battery and system general performance (in a code snippet in this page of Android's Developer guide there's a comment saying that "hopefully your alarm will have a frequency lower than 30 MINUTES").
Maybe there's another option that I still haven't thought about, or maybe there's a way to put the service from option 1 to sleep for some time or something like that. Bottom line, I'm looking for the approach that doesn't impacts on performance, consumes the minimum amount of battery and has the least chance of being killed by Android.
Any help and/or suggestions are welcome.
I have application which for every 10 seconds do some request to server (http client). I read a lot about application life cycle. My application has service with foreground flag and it's work well (application work all time) when android is "active". I don't have phone with real android, so I am testing on emulator, but my friend testing it on smartphone and he notice that when he leave his phone, request are post for 10, 30 minutes, even hour. If he turn on screen, then request time is back to 10 seconds (he have access to server so he see logs). Is this known behavior? Because he installed gmail notifier from google, and this same problem (big delay). Any solution for this? My service have timer task (so request is sent in async task)
Regards
First of all, if you're polling every 10 seconds, that's gonna drain a lot of battery and network bandwidth.
I recommend using a lower frequency or server push.
For the polling issue, how do you implemented the polling ?
Do you use timers ? if so, what options do you pass in ? Or do you use a thread that sleeps for 10 seconds ?
Depending on the version, Android may turn off all processes, or delay network requests to run every 30 minutes to preserver battery power and bandwidth. (Starting up the network components drain a lot of battery than keeping them running. So If your app turns ON network, do a poll, then simply turn it off, Android may schedule it to align with all other requests on the system.)
Can you provide us more info about how you do the polling ?
UPDATE
You might have to schedule a 'WakeLock' so android knows when to wake up for your service. I think, by default, android doesn't wake up for timer requests that are scheduled very frequently and it schedules them as I explained. WakeLocks on the other hand can force android to wake up.
See this question and WakeLock Documentation
Make sure you pass the correct parameters, so you don't turn the screen ON. (Would be really annoying.)
UPDATE
I still recommend using server push for this, which will save battery and bandwidth while keeping the updates real time.