Location updates can be registered for using criteria and a pending intent.
To receive location updates, applications can use the `requestLocationUpdates()` method. It may take some time before the first location update is received, so if an immediate location is required, the `requestSingleUpdate()` method can be used.
Location updates are received through callbacks or broadcast intents sent to a specified receiver. If a pending intent was supplied by the caller, then location updates are sent with a key of "" and a value of the pending intent.
The interval at which location updates are received can be controlled using the `minTime` parameter. The time between location updates will never be less than `minTime`, although it can be longer depending on the implementation of the Location Provider and the update interval requested by other applications.
Choosing an appropriate value for minTime is crucial to preserving the battery life of your application. Each location update operation relies on GPS, WIFI, Cell, and other radios for power supply. It is essential to pick a minTime value that is as high as possible while still providing a satisfactory user experience.
If your application is not currently in the foreground and you are displaying location data to the user, it would be wise to avoid using active providers such as GPS or WIFI. However, if you feel it is necessary, set a minTime of 5 * 60 * 1000 (5 minutes) or greater.
On the other hand, if your application is in the foreground and actively displaying location data to the user, a faster update interval can be considered more suitable. By selecting a shorter time period between updates, you can reduce the amount of power consumed by your app, thus extending the battery life of your device.
The minDistance parameter is a useful tool to control the frequency of location updates. It can determine how frequently your application receives location information from the location provider. If the value of this parameter is greater than 0, it means that the provider will only send you an update when there has been a significant change in the location by at least minDistance meters, and a minimum amount of time, i.e., minTime milliseconds have passed.
However, using the minDistance parameter can be more challenging for the location providers as it requires them to save power. Therefore, it is recommended to use minTime as the primary tool for battery conservation instead. This parameter ensures that the provider does not constantly try to upload the location data to your app if there are no significant changes in the user's movement. Instead, it sends updates at regular intervals based on a pre-defined time frame, thus reducing battery consumption.
In conclusion, while the minDistance parameter can help control the frequency of location updates, it can be more effective to use it in conjunction with minTime to ensure both optimal performance and energy conservation.
If your application is interested in tracking changes to the user's location made by other applications, but does not wish to consume excessive power in the process, then you should utilize the passive location tracking approach. This strategy relies on the system's built-in location providers, which do not require constant interaction or active modifications. As a result, you need not be as cautious about setting minimum time and distance thresholds.
However, if your app performs intensive work based on location updates (for instance, network activity), it is advisable to specify non-zero values for minTime and/or minDistance. This approach helps to regulate the rate at which updates are processed. In the case where an alternative app enables a location provider with exceptionally fast updates, such restrictions ensure that your application's workload remains manageable and does not exhaust device resources unnecessarily.
If the user disables the provider, location updates will stop and a provider availability update will be sent. However, as soon as the provider is re-enabled, location updates will resume immediately and a provider availability update will be sent. Providers can also send status updates at any time with extra information specific to their implementation.
If a callback was provided, then status and availability updates are made through either , or . Alternatively, if a pending intent was supplied, then status and availability updates are broadcast intents with extra keys of or .
It is important to note that when using a Looper to handle the delivery of callbacks, it must be specified in order for the calling thread to function properly. In particular, if a Looper is specified but without an associated Looper instance (such as the main thread of the calling Activity), then the calling thread must already be a Thread class such as one returned by the Thread constructor or by the getMainThread method of ActivityManagerService. If a Looper is specified along with a Handler instance, then callbacks will be made on the supplied Looper thread.
Prior to Jellybean, the `minTime` parameter was merely a hint. It meant that some location provider implementations chose not to follow it. However, starting from Jellybean and moving forward, all Android devices must adhere to both `minTime` and `minDistance` parameters as they are mandatory for compatibility with these devices.
