The UID map is updated by StatsCompanionService, which listens to broadcast
updates indicating that an app was updated/installed or removed. Also,
the entire map is updated when statsd first connects to the companion
service. Also, there is a way for metrics producers to subscribe to
updates, so that they can know when an app was upgraded.
Test: Created new unit-test for mapping and manually tested for install
and remove. Did not manually test the app upgrade.
Change-Id: I6676ae5c93b75c72d9badabb36aa9c40006db07d
Check whether the guard is null to avoid:
Uncaught exception thrown by finalizer
java.lang.NullPointerException: Attempt to invoke virtual method 'void dalvik.system.CloseGuard.close()' on a null object reference
at android.os.ParcelFileDescriptor.closeWithStatus(ParcelFileDescriptor.java:740)
at android.os.ParcelFileDescriptor.finalize(ParcelFileDescriptor.java:990)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:250)
at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:237)
at java.lang.Daemons$Daemon.run(Daemons.java:103)
at java.lang.Thread.run(Thread.java:764)
Follow-up to commit da5a3e12f4.
Bug: 7426029
Bug: 10330121
Test: m
Change-Id: I903f1545ab784008727ff23bb95fe182bd95b62a
Also a little code cleanup as I was going through to understand the
dumping code.
Bug: 65750808
Test: flash device and inspect incident.proto output
Change-Id: Ib850db408c98d6a96dc028296e96c75087258904
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
Merged-In: I7193a36751124dd380818b2b665303c0f0d8c984
Change-Id: I51cead7f92abd9e4c620f7dfde393993cdad494e
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
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
