Battery Life Recommendations
When you develop an app, you should always consider whether it is being a good citizen. An application is a good citizen when it is efficient, doesn't consume unnecessary resources, and minimally impacts the life of the device battery.
Being conservative with power consumption and having a great user experience aren't mutually exclusive concepts. In fact, being conservative with power usage might increase your user's satisfaction with your application.
Continue reading the checklist below to learn more about how you can make your app a good citizen and help to preserve battery life.
Monitor the battery and charging state
When you are making changes to reduce the strain on battery life, it is good to check the impact of running apps and app updates. Performing updates while a device is charging causes minimal battery drain, so you can create your app to maximise its update rate when the device is charging. You can also reduce the update rate when the device is not connected to conserve battery life.
You can use BatteryManager to broadcast battery and charging details. BatteryManager broadcasts whenever your device is connected or disconnected from power. These events can determine how often you start your app in a background state. To monitor changes in the charging state, register a BroadcastReceiver in your manifest to listen for these events by defining ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED. Generally, you only need to monitor significant battery changes. To do this, you can use the intents ACTION_BATTERY_LOW and ACTION_BATTERY_OKAY, so you can determine when to disable all your background updates. For the full tutorial, see Monitoring the Battery Level and Charging State.
The problem with using a BroadcastReceiver is that your app will wake up each time any of the receivers are triggered. However, you can disable or enable the broadcast receivers at runtime. This way the receivers you declared in the manifest are triggered by system events only when necessary. You can use the PackageManager to toggle the enabled state on any component defined in the manifest.
If you determine that connectivity has been lost, you can disable all of your receivers except android.net.conn.CONNECTIVITY_CHANGE, which informs you when the internet connectivity status changes. Once you are connected, you can stop listening for connectivity changes. You can use this technique to delay larger downloads by enabling a broadcast receiver that initiates downloads only after you are connected to Wi-Fi. For the full tutorial, see Manipulating Broadcast Receivers On Demand.
Stop animations when they're not needed
Although animations are important to the look and feel of most apps, they can affect the life of the device battery if they're overused. As a general rule, you should stop animations when they're no longer needed.
For example, consider an app that frequently requests remote data, or performs intensive operations, such as running SQL queries. Although it's important to provide a visual cue indicating that this process is underway, you need to consider how often the animation will run (such as a ProgressBar or your own animation). If the animation is running constantly, you might want to reconsider how you present this information to your users.
In most cases, you can replace an animation with a static image that the user recognizes and associates with a particular process. For example, in a mapping app, an image of a compass rose or an arrow might indicate that the app is currently receiving location updates.
For more information about animations, see Animations.
Be conservative with location requests
Unless your app needs to know the device's precise geographic coordinates at all times (such as in a mapping or navigation app), you should be conservative with how often you send location requests.
For example, consider a social networking app that tags updates with a user's current location. Or, consider a restaurant finder app that is designed to search for restaurants near the user's current location. In these instances, retrieving the location once when it's required is probably sufficient. While it might seem useful to have the user's precise location always available, this approach can cause a significant drain on the device battery.
For information about how you can retrieve the location of the device, see Retrieving the Current Location.
Push data to your apps
For BlackBerry PlayBook tablet, the preferred approach for receiving remote data is to use the Push Service. Push technology allows a server-side app to notify a client app when new data is available by pushing an alert with a small payload to the device. Using this approach, you conserve both processor power and network usage because the client app sends requests only when it knows there's data available. The result is an app that not only conserves battery power, but also has the added benefit of near real-time updates.
For more information about using the Push Service with Android, see Creating Push-Enabled Android Apps.