A typical storage device finishes the benchmark in under 10 seconds,
but some extremely slow devices can take minutes, resulting in a
confusing UX that looks like we've frozen. Even worse, we keep
churning through all that I/O even though we know the device will
blow past our user-warning threshold.
So periodically check if we've timed out, and also use that to report
progress up into the Settings UI.
Test: manual
Bug: 62201209, 65639764, 67055204
Change-Id: Id28e63a7ea1476d83184abab5aea737a1d193f3a
Factor out the logic that calls into ActivityManager, since we have
some evidence of violations being triggering before AM has been
published.
Test: manual
Bug: 68940916
Change-Id: Ie64b1eea42393089a657a9b5ae0c4585a0c83bfa
Until now, userdebug and eng builds have tracked StrictMode
violations on all system apps, including prebuilts that we have no
control over, which results in a lot of unactionable noise.
This CL narrows the set of enabled apps to only "bundled" system
apps, which gives us a much higher chance of burning these violations
down to 0 and keeping them there. We don't have a good proxy for an
app being "bundled", so we detect it based on being in the "android."
or "com.android." package namespace.
Clean up the entire flow of applying StrictMode defaults to make it
much more human-readable. This resulted in us fixing a bug where
StrictMode was never actually enabled for jank-sensitive threads in
system_server!
Relax I/O checks in a few places where we know we're interacting with
procfs or sysfs. Add internal "allow" methods that avoid object
allocation by returning raw mask.
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.StrictModeTest
Bug: 68662870
Change-Id: I536e8934fbcdec14915fcb10995fc9704ea98b29
All violations of StrictMode now inherit from one central Violation
class. This unlocks adding penaltyCallback(Violation).
Parsing strings is no longer required to infer what type of violation
something is.
Violation classes have no need to be loaded in Zygote as only developers
opt-in to this feature and will see violations.
Cross-binder thread violation perf test:
before
2872331
2574093
2481208
after
1938227
1742714
2654538
Bug: 64258734
Test: cts-tradefed run cts-dev --module CtsOsTestCases --test
android.os.cts.StrictModeTest
Change-Id: I1971feb03ff77cf297c940cacee62fadb5b8422c
Adds atoms to collect network bytes transmitted and received via wifi
and mobile data. We need to get the list of correct ifaces from
BatteryStats since NetworkStatsService only tracks the mobile ifaces.
We split the atoms so that we can also capture metrics sliced on
foreground and background since they are available from the kernel.
Also adds an atom for the Kernel Wakelocks.
Test: Manually tested with adb shell cmd stats pull-source after
modifying the StatsPullerManager.cpp
Change-Id: I9467afad799c6d97560e868f8625fefae5c2b5e1
BatteryService is the first service that uses a hwbinder
call, so we need to spawn the threads for BatteryService to receive
callbacks prior to starting BatteryService.
Test: boot test
Test: manually sleep in SensorDeviceUtils, still boots
Bug: 68765551
Bug: 68217725
Change-Id: Iadd88897d4cf9e0e37af706452c15318115f2149
IFoo.Proxy.equals() -> HidlSupport.equals() ->
IHwInterface.asBinder().equals() -> HwRemoteBinder.equals().
IFoo.Stub.equals() -> default Object.equals()
Notice that IHwInterface.asBinder() returns mRemote(of type
HwRemoteBinder) for proxies and itself (of type HwBinder) for stubs.
If IFoo.Stub.asBinder() had not return "this", its equals()
should also be overridden.
Bug: 68727931
Test: hidl_test_java
Change-Id: I916983d7bc739747145e2ebb6830226310fd4980
Note:
This is for value metric. The default operations is sum the diffs.
The test uses kernel wake lock, which also needs dimension by kernel
wake lock name.
The test is a bit cumbersome as it needs StatsCompanionService to do
the alarm, which is not exact alarm.
The internal state of a slice of bucket would look something like this:
4:ipc0000005e_727_android.hardwar
0 0
4:SensorService_wakelock
40 64
4:ipc0000005c_727_android.hardwar
...
Test: manual test on device.
Change-Id: I2ed0ac7d3c5fcba8b7611d46f38a38ffd8bdc92a
so other components (system UI, settings, etc) can use them.
Bug: 68769804
Test: Build & presubmit
Change-Id: I30fe78e49d2187bee7c7aeba735cd9c26fc332a5
The functionality has been replaced by the RulesManagerService.
Bug: 65536493
Test: make droid / boot device
Change-Id: I3e3807aff0ad7d367048671a902807a2303dc608
Support for instruction counting has been removed from ART
and the VMDebug APIs in question throw UnsupportedOperationException
unconditionally.
Test: make
Change-Id: Ibcaa160f755a5708bc6fbef3a783acfc26f0ba90
The javadoc of TokenWatcher promised to implement repeated calls to
acquire() with the same token as a no-op, but this wasn't the case.
When acquire() is called repeatedly with the same token, its associated
DeathRecipient object is replaced by a new one. The old DeathRecipient
can therefore be destroyed. This is problematic because the finalizer of
this DeathRecipient implementation calls release() on the same token,
resulting in the token being released unexpectedly.
In this CL we properly implement the documented no-op behavior.
Bug: 68368071
Test: (First, cherry-pick to internal master)
Test: cts-tradefed run cts-dev -m OsTest -t android.os.cts.TokenWatcherTest
Test: CTS verifier > Managed provisioning > Device owner tests
> LockTask UI
Change-Id: Idfad7c88075a510ea1f8527b5a8620121a5dd7bb
We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install. That API is thus
extended to allow you to open readable files, not just opening
file for writing.
Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that. Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.
This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added. This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd. Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added. As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible. (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has. We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)
A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.
Test: manual
Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
This change introduces minimal changes needed to support selection
of locales with BCP 47 numbering system specification. Two level
selection (Language/Region) schema remains, locales with numbering
systems appear in the region selection list and are displayed as
"region (numbering system)".
Bug: 18340949
Bug: 63754513
Test: manual, experimental UI for review.
Change-Id: I42691f3714c5e5c51fd8d96c034cc3a9f6be93dc
They are untested and were committed as part of a legacy refactoring
that appears incomplete.
The Wear team have added a few new config.* flags to disable services
they don't need on watches. These should probably be unified since we
don't really need this fine level of granularity.
Test: make & flash
Bug: 64052650
Change-Id: I5c8ed3f0e78c2ed0d2e733939a82e1ab8940de22
