- Create a new package private method for
applyNewResourceDirs that takes the lock internally in
the resources manager class
- Move all locking to use the internal lock object
Bug: 186411938
Test: on device and local build
Change-Id: Idb49c76ceca51ed656fd47b82fad0afca1b2740b
This change catches exceptions while parsing and ensures that we add
something to the queue being analyzed, else we block until timeout for
each failure for each iteration leading to test timeouts on devices with
APKs that won't parse (some for expected reasons).
Fixes: 179430570
Test: atest PackageParsingPerfTest
Change-Id: I5287c48a8fa54cd44cf8b7433f8bb2536a3743b3
This change swallows expected exceptions such as ignored overlays in the
package parsing perf tests.
Test: atest PackageParsingPerfTest
Fixes: 179430570
Fixes: 179430077
Change-Id: Iab09d5b8ae426f2208e1fad1987dd811ab911fa6
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
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)
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
Moved from MtpServicePerfTests to CorePerfTests
for Benchmark Instrument
Bug: 172498127
Test: atest CorePerfTests
Change-Id: I05c38d431bee6f30982313d01ed957f24f0cb2f4
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
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
* 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
Add the benchmark for anwsering the performance issue.
* the cost of the createContextAsUser
* the comparsion between *AsUser and createContextAsUser
Test: atest CorePerfTests:android.content.pm.PackageManagerBenchmark
Bug: 171370490
Change-Id: I7da6d4127520c1132c6050472a0c1ba462ab03d3
This purposefully supports only a small handful of substitutions to
improve execution speed. Benchmarking reveals this optimized
alternative performs 6.5x faster for a typical format string.
Add Preconditions overloads that accept varargs to avoid string
formatting overhead in successful case.
Bug: 170978902
Test: atest FrameworksCoreTests:android.text.TextUtilsTest
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest CorePerfTests:android.text.TextUtilsPerfTest
Change-Id: I3fae4dc95cfc98a61c4a7f07ca0781c4a2ee3be9
We have some ideas on how to improve the efficiency of CursorWindow
transport for smaller data sets, but we want to get some benchmarking
in place to better characterize our upcoming changes.
These tests move a small, medium, and large cursor across process
boundaries, exercising the typical ContentProvider.query() flow.
Bug: 169251528
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest CorePerfTests:android.database.CrossProcessCursorPerfTest
Change-Id: Ia9e6a3195324db93a02d224e8b5108d397e3bb41
Android.bp migration broke this as the external folder should no longer
be referenced directly.
See b/169071405 for request for assets_dir filegroup support to avoid
openNonAsset.
Bug: 168845570
Test: atest android.graphics.perftests.TypefaceCreatePerfTest
Change-Id: If1ee2cadbff02ac85c60dea49de50da2e98c1b39
Renames baseCodePath -> baseApkPath and codePath -> path to better
reflect their actual meanings. Their respective JavaDoc has also been
consolidated and updated.
Also explains why the pkg field can be null, as this has been the cause
of a significant number of bugs. Also hides it behind a getter to
preempt any mutation issues. Doesn't refactor existing usages. This can
be done inline with other changes that touch that code.
Bug: 164218844
Bug: 164488334
Test: atest com.android.server.pm
Change-Id: Ia254e7cebb0ab86165e5ec42e8f8bfcf8673884b
While recently looking at pprof data, we noticed that Parcel.obtain()
and recycle() were some of the most heavily used methods inside the
system process. On the surface, this makes sense because these
methods are typically invoked at least twice for every Binder call.
Internally these methods had been maintaining a pool of cached Parcel
objects to avoid GC pressure, but unfortunately it was using an
array which resulted in O(n) scanning under heavy load, increasing
lock contention encountered by all Binder calls.
This change greatly reduces that contention by using a hand-rolled
linked list approach, mirroring android.os.Message. For a 1-thread
benchmark, this new approach has almost 2x throughput, and for a
16-thread benchmark it has almost 8x throughput.
As part of making this change we evaluated several approaches,
including using pure-GC with no pooling, a single AtomicReference,
and a pool of several AtomicReferences. To measure these we wrote
ParcelPoolBenchmark which simulates various levels of Binder load
using 1, 4 and 16 threads. Below are the relative benchmark results
compared to the previous approach before this CL:
1 thread 4 threads 16 threads
Pure GC 131.74% 32.76% 43.90%
Single AR 95.22% 25.54% 13.66%
Pooled AR 57.65% 16.21% 11.55%
Linked list 52.66% 18.06% 12.55%
On balance, the linked list approach performs well across the board,
and we bias towards it over the two AtomicReference approaches since
it performs slightly better on the single-threaded case, which is
the most representative of typical Binder load across all processes.
Bug: 165032569
Test: ./frameworks/base/libs/hwui/tests/scripts/prep_generic.sh little && atest CorePerfTests:android.os.ParcelObtainPerfTest
Change-Id: I190b1c8f7fd59855c3c2d36032512279691e2c04
1. Scope dowm synchronized block to mAdjustedDisplays put and get
2. Use SoftReference instead of WeakReference because
display's weak reference is cleared after getAdjustedDisplay
returned and the cache didn't take effects previously.
fixes: 162445376
Test: ResourcesManagerPerfTest
Before:
getDisplayMetrics_median: 3413
getDisplayMetrics_mean: 3439
getDisplayMetrics_min: 3364
getDisplayMetrics_standardDeviation: 107
After:
getDisplayMetrics_median: 3048
getDisplayMetrics_mean: 3096
getDisplayMetrics_min: 2999
getDisplayMetrics_standardDeviation: 134
Change-Id: I8a5c3ba960c8231aee78b0e7fb958bf6845d5bb5
Update the atest configs to wait for CPU/IO threshold to
stabilize and collect the perfetto trace files.
Bug: b/162452689
Test: atest PrecomputedTextPerfTest#testCreate_NoStyled_Hyphenation
Change-Id: Ib16c718f8322ebf7a9a958cbb6848a42de657a52
Exception was due to an exception from trying to get the display from
the app context, instead of an Activity context.
java.lang.UnsupportedOperationException: Tried to obtain display from a Context not associated
with one.
In order to fix that and fix the display metrics factor, the CutoutSpecificationBenchmark only run
for the resolution 1080x1920 and density is 3.5f.
Test: atest CutoutSpecificationBenchmark
Change-Id: I0be9d09a859c5b3a8c5abff11a3d06d809edf9ab
