...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
We normally prevent apps from allocating into the "reserved" cache
space, but this change makes an exception for an active camera app,
since the user is probably trying to capture an important memory.
This change only lets the active camera app clear up to half of the
reserved space, since we don't want to completely destroy the
experience of all other apps.
Test: manual app before/during/after active camera session
Bug: 38267830
Change-Id: Ie9e63884fb2638ca881e10b894629eea84601648
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
New HAL support is a bit hacky but gets us unblocked.
Bug: 38417655
Bug: 38417570
Test: Manual (hacked up 1.1 HAL implementation that just logs)
Change-Id: I207cce97c81734bac1ca00a5de18e160d13e2bbe
Tombstoned now fully supports java traces and intercepts, and the
debuggerd dump API has been extended to support dumps of java traces.
This change switches ANR dumping over to using this API when the
right system property is set. The new flow is as follows :
- The system_server creates a new file using File.createTempFile for
each ANR detected by the activity manager. All dumps associated
with that ANR go into that file.
- All dumps are initiated using debuggerd client API (debuggerd_trigger_dump)
which handles all the timeout measurement for us. It can also
guarantee that no writes are made to the file after the method
returns, so we have no need of inotify watches and other fiddly
mechanisms to monitor progress. Also, this would give us the ability
to add meta-information about timeouts etc. to the dump file itself,
thougt that hasn't been implemented just yet.
Test: Manual
Bug: 32064548
Change-Id: I37e72c467e6dc29da4347c2a2829eeeeb1ad3490
This reverts commit 48b908bd77.
and brings back commit 0a4e11480b
This commit directs framework to use Power HAL 1.1
The commit has been tested not to cause application startup time
regression which was the reason of reverting the original commit
Bug: 62040325
Test: Performance Tests along with other tests
Change-Id: I84fdff3136c85e62223e2ae2f66b5bcad4e491b8
Signed-off-by: Ahmed ElArabawy <arabawy@google.com>
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
getUserInfo(), getUserName() was the only one that did not check for
null. This has led to NPEs like in b/37589362.
Test: none. :( Not sure how to force the race where getUserInfo()
returns null. Verified manually that getUserName() still works.
Change-Id: I98ef06fe99ba760ae0194ec256fc9d1f39d3b7e5
