This binder service is originally served by healthd.
To allow BatteryManager to continue to work, BatteryService
implements this binder service.
Test: BatteryManagerTest
Bug: 62229583
Change-Id: I9c97b3936546740c6d63060899fe50c5c4c957bd
We now disallow non-UTF8 property values directly in property_service,
so there is no need for this warning.
This partially reverts 33aea8d40e.
Bug: 63177684
Test: make
Change-Id: I61f49f635c6095013f55b906e00925a8cbd1ea8c
Instead of using the whole slab mem for kernel usage, split the
unreclaimable to kernel and reclaimable to cache (since is freed
under mem. pressure).
Test: tested on gobo
Bug:67753120
Change-Id: I0f5a310bb88603ad7bb28e5398ea57c249c04fc2
Bug: 66729158
Test: Manually build and flash the system.img and test "activity --proto
broadcasts"
Change-Id: I3cb7474c4a3ab092f38ed6a121b4d034cadfc402
Cleanup of Cellular/Wifi aggregate statistics in Batterystats dumpsys
Cellular
- Modification of field names to improve clarity
- Removed count "x" values
- Added power values to Rx signal strength
- Added power values to Tx power
- Added "Cellular Sleep time"
- Removed erroneous battery field (This is being fixed in b/67213886,
b/67213967)
- Removed the following fields (Mobile radio active unknown time, Mobile
radio active adjusted time, Signal scanning time)
Wifi
- Modification of field names to improve clarity
- Removed count "x" values
- Added power values to Rx signal strength
- Removed the following field (Wifi on, Wifi running)
BUG:67322291
Change-Id: I9630f154a73c7e3cb4bae4779609302f3674602f
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
