Wrong description of the "tid" parameter used by getThreadPriority():
the function does not "change" the priority of the thread associated to
"tid".
Defined also the meaning of setting tid parameter to 0.
Test: None
Change-Id: I8552f3b110eaab1aefa51477e82d3e295547be34
Signed-off-by: Alessio Balsini <alessio.balsini@gmail.com>
...can't hide themselves
Tune the policies for when we tell about apps running in the
background after their services have stopped.
- If it ran while the screen was on, the time we require for it
to be running is much shorter (a couple seconds) as well as the
time we tell about it having run (with another tunable for the
minimum time we tell about this).
- If it has only run while the screen is off and stops a sufficient
amount of time before the screen goes on (currently a second) then
we will not show anything when the screen goes on.
- If it stops when the screen turns on, we will make sure the user
sees about it for a short period of time (currently 5 seconds).
Also includes some improved debug output about handler message
queues.
Test: manual
Change-Id: Iab438410d7182b2dfe4f9c1cce7069b26b34834c
It has been discovered that for background values of
AggregatedWakelock, Sync, Job, and partial wakelocks,
the value of getTotalTimeLocked is wrong and often very
negative. getTotalDurationMsLocked, which should provide the exact same
value in all of these cases (since background data is never pooled),
does not have this problem. So while the source of the bug is sought
out, we should use getTotalDurationMsLocked instead of getTotalTimeLocked for
these data.
Bug: 62352334
Test: cts-tradefed run cts-dev -m CtsDumpsysHostTestCases -t android.dumpsys.cts.BatteryStatsDumpsysTest
Change-Id: I78e84368615578483ab8e9e5f0ee1d067491be08
This forces everyone to go through sdcardfs, instead of letting them
around the back door.
Test: builds, boots
Bug: 38231314, 27992761
Change-Id: I97b24d25599c7f86f9b535689e2f4ecf68261dac
We've seen some @SystemApi methods protected with non-system
permissions, so give Doclava the platform AndroidManifest.xml so it
can parse the actual permission protection levels to look for APIs
that are letting in non-system apps.
Also document more @SystemApi permissions.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api
Bug: 62263906
Change-Id: Ie0f0a5fb0033817bcc95060f2183a52ae4ae7b06
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
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
