Take the following actions to[improve your app's impact on a device's battery life](https://developer.android.com/develop/sensors-and-location/location/battery)when using location services.

## Remove location updates

A common source of unnecessary battery drain is the failure to remove location updates when they are no longer needed.

This can happen when an activity's[`onStart()`](https://developer.android.com/reference/android/app/Activity#onStart())or[`onResume()`](https://developer.android.com/reference/android/app/Activity#onResume())lifecycle methods contain a call to[`requestlocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#requestLocationUpdates(com.google.android.gms.location.LocationRequest,%20android.app.PendingIntent))without a corresponding call to[`removeLocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient.html#removeLocationUpdates(com.google.android.gms.location.LocationCallback))in the[`onPause()`](https://developer.android.com/reference/android/app/Activity#onPause())or[`onStop()`](https://developer.android.com/reference/android/app/Activity#onStop())lifecycle methods.

You can use lifecycle-aware components to better manage the lifecycle of the activities in your app. For more information, see[Handling Lifecycles with Lifecycle-Aware Components](https://developer.android.com/topic/libraries/architecture/lifecycle).

## Set timeouts

To guard against battery drain, set a reasonable timeout when location updates should stop. The timeout ensures that updates don't continue indefinitely, and it protects the app in scenarios where updates are requested but not removed (for example, because of a bug in the code).

For a fused location provider request, add a timeout by calling[`setDurationMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setDurationMillis(long)), which receives a parameter that represents the time in milliseconds since the method was last called. You can also use the method to express the expiration time in terms of duration.

To add a timeout to a geofence location request, call the[`setExpirationDuration()`](https://developers.google.com/android/reference/com/google/android/gms/location/Geofence.Builder.html#setExpirationDuration(long))method.

## Batch requests

For all non-foreground use cases, batch multiple requests together. Use the[`setIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setIntervalMillis(long))method to specify the interval at which you would like location to be computed. Then, use the[`setMaxUpdateDelayMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setMaxUpdateDelayMillis(long))method to set the interval at which location is*delivered* to your app. Pass a value to the`setMaxUpdateDelayMillis()`method that is a multiple of the value passed to the`setIntervalMillis()`method. For example, consider the following location request:  

### Kotlin

    val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
    .setMaxUpdateDelayMillis(60 * 60 * 1000)
    .build()

### Java

    LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
        .setMaxUpdateDelayMillis(60 * 60 * 1000)
        .build();

In this case, the system computes location roughly every ten minutes and delivers approximately six location data points in a batch approximately every hour. While you still get location updates every ten minutes or so, you conserve battery because your device wakes up only every hour or so.

## Use passive location updates

In background use cases, it is a good idea to throttle location updates. Android 8.0 (API level 26) limits enforce this practice, but apps running on lower devices should strive to limit background location as much as possible.

It is likely that while your app is in the background, another app may be frequently requesting location updates in the foreground. Location services makes these updates available to your app. Consider the following location request, which opportunistically consumes location data:  

### Kotlin

    val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
    .setMinUpdateIntervalMillis(2 * 60 * 1000)
    .build()

### Java

    LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
        .setMinUpdateIntervalMillis(2 * 60 * 1000)
        .build();

In the previous example, the app's location computes roughly every 15 minutes. If other apps request location, the app receives the data at a maximum interval of two minutes.

While consuming location passively incurs no battery drain, take extra care in cases where the receipt of location data triggers expensive CPU or I/O operations. To minimize battery costs, the interval specified in[`setMinUpdateIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#public-locationrequest.builder-setmaxupdateagemillis-long-maxupdateagemillis(long))shouldn't be too small.