Use measured screen energy usage (where available)
in battery reporting in BatteryStatsHelper, including
total and per-app screen energy usage.
Regardless of the data source (measured screen power usage vs.
estimating from screen time), the blame on apps is 'smeared',
meaning that it is apportioned (after-the-fact) based on each
app's foreground usage. That does not change here.
Also fixes a mistake in Uid.getScreenOnEnergy().
Future followups to do
1. Make getMeasuredOrEstimatedPower more universal (as more
PowerCalculators follow suit)
2. Support for BatteryUsageStats
3. Deal with voltage properly
4. Toggle whether to report the measured energy on/off.
Test: atest BatteryStatsHelperTest
Bug: 174818228
Change-Id: I0eaa4bc594cb31b4a26b5488b08114cbf80e3884
Merged-In: I0eaa4bc594cb31b4a26b5488b08114cbf80e3884
(cherry picked from commit 30594e82d5)
Keep previous vibrations to be reported in the dump method, similar to
VibratorService.
Implement some vibrate commands to test VibratorManager in the adb
shell.
Bug: 167946816
Test: VibratorManagerTest
Change-Id: Ie7dd89b0e3b2747454b32fe3cc2d8751daae9e19
Use the same VibrationThread to control combined vibrations on all
vibrators.
Bug: 167946816
Test: VibratorManagerTest
Change-Id: I40c9f235f05baf85e5ed15bf3bce41451283c7f2
As a feedback from API review, we should unhide the violation so that
the developers can perform instanceof check when writing their own
logging stacks.
fixes: 177707145
Test: atest StrictModeTest
Change-Id: I6fbf10c915b5b6a7c72aacc5882ef5e33551c6e8
This reverts commit 31fa0fc9c1.
Reason for revert: Play data loader doesn't write data to incfs during "Downloading...", so we shouldn't use incfs progress to replace install progress. Reverting this, so that Launcher will display the install progress ring during "Downloading..." using the progress reported from Phonesky.
Change-Id: I124033d725fe488fd337b6ded0bdf319a764b6ca
Merged-In: I124033d725fe488fd337b6ded0bdf319a764b6ca
BUG: 178528778
(cherry picked from commit d0cec52acb)
Change-Id: Ib6637be489e36c78e5074c161d01ac510da5d045
Similar to how HIDL HALs are here, we don't know the commandline of the
service, so we can dump them based on service name prefixes.
Power stats and lights are added here, for parity w/ HIDL since these
hvae been converted to AIDL.
Fixes: 175322136
Test: after `adb shell am hang`, we can verify the light service is
dumped, when it wasn't before:
vsoc_x86_64:/data/anr # cat anr_2021-01-28-22-42-44-969 | grep light
Cmd line: /vendor/bin/hw/android.hardware.lights-service.example
Change-Id: I8c8b0cff0c102221875114015a5524c03cfb5b5c
Root cause:
1) a client thread calls "transact", and then, reads a java binder object from the java parcel object
2) the java binder object sends BC_ACQUIRE/BC_INCREFS, but still in the queue, not yet flushed to driver
3) the java parcel object is garbage-collect-ed, and, its finalize method may possibly sends BC_FREE_BUFFER
Because "BC_FREE_BUFFER" is from the java finalize thread, which is different from the "client thread", so, it is possible that "BC_FREE_BUFFER" will be flushed to driver before "BC_ACQUIRE/BC_INCREFS", which makes driver destroy the related "binder_ref" object prematurely.
Consequences of the issue:
The user space process might always hold the above java binder object, whose "handle value" is indeed invalid because the related "binder_ref" in driver is destroyed. This causes a lot of chaos inside the process:
<a> any binder call on the java binder object will be a failure, with kernel log complain: ...got transaction to invalid handle...
<b> afterward, any new bind object passed to this process will NOT create a brand new one for it, instead, it will be simply and incorrectly mapped to the above old biner object, because the new incoming one will use the same "handle value" as the old one. This will make a mess and many weird bugs.
First, it may break "binder object identity" compare based functionality. For example, after registering a listener to a service, all following registering may fail because the latter new listener object is mapped to the old one incorrectly. The service will reject them as "already registered".
Second, binder call on the old binder object is actually dispatched to the new remote binder object, it might even be a success if they are of the same class/interface, which is actually not we expected; and on the other hand, the new binder object may even be of different class/interface, and of course, the binder call may be a failure due to "interface descriptor check".
<c> the user space process cannot recover from the bug automatically unless restart.
Solution:
Hold a temporary reference to the parcel object until "BC_ACQUIRE/BC_INCREFS" flushed to driver.
Bug: 139327211
Test: monkey test for one day and one night
Co-authored-by: Steven Moreland <smoreland@google.com>
Signed-off-by: Jintao Zhu <zhujtcsieee@gmail.com>
Change-Id: I9345f443996b0bdef9d57ddaad119b86205e817f
Android 12 introduces a StrictMode check to warn developers if they
are launching an unsafe Intent (one that has been unparceled from the
delivered Intent). This commit provides an API to allow a developer
to access the Intent that triggered the StrictMode violation.
Bug: 178029824
Test: atest StrictModeTest
Test: Manually verified serialized violation does not result in
an Exception
Change-Id: I392df3f80487503bc8235700ecb17c51d930830c
New system API added for privledged clients to modify the full battery
saver mode policy. This API is used to override static settings at
runtime, and any overridden settings are cleared when exiting full
battery saver mode.
Bug: 172294448
Test: atest PowerManagerTest
Test: atest PowerManagerServiceTest
Test: atest BatterySaverPolicyTest
Test: build and boot ensuring SoundTrigger service behavior is not
changed
Change-Id: I41f968799b184a5dac702553379294795614be0a
FAT volume identifiers are randomly generated 32-bit identifiers
that are not UUIDs as per the spec. However, we need to coerce
them into UUIDs because several storage APIs are defined in terms
of UUIDs.
We need a follow up change to properly return UUIDs for public
volumes in order to complete developer support.
Test: atest StorageManagerTest
Bug: 166129035
Change-Id: Icaa4f3485af698ab7163031c540aa2b27d1e1f16
Control over the SoundTrigger service behavior in battery saver mode is
expanded to from a boolean to multiple modes. Modes include enabled,
disabled, and privileged. Adding the privedged mode allows for the
SoundTrigger service to selectively control clients which are deemed
esential to the Android system.
Bug: 172294448
Test: atest BatterySaverPolicyTest
Test: atest CtsBatterySavingTestCases
Test: atest PowerManagerTest
Test: build and verify backward compatibility with SoundTrigger system
service behavior
Change-Id: Ib701963b07b205e5902ef265198b390a9850cb88
Connectivity service is going to become a mainline module which
will not be able to access hidden APIs. But PermissionMonitor
needs know Build.VERSION.FIRST_SDK_INT for granting network
restricted permission to system packages. Thus, expose the value
as module-lib API to support the usage.
Bug: 170598012
Test: make update-api
Change-Id: Id0ae42120f69faee43eeb7ebd35cae9e26cb7561
UserManager.removeUserOrSetEphemeral() was added primarily to
be used by CarDevicePolicyManager, in which case it should ignore
the no_remove_user restriction. But as it's also used in other
places, it needs a new parameter to define this behavior.
Test: atest FrameworksServicesTests:com.android.server.pm.UserManagerTest#testRemoveUserOrSetEphemeral_evenWhenRestricted
Test: atest FrameworksServicesTests:com.android.server.pm.UserManagerTest # to make sure it didn't break anything
Test: atest android.car.apitest.CarDevicePolicyManagerTest#testRemoveUser_whenDisallowed # on automotive
Bug: 170887769
Change-Id: If797ace64c0fa0262116f649212bbcb1d61e2046
