Timer is the basic stat tracking object that's used for a lot of the
data in batterystats.
ControllerActivity data is tracked both per uid and for the entire
system, so it makes sense to define it now independently.
For the BatteryStatsHelper change: there's a small window of time after
boot where getSystemService will return null. I ran into it.
BUG: 65750808
Test: flash device and check incident proto output
Change-Id: I15e7d046a43f76d5f53d05b5138ea40f42e19d59
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
Change-Id: I7193a36751124dd380818b2b665303c0f0d8c984
Create a settings class only for use with permissions. It's
subservient [and should only be accessed directly by] package
settings or the permission manager. The rest of the permission
related data needs to be moved to permission settings. At
which point we can start pulling the permission methods out of
the package manager service and into the permission manager.
We still have a somewhat tight relationship between package
manager and the permission manager. It's unclear how far we need
to separate them and if relying entirely on an internal
interface is sufficient.
Bug: 63539144
Test: Manual. Builds and runs
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.PermissionsHostTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsPermissionTestCases
Test: cts-tradefed run commandAndExit cts-dev -m CtsPermission2TestCases
Test: bit FrameworksServicesTests:com.android.server.pm.PackageManagerSettingsTests
Change-Id: I616184fa2135a11687e4ce615884f861466fdebe
WakeLock can end up in a bad state if the following sequence
is executed:
1. mWakeLock = mPowerManager.newWakeLock(...)
2. mWakeLock.acquire(TIMEOUT_MS);
3. timeout TIMEOUT_MS occurs before release() is called
4. release is called()
[1] mInternalCount = mExternalCount = 0
[2] mInternalCount = 1, mExternalCount = 1
[3] mInternalCount = 0, mExternalCount = 1
[4] mInternalCount = -1, mExternalCount = 0
If acquireLocked is called on the same object after this sequence,
mInternalCount is incremented to 0 which results in no wakelock
being requested from PowerManagerService.
Bug: 64676694
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.PowerManager_WakeLockTest
Change-Id: I133812aefb5d92eec2e2dde1a36f81dc9ffd7625
When statsd is told that it is time to poll data, it asks
StatsCompanionService to pull kernel wakelock data, receives the result
(as a string), and outputs it to screen.
Still to do:
1. don't use a string; use a parcel instead
2. don't output it to screen; do something useful instead
3. do more than just kernel wakelocks
4. pull data on demand, in addition to just on periodic pulling
Test: added setPollingAlarms to statsd.main and confirmed that kernel
wakelock information was written to screen
Change-Id: I35f5164420699dea1a00c9e530b938904f1d3055
We want the user to be able to remove apps that are added in the system
whitelist. The user can restore them back later if they want.
Test: cts-tradefed run cts-dev -m CtsDeviceIdleHostTestCases
Bug: 63528174
Change-Id: Ia2f908c5fac84e28772d85b303be68b70efac8ba
Awhile back we explicitly blocked any new ASEC installs, with the
expectation that we'd eventually remove the logic entirely. We've
had them disabled for about a week now without incident, so let's
rip out the remaining code.
Test: bit FrameworksCoreTests:android.content.pm.PackageHelperTests
Test: bit FrameworksCoreTests:android.content.pm.PackageManagerTests
Bug: 32913676
Change-Id: I1ecc35487420731f5c4bdf03bca5751548ce51b3
This only worked on broadcom devices, and was superseded in
M by a wifi HAL call made by IpManager.
Test: bullhead builds, boots
Change-Id: I711cae7dafe171c2c8b4e84a229adbcad27f3d14
When BatteryService triggers ACTION_REQUEST_SHUTDOWN intent, add the reason
for shutdown as extra to indicate low battery or critical battery
thermal state.
Bug: 63736262
Test: 1/ adb shell cmd battery unplug && adb shell cmd battery set level 0
2/ Power on the device
3/ Verify sys.boot.reason == shutdown,battery
Test: 1/ adb shell cmd battery set temp 700
2/ Power on the device
3/ Verify sys.boot.reason == shutdown,thermal,battery
Change-Id: If20a36ef53f8bcbfae4114df08f741ec1dcd7df9
Modify IServiceManager to accept supported dumpsys priority as a bitmask
with NORMAL being the default priority. Change listServices to return
a list of services filtered by the priority or all services when the
priority is set to ALL.
BUG:27429130
Test: manual verification
Change-Id: If367ace2f37f918043f1b330568d8560676d9b78
Also fix up imports to make repohooks happy and some whitespace issues.
A very small step towards making this code more understandable.
Bug: 65760710
Test: Builds.
Change-Id: I0396c06bb303e0b06ad0cbbbff4fdc1ac527ac6c
All detector bits should be the same visibility.
Extract some error messages into constants.
Bug: 65966451
Test: CTS builds
Change-Id: Ib8ed80042c8d490d18ddd0054db8870e09c2b19d
Without this test, someone could trick us into constructing other
shady classes.
Test: builds, boots
Bug: 65281159
Change-Id: If678d0681708d1b0dcf056aa1133830ad3dbce31
If statsd or statsdcompanion crashes, or if one loads
before the other, the other will be able to accomodate.
When statsd loads, it will attempt to tell statscompanion that it's
alive, and then get on to its business, while assuming that
statscompanion is not alive. Only when statscompanion tells statsd
that it is alive, statsd will then start to use it.
When statscompanion loads, it will attempt to tell statsd that it's
alive and then do nothing (since it has nothing to do). When statsd
tells statscompanion that statsd is alive, statscompanion will respond,
telling statsd that it is alive and, if that binder call returns, will
get to work.
This way, if statsd loads first, it can work unobstructed until
statscompanion informs statsd that it is alive, at which point they
shake hands and work. Conversely, if statscompanion loads first, it will
do nothing until statsd contacts it, at which point they will shake
hands and work.
Test: manual
Change-Id: I969ad47fb8060e27814d05ad37433a02711cfa6a
StatsCompanionService can now inform statsd that an alarm (for anomaly
alerting and for polling) has fired, so that statsd can act accordingly.
Test: manual created an alarm from statsd.main and checked logcat that
statsd received the broadcast that it fired
Change-Id: I1d33dfbee0d3e213c91dd6973d2622ecacc890c8
Now that we're using Binder, we can have callers provide explicit
listeners for every request instead of trying to squeeze them all
into unsolicited socket events.
Move benchmarking to be async to avoid blocking other commands for
up to several minutes. Remove post-trim benchmarking flag, since
benchmarking now requires a separate callback. Will bring back in
a future CL.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Test: adb shell sm fstrim
Bug: 62201209, 13758960
Change-Id: I26f76c66734ac2fd0f64713b8ab9828430499019
Before this change, ZygoteProcess.preloadPackageForAbi returned
as soon as the command was written to the zygote socket and not
after the preload completed. This meant that there was a small
window of time before the server side of the socket polled its FDs
where a second command could be written to the zygote socket. This
would lead to only one of the commands being processed and the
other being dropped. The client side of that socket would then wait
forever for a response and bring down the system once the watchdog
timeout was hit.
Example failure case :
--------------
system_server：send command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(preloadPackage) // the fork command is dropped.
Example of normal operation :
------------------
system_server：send command(preloadPackage)
zygote：poll & process command(preloadPackage)
system_server：send command(fork)
zygote：poll & process command(fork)
This change makes preloadPackageForAbi synchronous, which ensures
that each POLLIN event corresponds to precisely one command.
(cherry picked from commit 24a3306c32)
Bug: 62886909
Bug: 13618569
Test: Manual
Contributed-By: yuqianyu@huawei.com
Merged-In: I83faf974c9a70a6ab18323f692c1981784e4c56a
Change-Id: I83faf974c9a70a6ab18323f692c1981784e4c56a
RPM = resource power manager.
Fetching the rpm stats (specifically, the subsystem low power stats) is
slow... too slow to reasonably do each time the screen state changes.
Therefore, it is disabled until fetching this information can be done
more quickly. Consequently, the screen-off RPM values will be incorrect
until it is re-enabled; they are therefore not printed.
Bug: 65164435
Bug: 62549421
Test: manual
Change-Id: I54d54f244c69ee372f22ecd99f32570db4aeb222
Create IVoldListener and move most unsolicited vold events over to
this new interface. The remaining events will be routed through
method-specific listeners instead of a global one.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.DirectBootHostTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.storage.cts.StorageManagerTest
Bug: 13758960
Change-Id: I492dacfaf98eeb66868b2cf7dfa27d84f6710948
Currently Resource Power Management (e.g. VMIN time) is reported in the
batterystats history each time the battery level changes. We need this
information in the batterystats checkin, and need to be able to
differentiate time spent in each power state/voter, total as well as
when the screen is off.
The RPM information is obtained via a JNI call to the appropriate HALs.
Batterystats report version is increased to 26.
Bug: 62549421
Test: manual
Change-Id: I0c384eb3950714d8a0aa1353a4bf965330ebc8c1
