Battery Historian

Highly recommended article: Welcome to collect Android dry goods to share

##### Read five minutes, 10 o ‘clock every day, and learn for life with you. This is Android programmer

In this article, you’ll learn a few things about battery power in Android development:

Install Battery Historian 2. Collect Batterystats data 3. Data analysis using Battery Historian 4.Batterystats additional data 5. 6. What can Battery Historian do

This paper analyzes the basic usage and workflow of Batterystats tool and Battery Historian script.

Batterystats is a tool included in the Android framework for collecting battery data from devices. You can use ADB to dump the collected Battery data to your development machine and create a report that you can analyze using Battery Historian. Battery Historian converts reports from Batterystats into an HTML visualization file that can be viewed in a browser.

What’s it good for:

Shows you where and how the process draws current from the battery. Identify tasks in your application that can be deferred or even deleted to extend battery life. Install Battery Historian

The easiest way to install Battery Historian isto use Docker. About alternate installation methods (including building from source code). To install using Docker, do the following:

• 1. Follow the instructions on the Docker website to install Docker Community Edition.

• 2. To verify that Docker is properly installed, open the cli and enter the following command: Docker run hello-world

• 3. Run Battery Historian image using the following command:

Docker --run -p port_number:9999 gcr. IO /android-battery-historian:2.1 --port 9999

• 4. Navigate to Battery Historian in your browser to confirm that it is running. Addresses vary by operating system:Linux and Mac http://localhost/port_number For Windows http://123.456.78.90:port_numberYou will see the Battery Historian launch page where you can upload and view Battery statistics.

#2. Collect Batterystats data

Connect to your phone, open developer mode, and connect to ADB.

• 1. Reset batteryStats data

adb shell dumpsys batterystats --reset

The device always collects batteryStats and other debugging information in the background. Resetting clears old battery collection data.

• 2. Disconnect the device from the computer so that current is consumed only from the device’s battery.
• 3. Play with your app and perform the behavior of the data you want; For example, disconnect from WiFi and send data to the cloud.
• 4. Reconnect mobile phone dump data

adb shell dumpsys batterystats > [path/]batterystats.txt

• 5. Export the raw Bugreport data

Adb bugreport > [path/]bugreport.zip

Android 5.0/6.0 adb bugreport > [path/]bugreport.txt

• 6. Open and submit data for analysis Battery Historian

Analyze data using Battery Historian

After successful submission, the data is analyzed as follows

• 1. Add other indicators from the drop – down list.
• 2. Hover over the information icon to see more information about each metric, including keywords for the colors used in the chart.
• 3. Move the mouse pointer over the bar to view detailed information about the indicator and the battery status at a specific point on the timeline.

#4.Batterystats Additional data

Additional information in the BatteryStats.txt file can be viewed in the Stats section below the Battery Historian chart.

1. The System Stats TAB contains system-wide statistics such as cell signal level and screen brightness. This information provides an overall picture of what is happening to the equipment. This is especially useful for ensuring that no external events affect your tests.

2. The App Stats TAB contains information about a specific application. Sort the list of applications using the Sort applications drop-down list in the application selection pane on the left (Figure 3). You can select a specific application to view statistics using the application drop-down list below (Figure 4). Analyze Battery consumption using Battery Historian

Battery Historian provides an in-depth analysis of device Battery consumption over time. At the system-wide level, the tool views power-related events from the system logs in HTML form. At the application-specific level, the tool provides a variety of data to help you determine the behavior of a battery-depleted application.

This document describes ways to use Battery Historian to understand Battery consumption patterns. The document begins by explaining how to read system-wide data reported by Battery Historian. It then describes how Battery Historian can be used to diagnose and solve application behavior related to Battery consumption. Finally, it provides several hints about scenarios in which Battery Historian might be particularly useful.

Battery Historian provides a system-wide visualization of various applications and system behavior, as well as its relevance to Battery consumption over time

Of particular interest to this graph is the black horizontal descending trend line, which represents battery power, measured on the Y-axis. For example, at the initial time point of the battery level, around 6:50 a.m., the visualization shows a relatively sharp drop in battery levels.

At the start of the battery line, as the battery drops sharply, the display shows three things: the CPU is running, the application has acquired a wakeup lock, and the screen lights up. In this way, Battery Historian can help you understand what is happening when Battery consumption is high. You can then locate these behaviors in your application and investigate whether they can be optimized accordingly.

In addition to system-wide macro data, Battery Historian also provides spreadsheets and visualizations specific to each application running on the device. Table data include:

• The estimated power consumption of the application on the device.
• Network information.
• Wakelocks.
• Service.
• Process information.

These tables provide two dimensions of data about your application. First, you can see how your app’s power consumption ranks compared to other apps. To do this, click the device Power Estimation table under the table. This example examines a fictional application called Pug Power.

As the chart above shows, Pug Power is the ninth-largest battery-powered user on the device, and the third-largest application that is not part of the operating system. This data indicates that the application undertakes further investigations.

To find data for a particular application, enter its package name lower in the two drop-down menus under Application selection at the bottom left of the visualization

When you select a specific application, the following data visualization categories change to show application-specific data instead of system-wide data:

• SyncManager.
• Foreground process.
• Userspace Wakelock.
• Top app.
• JobScheduler.
• Activity Manager Proc.

If your application synchronizes and executes jobs more than necessary, the SyncManager and JobScheduler visualizations are immediately obvious. In doing so, they can quickly identify opportunities to optimize application behavior to improve battery performance.

You can also get more application-specific visualization data, user-space Wakelock. To include this information in the error report, enter the following command in the terminal window: ADB shell dumpsys batterystats –enable full-wake-history

Ps: Starting with Android 6.0 (API level 23), the platform includes the Doze feature, which implements some optimizations for applications. For example, No matter how JobScheduler schedules them, Doze will batch jobs during short maintenance periods.

Look at the visualization and it doesn’t show anything immediately. The JobScheduler line shows that the application has no scheduled tasks. The SyncManager line shows that the application has not performed any synchronization.

However, an examination of the Wakelocks portion of the tabular data showed that Pug Power took more than an hour in total. This unusual and expensive behavior can explain the application’s high power levels. This information helps developers target areas where optimizations can be of great help. In this case, why do applications get so much wakeup time, and how can developers improve this behavior?

What can I do here

Battery Historian can also help you diagnose opportunities to improve Battery behaviour. For example, Battery Historian can tell you if your application:

• Excessively frequent wake-up calls (every 10 seconds or less).
• Hold GPS lock continuously.
• Schedule assignments every 30 seconds or less.
• Plan to synchronize every 30 seconds or less.
• Use cellular radio more often than you might expect.

At this point, this has ended, if there is wrong place, welcome your suggestion and correction. Meanwhile, I look forward to your attention. Thank you for reading. Thank you!