This article is published by the Cloud + community
Author: Tencent Mobile Quality Center TMQ
1. Research Background
At Google I/O 2017, Google announced a new feature for the Google Play Administration Center: Android Vitals. When an app is running on a large number of devices, Android Vitals collects all sorts of anonymous data related to app performance, such as: Data related to app stability, app startup time, battery usage, rendering time, and permission rejection are analyzed and displayed in the Android Vitals Dashboard in the Google Play Administration center. Key metrics for Android Vitals developers to focus on are crash rates, ANR rates, excessive wakeups, and stuck wake locks. Pay attention to other indicators based on the application type (See Figure 1-1 for an overview of indicators on Android Vitals). Poor performance of some indicators of an app will affect user experience and lead to a low level and low ranking of the app in Google Play Store (see Figure 1-2 for an example of abnormal app indicators). Developers can improve their apps by analyzing some of the metrics provided in Android Vitals.
Figure 1-1 Check indicators of the Android Vitals platform
Figure 1-2 Example of an APP indicator exception
2. Details of core indicators:
In order to monitor the indicators of the APP, it is necessary to first make clear how the indicators are counted in Android Vitals. This section mainly introduces the basic concepts and calculation methods of the core indicators related to electricity quantity.
2.1 Stuck partial wake locks
A. Wakelock basic concepts:
In order to optimize battery usage, the Android system itself goes to sleep when there is no operation to save battery. For ease of development (many apps will inevitably want to run things after the screen goes off, or to keep the screen on — like playing videos), Android offers something called PowerManager.wakelock. WakeLock can be used to keep the CPU running, or to keep the screen from darkening/turning off, allowing the phone to do something without the user doing it. However, WakeLock is easy to get, and bad release can be a problem, consuming power.
For example, we grab a WakeLock to keep the CPU running, perform a complex calculation and upload data to a background server, and then release the WakeLock. However, this process may not be as fast as we think, because WakeLock is not released because the server hangs, an exception is calculated, and so on. The problem is that the CPU will not sleep, which will greatly increase power consumption.
Wakeup locks can be divided into and identify four types of user wakeup locks:
Starting with API level 17, FULL_WAKE_LOCK is deprecated. The application should use FLAG_KEEP_SCREEN_ON.
Relevant link: developer.android.com/reference/a…
B. Graveyard wake locks (partial wake locks)
Partial wakeup lock ensures CPU operation, but screen and keyboard backlight can be turned off. If an APP running in the background holds a partial wakeup lock for a long time, the partial wakeup lock will hold. This is a drain on device power because it prevents the device from entering a low power state. Android Vitals focuses on being stuck partial Wake locks, which alerts you through the Play Manager when your APP is experiencing a partial wake lock. Figure 2-1 shows an example of this. In addition, detailed statistical charts are provided from each dimension (figure 2-2 shows the distribution of the maximum duration of wake Lock in the background in each working period). Android Vitals reports a wakeup lock stuck when:
- At least 70% of battery sessions had at least one partial wakeup lock lasting at least one hour.
- When running only in the background, at least 10% or more of the battery sessions experienced at least one partial wakeup lock lasting more than an hour.
(PS: Battery session refers to the time interval between two battery charges. The Battery sessions shown on Android Vitals are the total battery sessions of all app test users.)
Relevant link: developer. The android. Google. Cn/topic/perfo…
Figure 2-1 Partial wakeup lock (background) of an APP
Figure 2-2 Distribution of the maximum duration of the background Wake Lock in each working period
2.2 Excessive wakeups
A. Makeup basic concepts
Wakeups is a mechanism in the AlarmManager API that allows developers to set an alarm to wake up the device at a specific time. When a wakeup alarm is triggered, the device comes out of low-power mode, and the Alarm Manager holds a partial wakeup lock while executing alarm’s onRecieve () or onAlarm () methods. If wake Alarms are triggered frequently, they run out of power. Android Vitals shows the number of over-wakes in the app.
There are four types of Alarm:
1)RTC_WAKEUP
At the specified time (when an Alarm is set), the device is awakened to trigger the Intent.
2)RTC
Fires the Intent at an explicit time, but does not wake up the device.
3)ELAPSED_REALTIME
After launching from the device, if the total time elapsed, the Intent is fired, but the device is not woken up. Elapsed time includes any time the device sleeps. Note that time has elapsed since it was last activated.
4)ELAPSED_REALTIME_WAKEUP
After starting from the device, the device wakes up and the Intent fires if needed after the elapsed time.
In Android Vitals, only RTC_WAKEUP and ELAPSED_REALTIME_WAKEUP are listed. Google will calculate the percentage of battery working time when wakeup occurs more than 10 times per hour (see Figure 2-3 for the example of excessive wakeup in APP). The number of Alarm Manager wakeup per hour was calculated by application version, wakeup flag, device, Android version, etc. (See Figure 2-4 for the distribution of Wackup per hour in each working period).
Figure 2-3 An example of an APP waking up excessively
Figure 2-4 Distribution of wakeup times per hour in each working period
3. Research on test methods
3.1 Review of traditional electric quantity test methods
We have also tested the power consumption of Tencent Video mainline version before, focusing on whether the power consumption of APP is normal in each scene from a macro perspective. The test methods adopted are mainly physical instrument test method and GT test method.
A. Physical instrument test method (ammeter, etc.)
Under the condition of constant voltage, the average current value of each scene is obtained to calculate the power consumption of the system. By using this method, it can be generally seen whether the power consumption of APP is normal. If the instrument is of high accuracy, the value of electricity measured by this method is the most accurate.
Defects: This method can only test the current of the entire phone, not distinguish APP, which is affected by many factors, such as screen brightness, volume, etc., so it is impossible to ensure that the environment of each test is completely consistent.
Figure 3-1 Measuring electric quantity with physical instruments
B.G T test method
GT (Portable Debug) is an APP portable Debug platform independently developed by MIG special test group. It is an “Integrated Debug Environment” (IDTE) that runs directly on mobile phones. By using GT, you can carry out quick performance test (CPU, memory, flow, power, frame rate/fluency, etc.), development log view, Crash log view, network packet capture, APP internal parameter debugging, real machine code time statistics, etc., for APP only with a mobile phone without connecting to a computer.
GT allows you to collect data related to mobile phone power consumption: current, voltage, power, temperature, etc. By analyzing these data, you can analyze the power consumption of the entire mobile phone.
Disadvantages: Similar to the physical instrument test method, GT test can only obtain the battery data of the whole phone, instead of focusing on a single APP, which is greatly affected by various factors.
3.2 Pre-study of international version electric quantity test method
Since the international version of the APP is released on Google Play, we need to pay attention not only to the normal power usage of the entire APP, but also to the wack lock and alarm usage of the APP. Therefore, the traditional electric quantity testing method has been unable to meet our needs, and we need to add additional testing methods on this basis.
A.Batterystats/ bugreport
With Android5.0, battery data is available via dumpsys batterystats. The basic formula for statistical power consumption of Android system is W=UIt. In a cell phone, U is generally constant, so it can be expressed separately as Q (capacitance) =I*t. The core BatterStatsImpl class provides the running time of each component of the App, and PowerProfile provides the current value of each component. Android component current information is stored in: In the power_profile. XML file, each OEM has its own power_profile. XML file. PowerProfile reads the file to obtain the current value of the access component (Figure 3-3 shows a model of Samsung power_profile. XML). The Android system takes UID as the unit to make statistics of CPU consumption, WAKE Lock consumption, mobile data consumption, wifi data consumption, wifi maintenance consumption, wifi scanning power consumption and each sensor power consumption. The battery consumed by The Wake Lock only counts the battery consumed by the Partial Wake Lock, which is exactly the type of wake up that we need to pay attention to. Therefore, we can test the case of the app holding the Partial Wake Lock by analyzing the battery data obtained by BatteryStats.
Android in order to facilitate developers to analyze the entire system platform and an app running in a period of time all the information, specifically developed the bugreport tool. The bugreport file records various log information about the process that the system allows, including power consumption information. The information that the APP holds Partial Wake Lock can also be obtained by analyzing the electron-related data in Bugreport.
Ps: RELATIONSHIP between Uid and App: If two Apps have the same signature as sharedUserId, they have the same Uid at run time. This means processAppUsage may be counting the power consumption of multiple apps, which is rare for regular apps and more common for Android apps.
Figure 3-2 Wack Lock power consumption calculation source code
Figure 3-3 Sumsung power_profile.xml
Data preparation:
- Disconnect the ADB service, and then start the ADB service.
(1)adb kill-server
(2)adb start-server
Restart the ADB command to be on the safe side, since battery logging opens a lot of things that could cause conflicts during development.
- Reset battery data and collect data
(3) adb shell dumpsys batterystats –enable full-wake-history
(4) adb shell dumpsys batterystats –reset
(5) adb shell logcat -c
Use the above command to enable battery data acquisition and reset, clear the interfering data, clear the history log.
- Power acquisition report
Unplug the data line to prevent the interference of charging and discharging data caused by the data line. Then do some test cases, after some time, reconnect the phone to make sure adb is connected, run the following command to save bugreport information to TXT file.
(6) adb bugreport >D:/bugreport.txt
Or use the following command can also be used, the content of the official website, by practice, cannot be read…
(7) adb shell dumpsys batterystats > batterystats.txt
Adb shell dumpsys batteryStats > com.example.app >batterystats.txt
Ps: Note that you must wait until the command is executed (slightly slow), and then open the bugreport. TXT file.
B.battery historian
The generated bugreport file is sometimes extremely large, can reach 15M+, think about a TXT file content length of 15M+ is a concept, if you use the text tool to open view will be a nightmare. As a result, Google has developed battery Historian for Android 5.0 (API 21) and beyond to parse the TXT file and render it in web graphics as a more user-friendly and readable application. We can use this tool to parse the bugreport file and get power data more easily.
Battery Historian can be installed as follows:
Github.com/google/batt…
Developer.android.com/studio/prof…
You can also use the online version directly:
bathist.ef.lc/
Data analysis:
(1) Choose Tencent Video APP
(2) The Wacklocks table shows the number of Wacklocks held by our app, for how long and how many. We can see if there are any wack_locks held by our app for more than an hour.
(3) The Wakeup Alarm Info table shows the name and number of Wakeup alarms triggered during APP operation. The analysis tool can also count the alarm wake-up times of APP.
C.QAPM
QAPM is a tool platform developed by SNG to liberate dedicated testers. The platform has a power monitoring function. In the power case menu, wackLock’s holding information is counted for both the front 30 minutes and the back 5 minutes. The data on this platform can be used as a reference object for our electric quantity test, and the specific statistical methods need to be further understood.
D.d umpsys command
Dumpsys tool provided by Android can be used to check the information and status of interested system services. After the mobile phone is connected to the computer, you can directly run ADB shell Dumpsys command line to check the battery and power information.
- adb shell dumpsys power
With this command, you can see all wack_lock holding information in the phone
- adb shell dumpsys alarm
This command provides information about the alarm system service on the device. Alarm Stats lists the Alarm Settings for the application, including the time consumed by all the alarms of the application and the number of times the Alarm is woken up. The number of times a user wakes up in an hour can be analyzed by taking power data over an hour.
Relevant link: blog.csdn.net/memoryjs/ar…
This method is similar to the burgreport file for power statistics. Both of them output power consumption through the tools provided by the Android system, and the output report in this way is also more complex and readable, which can be used as a reference in the test process.
4. Summary and practice of international version electric quantity test method
4.1 Summary of test methods
- According to the test method research in the previous section, we plan to first test whether there is any abnormality in APP power consumption in each scene by GT.
- The Bugreport files from the phone were then analyzed using battery Historian to calculate the number of Wack_locks held in the app for more than an hour and the number of wackps that occurred within an hour.
- The data collected in QAPM can be used as an auxiliary data for our analysis and we can compare the two to see if the Wack_lock data we have counted from battery historian is accurate.
- We can also use the dumpsys command to view the app’s battery information as a test aid.
4.2 Test method practice
Tencent Video International version 1.0.0 has been released, and we have used this method to conduct a battery test on it. The specific test process is as follows:
Atul gawande T test:
Test scenario: Start – Play – Foreground stand
Test machine: Nexus
Analysis of test results:
- As can be seen from the following current trend variation diagram, the current curve is stable in the process of playing and the stage standing, without large fluctuation or obvious abnormality.
- From play to exit play the front stand, the use of current significantly smaller, in line with expectations.
B.battery Historian Test:
Test scenario:
- The app foreground is left standing for 2 hours
- App background stands for 2 hours
- Full screen for 2 hours
Test Model:
- Y7 Pro 2018 (LDN-LX2)
- OPPO F7 (CPH1819)
Analysis of test results:
- In the three scenarios, the WindowManager wakelock will be held for more than 1 hour in the play-only scenario. However, Android Vitals focuses on the situation of holding partial wakeup lock for a long time when the app is running in the background, and this scenario can be excluded when playing. Therefore, it is concluded that the international version of app holds wakeup lock normally.
| scenario | models | Hold a Wack lock for more than 1 hour |
|---|---|---|
| The app at the front desk | Huawei Y7 Pro 2018 (LDN-LX2) | There is no |
| OPPO F7 (CPH1819) | There is no | |
| App background | Huawei Y7 Pro 2018 (LDN-LX2) | There is no |
| OPPO F7 (CPH1819) | There is no | |
| Full-screen playback | Huawei Y7 Pro 2018 (LDN-LX2) | WindowManager |
| OPPO F7 (CPH1819) | WindowManager |
\2. No alarm data is collected during the test, indicating that the AlarmManager scheduled task is not used in the international APP.
C. Test conclusions:
- GT current test shows that the power usage of various application scenarios of the international APP is normal.
| scenario | Start the APP | play | Exit playback, the foreground is still |
|---|---|---|---|
| conclusion | Images and other resources need to be loaded during startup. The current is large and normal | The current is stable and normal during playback | The current of exit play becomes smaller, and the static process is smooth without abnormality |
Analysis of Battery data shows that only one of the three scenarios, foreground stationary, background stationary and playback, can hold wack lock1 hour or more, which does not fall into the statistical category of Android Vitals. It will not affect the ranking of the international APP in the Google Play Store.
| scenario | models | stuck wake locks | excessive wakeups | conclusion |
|---|---|---|---|---|
| Let stand at the front desk | Huawei Y7 Pro | No wakeup lock stuck | Nontransitional awakening | normal |
| OPPO F7 | No wakeup lock stuck | Nontransitional awakening | normal | |
| The background of time | Huawei Y7 Pro | No wakeup lock stuck | Nontransitional awakening | normal |
| OPPO F7 | No wakeup lock stuck | Nontransitional awakening | normal | |
| play | Huawei Y7 Pro | Hold wakeup lock for more than 1 hour | Nontransitional awakening | normal |
| OPPO F7 | Hold wakeup lock for more than 1 hour | Nontransitional awakening | normal |
5. Summary and outlook
Because tencent video international version of the current function is less, use less wack_lock and alarm, we only tested let stand at the front desk, the background is static, played three scenarios, battery test results also show that APP electricity usage is normal, no part of the wake lock stuck and transitional sensei, subsequent international version function will increasingly rich, Test scenarios like push and download may need to be supplemented, and holding Wack_lock and alarm will be more complex, so we will continue to improve and refine our power testing methods as needed.
This article has been published by Tencent Cloud + community in various channels
For more fresh technology dry goods, you can follow usTencent Cloud technology community – Cloud Plus community official number and Zhihu organization number