RROs have historically been APK packages. We now have the ability to
generate RROs on-the-fly. These "fabricated" RROs are not APKs.
ApplicationInfo#resourceDirs documentation states that it only contains
paths to packages. To prevent changing the behavior of resourceDirs
until we can deprecate and remove it, a new overlayPaths field has been
added to ApplicationInfo. This new field contains APK overlay paths as
well as non-APK overlay paths.
Bug: 172471315
Test: boot enable/disable overlays and examine overlays working as well
as package manager dumpsys
Change-Id: I78c5eeef73b7d8bada61edc0f64a12a3cdc1ce16
This CL moves computeWindowBounds to the client side. The client can use
it to compute the frame hint on its own.
This can be a step to make client compute its window frame locally.
Bug: 161810301
BUg: 175858823
Test: atest WindowAddRemovePerfTest ActivityRecordTests
DisplayPolicyLayoutTests TaskSnapshotSurfaceTest
Change-Id: Ia5af1919b8e0e973646a63d1a4c3bf7ea7e2d1f6
Similar to passing in display metrics. We can use
ActivityThread.currentApplication() as the context for getting
PermissionManager in system server process because it will be created
early in ActivityThread.attach() before any custom logic can run, but
it becomes a problem for apps because they can run their own logic by
overriding Application.attachBaseContext() and do things there before
ActivityThread.currentApplication() becomes non-null.
So pass in the split permissions explicitly as an external dependency
for ParsingPackageUtils, and move the getPackageArchiveInfo()
implementation from PackageManager to ApplicationPackageManager to
utilize the context there. PackageParser2 can get the split
permissions internally because it's only used in system server.
Fixes: 178155985
Test: manual
Change-Id: I8213cf752e16b08328ad1150b2639da18c5d0e83
(cherry picked from commit 7b8974d375c74ff228d71b1f038f48cfb46c6d7c)
In order to do this, updated the apct-tests/perftests/OWNERS file to
include the entire perf team and then added that to the
PinnerService.java definition.
Also removed srnvs@ since I am getting a "does not exist"
warning for that email.
Bug: 177918051
Test: Presubmit
Change-Id: I00f30f5131d38c4b073266e8c80d92d1ad734eb5
We've been working hard to require PendingIntents explicitly declare
if they allow their contents to be mutated or not, and to finish
landing that work this change applies the new FLAG_MUTABLE_UNAUDITED
flag to all remaining code locations until they can be manually
inspected.
Bug: 160794467
Test: manual
Change-Id: I8d7ec64ac89755c14b5959bb6ef0bce203c92bf0
Since the display cutout is a type of insets and the display cutout can
be obtained from WindowInsets, it makes sense that InsetsState has the
display cutout instance. In this way, we can send the display cutout to
client via W#insetsChanged instead of W#resized.
This can be a step to remove the class of ClientWindowFrames, and can
also be a step to make client compute its window frame locally.
Fix: 175858810
Bug: 161810301
Test: atest WindowAddRemovePerfTest ImeInsetsSourceConsumerTest
InsetsControllerTest InsetsStateTest ViewRootImplTest
WindowInsetsControllerTests ActivityRecordTests
DisplayPolicyLayoutTests LaunchParamsControllerTests
TaskSnapshotSurfaceTest WindowMetricsActivityTests
WindowMetricsWindowContextTests WindowMetricsTest
WindowFrameTests WindowStateTests WmDisplayCutoutTest
Change-Id: I9a930b1d2f7df3cea2b29629b767a4a5f31bca17
Moved from MtpServicePerfTests to CorePerfTests
for Benchmark Instrument
Bug: 172498127
Test: atest CorePerfTests
Change-Id: I05c38d431bee6f30982313d01ed957f24f0cb2f4
As part of bringing up these tests in Cystalball,
use Collector helper library to wait for device to stabilize
before running the test.
Bug: 163826419
Test: atest BlobStorePerfTests
Change-Id: Iad31b9e0a5b1f17f83499984f41e39118d8cc153
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Add WindowPerfTestBase and WindowPerfRunPreconditionBase
into apct-perftests-utils. So window manager and input
method manager can share the same functions.
Bug: 174292015
Test: WmPerfTests ImePerfTests
Change-Id: Ie2818536d6611d1ba5f4b6cd725cd2d4a95e1cac
This change adds the necessary build dependencies and test rules to
support adding the package manager perf test suite to crystal ball.
Bug: 169160667
Test: atest PackageManagerPerfTests
Change-Id: I1335b40737473541f12f5f4c4ef2bb32eea6196b
A recent set of patches had mismatched handling of UTF-8 vs modified
UTF-8; this change converges all paths towards using modified UTF-8
to match the DataInput/Output API contract.
New tests verify that underlying raw data is compatible between the
upstream and local implementations.
Bug: 171832118
Test: atest FrameworksCoreTests:android.util.CharsetUtilsTest
Test: atest FrameworksCoreTests:android.util.XmlTest
Test: atest FrameworksCoreTests:android.util.BinaryXmlTest
Test: atest FrameworksCoreTests:com.android.internal.util.FastDataTest
Change-Id: I49423edc867839fb6626cd8bd361abe7bc512633
Measure latency caused by IMF for IME operations like show / hide.
This CL uses apct tests for integration with Crystallball to measure
overall latency and breakdown of critical IMF methods.
In this CL we introduce a BaselineIme with minimal UI to measure
user-preceived delays in IME show/hide.
Refer to design doc in bug.
Bug: 167947940
Test: atest ImePerfTests and also refer to README.md
Change-Id: I8efff52fe25952d452aef7f059400c63d1a9fa4a
* changes:
Custom binary XML wire protocol.
Progress towards efficient XML serialization.
More efficient alternatives to ByteBuffer.
CharsetUtils alternatives that avoid allocations.
We've identified that XML writing and reading uses roughly 1.5% of
all system_server CPU, and can generate many temporary objects.
Building on the recent TypedXmlSerializer/PullParser interfaces, this
change introduces new BinaryXmlSerializer/PullParser implementations
that store data using a custom binary wire protocol. Benchmarking of
a typical packages.xml has shown this new binary approach can write
4.3x faster and read 8.5x faster, while using 2.4x less disk space:
timeWrite_Fast_mean: 27946635
timeWrite_Binary_mean: 6519341
timeRead_Fast_mean: 59562531
timeRead_Binary_mean: 7020185
A major factor in choosing to invest in this new wire protocol is
that it enables the long-tail of over 100 unique XML schemas used
across the OS internals to be transparently upgraded to gain these
benefits with only minimal changes, reducing the risks associated
with rewriting those schemas.
Finally, since the wire protocol is essentially a serialized event
stream, it's trivial to transparently convert this new protocol
into human-readable XML and vice-versa. The tests in this change
demonstrate this translation working correctly, and future changes
will introduce new shell tools to aid development work.
Bug: 171832118
Test: atest FrameworksCoreTests:android.util.XmlTest
Test: atest FrameworksCoreTests:android.util.BinaryXmlTest
Test: atest CorePerfTests:android.util.XmlPerfTest
Change-Id: Ib9390701f09562dca952b3786622675b9c68a462
Some upcoming binary XML work needs to efficiently read and write
raw bytes, and we initially started using ByteBuffer. However, that
design had additional overhead since we were performing bounds checks
twice (once to fill/drain buffers, then again to parse data). In
addition, the upstream ByteBuffer makes per-byte method invocations
internally, instead of going directly the the buffer.
This change introduces FastDataInput/Output as local implementations
of DataInput/Output which are focused on performance. They also
handle fill/drain from an underlying Input/OutputStream, and the
included benchmarks show reading 3x faster and writing 2x faster:
timeRead_Upstream_mean: 5543730
timeRead_Local_mean: 1698602
timeWrite_Upstream_mean: 3731119
timeWrite_Local_mean: 1885983
We also use the new CharsetUtils methods to write UTF-8 values
directly without additional allocations whenever possible. This
requires using a non-movable buffer to avoid JNI overhead to gain
the 30% benchmarked performance wins.
Bug: 171832118
Test: atest CorePerfTests:com.android.internal.util.FastDataPerfTest
Test: atest FrameworksCoreTests:com.android.internal.util.FastDataTest
Change-Id: If28ee381adb528d03cc9851d78236d985b6ede16
Add the benchmark for processing InputEvent in ViewRootImpl.
* the cost of processing KeyEvent
* the cost of processing MotionEvent
* the cost of processing KeyEvent with IME x (handle preIME or not)
* the cost of processing MotionEvent with IME x (handle preIME or not)
Test: atest InputStageBenchmark
Bug: 162193693
Change-Id: I64f6b2e8ec3e841461553dbc6c9f4c0dfdd8ef86
Internally String.getBytes() calls libcore.util.CharsetUtils methods
for a handful of common charsets, but that path requires new memory
allocations for every call.
This change introduces alternative versions of those methods which
attempt to encode data directly into an already-allocated memory
region. If the destination is to small, callers can detect and pivot
back to calling String.getBytes().
The included benchmarks reveal these raw performance improvements,
in addition to the reduced GC load which is harder to measure:
timeLocal_LargeBuffer[simple]_mean: 424
timeLocal_SmallBuffer[simple]_mean: 511
timeUpstream[simple]_mean: 800
timeLocal_LargeBuffer[complex]_mean: 977
timeLocal_SmallBuffer[complex]_mean: 1266
timeUpstream[complex]_mean: 1468
Bug: 171832118
Test: atest CorePerfTests:android.util.CharsetUtilsPerfTest
Test: atest FrameworksCoreTests:android.util.CharsetUtilsTest
Change-Id: Iac1151e7cb8e88bf82339cada64b0936e1a7578b
Previous logic was using GetStringUTFChars() and GetStringCritical(),
which resulted in making a new temporary heap allocation and an extra
memcpy(). The new approach in this CL bypasses those operations by
asking the JNI helpers to copy directly into the Parcel buffer.
This does mean that the contract for writing strings (prefixed with
length) is now duplicated in Parcel.cpp and android_os_Parcel.cpp,
so we leave docs to ensure future maintainers keep them in sync.
Benchmarking shows that this change improves performance by ~36%
for UTF-8 strings and ~52% for UTF-16 strings:
Before:
timeWriteString8[simple]_mean: 1323
timeWriteString8[complex]_mean: 2103
timeWriteString16[simple]_mean: 1427
timeWriteString16[complex]_mean: 1368
After:
timeWriteString8[simple]_mean: 846
timeWriteString8[complex]_mean: 1671
timeWriteString16[simple]_mean: 685
timeWriteString16[complex]_mean: 748
Bug: 172562452
Test: atest CorePerfTests:android.os.ParcelStringPerfTest
Change-Id: Ibacce2547ecc7a050b698cee8aa5b4e3bc45956f
