Understanding basic battery drain

Earlier editions of Android OS used to run on Dalvik Runtime, which means apps used to compile at execution time. Post-Lollipop edition, Android has switched to Android runtime (ART), which means the apps are compiled beforehand, ensuring they are launched faster. ART, as the runtime, executes the Dalvik Executable format and dex bytecode specification. Apart from the launch, the entire consumer experience using the app is essential for app retention. One important feature is the battery - a dear feature of the phone.

An app which is greedy for power often finds itself in the position of either being uninstalled or lower rated when reviewed on the Google Play Store listing. Take a look at some of the most popular apps on the Store, including Facebook, which has had consistently bad reviews that quote battery drain as one of the top sources of user dissatisfaction. If your app has the reputation of being a battery hog, that might incur a loss of potential users that could otherwise be using the app. Android developers usually neglect the way that their app could impact the battery life of the smartphone. Not that it needs deeper insights in embedded systems, but a few tips can help you to appreciate the impact of an app on battery life.

If your app is one of the top drainers of the battery in the device, what's the best way to figure it out? The battery setting menu has an information resource to diagnose battery drain issues caused by mobile apps. Simply heading to Settings | Battery will provide the user with the necessary information in a graphical format, comparing consumption against time. The records are maintained since the last full charge status. There is also an interesting statistical overview of the applications that have contributed to battery drain:

Clicking on the graphs opens an extended section that shows how much time your device has spent in various cellular states. The different color patterns such as green, yellow, and orange indicate the signal strength. It also provides other information like active time using Wi-Fi, Device Awake time, and Screen On time.

A key observation you should make as a developer is of the state when your device is awake but the screen is off. This might be the result of a Wakelock or alarm that uses the device resources when the user might not be actively using the device. If this is frequently seen, it calls for some optimization. We will be talking about the Wakelocks and their impacts during the performance section of this book.