1ce1d3a42ce50ec6ac50b4c881b1dc8ace928e85 |
|
20-Sep-2017 |
Mike Ma <yanmin@google.com> |
Add AOD metrics in batterystats Fixes: 64899521 Test: manual - flash build, reset batteryStats, use device > 1 hr with alternating pattern between screen on/off/AOD. Dump stats, check all screen related stats look normal, esp. record matches actual time spent in each screen state. In raw bugreport: Search "amount discharged" for % discharge; Search "Screen on/off/doze discharge" for mAh discharge; Search "time on battery" for up/real time in each state. Test: Added two unit tests for note AOD screen state Merged-In: I7193a36751124dd380818b2b665303c0f0d8c984 Change-Id: I51cead7f92abd9e4c620f7dfde393993cdad494e
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
4c0900102b39c2e49afbeca0f7c87973e7b1a720 |
|
25-Jul-2017 |
Ajay Panicker <apanicke@google.com> |
Merge "Batterystats handles nested unoptimized ble scans" into oc-dr1-dev am: aaf3860941 Change-Id: I627a6da4db6eb09b68e23882ccef2de4c80bf747
|
94c5a313d7313a9a88abdf4267af43b87deb0dd2 |
|
12-Jul-2017 |
Bookatz <bookatz@google.com> |
Batterystats handles nested unoptimized ble scans When a ble scan starts, it tells batterystats whether that scan is unoptimized. When the scan stops, batterystats is not informed of whether the stopped scan was unoptimized. Because the ble scan call could not be nested (couldn't call start twice without stopping first), this was fine, but now nesting is possible, so batterystats needs to know whether the stopped ble scan is unoptimized. Bug: 63456783 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Test: no new errors when run cts-dev -m CtsIncidentHostTestCases -t com.android.server.cts.BatteryStatsValidationTest#testUnoptimizedBleScans Change-Id: Ia73f294cf1807ddaf20f1c0bcc28add001cac78c
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
94326cb56aa0c7cee110d6781fb8b8f16fb09663 |
|
29-Jun-2017 |
Dianne Hackborn <hackbod@google.com> |
Add reporting of how jobs complete. In both battery stats and job scheduler statistics, keep track of the reason jobs are ending. This can help to identify apps that are having bad behavior with jobs (in particular, regularly timing out their job instead of finishing it when done). Test: manual Change-Id: Icc12d5e0dc0df1906716e7d995c56d50a9fa148a
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
b1f04f372c42114e864d52f4206ff07d9264c5b9 |
|
19-May-2017 |
Bookatz <bookatz@google.com> |
Batterystats track background bad ble scan time Allows tracking ble scan time (total and background) for unoptimized scans. Whether the scan is unoptimized is provided by the bluetooth code when calling batterystats. Bug: 38461344 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Test: run cts-dev -m CtsIncidentHostTestCases -t com.android.server.cts.BatteryStatsValidationTest#testUnoptimizedBleScans Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest Change-Id: I814482ff663424170eac4b413464d24c14a5cf91
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
c8c44960c0051dacac0a6cb6c65ddfafc9d1cb84 |
|
11-May-2017 |
Bookatz <bookatz@google.com> |
Cumulative wakelock time per uid Currently, the time for each partial wakelock was tracked. If one wants the total time that a uid held partial wakelocks (over all of its wakelocks), they could sum over all the uid's partial wakelock totalTimes, but this would underestimate the value because totalTimes are pooled amongst all uids. Alternatively, they could sum over all the uid's partial wakelock totalDurations, but this would overestimate the value because totalDurations are not pooled within the uid (so there will be double-counting if two wakelocks are held simultaneously). This cl adds a new timer that specifically tracks the actual total time that the uid spent holding wakelocks, and also provides the ability to see how much time the uid was in the background when doing so. Bug: 38198272 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Change-Id: I20ea3546338c44ffdf06859bc840d9059fb18321
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
2bffb5bb3ae092b9e5c6154a6db693c75ccb1b25 |
|
13-Apr-2017 |
Bookatz <bookatz@google.com> |
Collect background stats: syncs Added background times and counts for an app's sync usage. Bug: 35669746 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Change-Id: I1c01c5044064277b97e8d330386454da3e8204da
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
ceebafe41a127c18213ca39ddf692ae1cbfb100e |
|
06-Apr-2017 |
Bookatz <bookatz@google.com> |
Fix counting problems in StopwatchTimer. Changed StopwatchTimer so that its count only increases if the timer is started when its time base is running. Previously, if the time base was off, the timer was started, the time base was turned on, and then the timer was stopped, the count would be increased; now, it will not (because the time base was off when the timer started). Moreover, this likely fixes the count==-1 bug that previously could occur, since the count will no longer be decremented if the timer is stopped after a reset. Fixes: 36730213 Bug: 30099724 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Change-Id: Iad195e431618629ce432074e0c1bd217f9818cb1
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
aa4594aad251bdde8306180f07983dde173bc9e1 |
|
24-Mar-2017 |
Bookatz <bookatz@google.com> |
Collect background stats: scheduled jobs Added background times and counts for an app's scheduled job usage. Changes DualTimer to be a subclass of Timer so that background timers can be easily accessed from the main timer (which is convenient for jobs, whose ArrayMap of Timers is directly accessed outside of BatteryStatsImpl). Bug: 35669746 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Change-Id: Ic1d85db34346ebda94ed39f134fc0794a5877815 (cherry picked from commit d253f537a0cc15851fb0308f3ea287e6bd93dfe6)
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|
867c0d72af63b67cd0abce8a0f40e94e04193aa6 |
|
08-Mar-2017 |
Bookatz <bookatz@google.com> |
Collect background stats: bluetooth, wifi, sensors Added background times and counts for an app's bluetooth scans, wifi scans, and sensor usage. Note that the original times for these three are pooled (i.e. represent the blame apportioned to an app for using these, rather than the actual time an app used these). Since background times are not pooled, and are therefore incomparable to the original times, an extra time, to represent the actual time, had to also be added in the form of 'total duration' to which background times can be compared. Note that this total duration is now a feature of all DurationTimers and can be used, e.g., to track actual wakelock time (not just apportioned wakelock times). The total duration is the time used since reset, and does not give other 'which' times (such as 'since unplugged'). Bug: 35679958 Bug: 35677312 Bug: 35673525 Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java Change-Id: I4b6943f76517cf5cc9420684857a5592cc7495be
/frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsBackgroundStatsTest.java
|