Tips for an Android: How to track location in the background and not to get killed?
We have been dealing with background location tracking many times in Dactyl. Because the solution is not always simple, we have prepared a few tips which were useful in practice. Let’s have a look.
The solution for occasionally tracking: WorkManager
The background location can be written down in many ways. If you need just an occasional tracking, you can use for example WorkManager. You can set different criteria such as a period or internet/energy availability etc. The minimal period of 15 minutes could be a minus. If you need to proceed constantly you will need to choose a background process – Service.
It needs more flexible solution
The most important thing for a successful background process is Foreground Service. It’s a service with the highest priority which has the lowest probability of ending by the system itself.
There is a pinned notification that gives information to the customers. The higher restriction from API 26 is set for the background so the classical services are killed after a few tens of seconds.
The support of this type of service with these new restrictions came from API 26. During the implementation of your service, you can set the way how to start API service by ContextCompat.startForegroundService(context, serviceIntent) command.
Even the top of the pyramid cannot guarantee that all processes will run smoothly. It’s good to implement your own detection to find out if the app was terminated unexpectedly (by the system) and to inform the user to turn off the regulation of background processes.
Problematic marks and devices
There’s a list of brands of devices on the Don't Kill My App website which gives information about apps that are the most problematic. If there was a problem with the determination, the cancellation of the app's power restrictions in the operating system settings can push him to perfection.
Every producer hides the restriction settings in a different place. That’s why it is good to focus on the most problematic and well-known brands. We had most problems with the Huawei brand which was also attacking the highest positions on the Don’t Kill My App’s list.
If you want to implement a service, you need to rewrite a few methods. One of them is onStartCommand where we take the START_STICKY value which will help us to restart the service by the termination.
We found out that for the position recording is good to use FusedLocationProviderClient instead of data provided just from the GPS using the LocationManager. Thanks to the combination of more than one position provider was the positioning process much faster and even more stable and more accurate. The settings of LocationRequest for the Provider gives you many parameters. The Provider provides you four modes. After their definition will the location be distributed to the onLocationResult callback.
An interesting solution for the cities
There were interesting results from a power-saving PRIORITY_LOW_POWER in the cities. It provides, thanks to using mobile BTS positions, satisfactorily determine the position of a user. You can find all these modes in This document.
The interval and fastestInterval parameters were defined on the same level. Definition interval value without fastestInterval provides the system worse adherence to the set period.
We are saving users battery
You can reduce battery consumption by an implementation of BroadcastReceiver. You also can, by setting actions BluetoothDevice.ACTION_ACL_CONNECTED or BluetoothDevice.ACTION_ACL_DISCONNECTED implement the message to the interface that the paired device was connected and thanks to this, you can promptly react by change of position settings or by starting the record.