When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes(). That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.
This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations. Callers freeing cached data need to
now explicitly request defiance of the reserved cache space. (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)
Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand. It
also now handles cached data on adopted storage volumes, which had
been ignored until now. Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9
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
Changed partial wakelock time to be a DualTimer so that it can also
track the time spent while app was in background.
Bug: 62134255
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Change-Id: I85cca468ac126ee83a3600800bcfa75c9fc3012f
Use the looper from the TextView's thread for the helper
Bug 62043115
Test: Manual, type on edit field and select text
Change-Id: I501430a500016a81963a9f9fa636474b708b9b36
Primarily used by tests to be more robust, since reading raw logcat
data recently became very flaky.
Bug: 37915178
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest
Change-Id: I3f12508bb6206c53005356b5d8d9ba57aac2436e
In the case that a user has been removed but their jobs still exist on
disk, the JobSchedulerService will remove all jobs not associated with
current users on boot.
Exposed UserManagerService#getUserIds() via UserManagerInternal for
quick user id retrieval.
Fixes: 38261977
Test: manual
Change-Id: Id4b3c0a4142b4818fcd875eef18ea03f3c45ca40
Signed-off-by: Michael Wachenschwanz <mwachens@google.com>
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
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I247bd1f095dd27335e671981f9e2d77e149af84f
Merged-In: I247bd1f095dd27335e671981f9e2d77e149af84f
In O, graphics drivers are loaded into a new restricted linker
namespace. Drivers built for previous versions of the OS may not work
under those restrictions, so require an updated driver package to
declare compatibility by setting targetSdkVersion >= O.
Bug: 34228255
Test: manually construct packages with and without
targetSdkVersion >= O, confirm driver is used/not-used as
expected.
Change-Id: I4518360433a6de5c6e1e792a6eedddf8c6bf4394
Some users never get switched to (managed profile/work profile) so the
overlay state for a user would never be setup (but they could still show
UI and apps).
This change ensures that user state is setup after an OTA to android O,
and whenever a user is added.
Bug: 37899201
Test: manual (add user via Device Admin sample: vendor/google/tools/DeviceAdminSample)
Change-Id: If214e26e39b18c2861794baf5c608a47d536e5ff
Currently we have total user and system cpu time spent by the uid
in the batterystats. This change will add times spent by the uid
at each different cpu frequency to the batterystats dump which will
help in better understanding the battery usage.
Bug: 34133340
Test: manual
Change-Id: I567dc75875eb58543c0e71572d0b440e87dbb4b9
There is now an IBinder "token" that must be specified when setting
the whitelist duration for an Intent. To have the whitelist supplied,
the caller to send a PendingIntent must pass in the same token. The
PendingIntent and IntentSender classes now internally maintain this token
to pass in when their send() is called.
The big complexity for making this work is we now need to associate this
whitelist token correctly with the actual PendingIntent objects that
applications and other code is getting. To do this, we propagate the
token in the Notification object, and have a new API on Parcel that allows
us to make it available to PendingIntent when it is unmarshalled. And
this allows to deal with PendingIntents appearing in nested bundles, as
we can propagate that information from the original Parcel to the new
Parcel that Bundle keeps to delay unmarshalling.
Test: manual
Change-Id: Idda00490ccfe2be37e4ab21354b9ab7528a52750
It can be used to check that the value returned by getUserName() was set
by the user and is not a default value returned by the system.
Test: UserManagerServiceUserInfoTest pass
Bug: 38138381
Change-Id: I0ca37970fda548508190bffd1fa7be95d4a15076
Catch an exception sent from native code looking for a specific known
bug and report via wtf which code path is hitting the bug. Revert this
change once bug has been resolved.
Bug: 37298089
Test: manual
Change-Id: Ieb98a8a82a9a2cffe4d0cfbbc8333f453b3e36d5
Signed-off-by: Michael Wachenschwanz <mwachens@google.com>
Make sure to not hold the wm lock when calling into power manager
service, because PWM will acquire a lock that might be contended.
Test: Make sure user activity timeout is still respected on
Keyguard
Test: Have activity with screenBrightness=1.0, make sure screen
is fully bright when opened
Bug: 37888898
Bug: 36631902
Change-Id: I4b5433dbaf8aa151465ae32232d3b3b8597715df
Previously, wakelock max/current/total durations were initialized to -1,
instead of 0. So if, e.g., an app held a full wakelock but not a partial
wakelock, then the partial wakelock would return -1 for these data. This
cl changes that to be 0. The value will only be -1 if the data is not
tracked (as is currently the case for full and window wakelocks), in
which case if the wakelock was held, -1 will be given to signify the
lack of tracking.
Test: manually confirm 0 instead of -1 in batterystats dump.
Change-Id: I934022294ba5adafb2e4d9a5be1dc20aab045cb0
Previously, partial wakelock times reported the blame apportioned to the
app (i.e. the times were pooled). This CL adds another field to provide
the actual time the partial wakelock was held (unpooled, irrespective of
other app's wakelock usage). Full and window wakelocks also now have the
equivalent field, but it always returns -1 (like their max and current
durations), since none of those are currently tracked. Kernel wakelocks
are unchanged.
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Bug: 18998184
Change-Id: Ic4cc8c3abba9afa60902d0c8e17e11abeef52a96
