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
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
Most processes might end up using EGL, but most don't except for
Activities with HW-accelerated UI. And for other cases, the startup
latency of initializing EGL on-demand isn't as important. So this
change only tries to early-initialize EGL for HWUI Activities.
It also fixes a logic problem that may or not have been an actual bug:
previously, we only chose a graphics driver if we successfully set up
shader cache directories, even though these are mostly unrelated. Now
we always choose a graphics driver, except in isolated processes that
can't use graphics.
Bug: 38215658
Test: systrace framework start and Clock launch, check eglGetDisplay
is called by RenderThread in non-HWUI-Activity cases, and is
called on a separate thread before RenderThread needs it for
HWUI-Activity cases.
Change-Id: I101e5578a9d7c508d232d0edeed7ceff9d8a74d6
Put all of the setupGraphicsSupport-related code into one function so
its easier to follow the full logic, and less intrusive to the code
around the call-site. This isn't supposed to change behavior at all,
but is preparation for the next change which will.
Bug: 38215658
Test: launch Clock, observe relevant events in systrace
Change-Id: I157b6233c0e9daf65e41697b504aa7e7d684401c