The Battery Historian feature shows how a device’s battery consumption has changed over time. The programme visualizes power-related events from the system logs in an HTML representation at the system level. The tool gives a number of metrics at the app level that might help you discover battery-draining app activity.
Battery Historian may be used to learn about battery usage trends in a variety of methods, as described in this document. The first section of the document explains how to read the system-wide data that Battery Historian generates. After that, it shows you how to utilise Battery Historian to examine and debug your own app’s battery consumption habits. Finally, it provides numerous suggestions for situations where Battery Historian may be very valuable.
Take a look at the entire system.
The Battery Historian tool visualises different app and system activities throughout the whole system, as well as their relationship to battery use over time. Figure 1 shows a view that might assist you in diagnosing and identifying power use issues in your app.
Figure 1. Battery Historian’s display of entire system events affecting power consumption.
In the middle of the Battery Level line, as battery decline steeply, the display shows three things happening:
The CPU is on, an app has a wakelock, and the screen is turned on. Battery Historian helps you understand what happens when your battery usage is high in this way. You may then use your app to target these behaviors and see if there are any associated optimizations you can make.
Other insights may be revealed by the system-wide display. For example, if it is discovered that the mobile radio is frequently turned on and off, intelligent scheduling APIs such as JobScheduler or Firebase Job Dispatcher may be used to optimize this behavior.
View app-specific data
Battery Historian also gives tables and some data visualization for each programme that runs on your device. The following is a list of the tabular data, On-device power consumption estimates for the app.
- Network information.
- Wakelocks.
- Services.
- Process info.
To start, you can compare your app’s power utilization to that of other apps. To do so, go to Tables and select the Device Power Estimates table. This example looks at a programme called Unified Agent (com.nix).
Figure 2. The most power-hungry apps are being investigated.
Enter the package name of a specific app into the lower of the two dropdown boxes under App Selection, situated on the left side of the graphic, to hunt for data for that app. (Figure 2).
The following data visualization categories change to display app-specific data instead of system-wide data when you pick a specific app:
- SyncManager.
- Foreground process.
- Userspace Wakelock.
- Top app.
- JobScheduler.
- Activity Manager Proc.
If your app runs syncs and jobs more frequently than necessary, the SyncManager and JobScheduler representations make it clear right away. They can immediately uncover an opportunity to optimize your app’s behavior for better battery performance by doing so.
Userspace Wakelock is another piece of app-specific visualization data that you can get. Enter the following command in your terminal window to include this information in the bug report:
$ adb shell dumpsys batterystats –enable full-wake-history
A quick glance at the picture reveals nothing immediately noteworthy.. The JobScheduler line shows that the app has few jobs scheduled.
Pug Power, on the other hand, obtains nearly an hour’s worth of wakelocks, according to the tabular data’s Wakelocks segment. The app’s excessive power usage can be attributed to this uncommon and expensive behavior. This piece of information allows the developer to focus on a specific region where optimization is most likely to be beneficial. Why is the application acquiring so much wakelock time in this scenario, and how can the developer improve this behavior?