| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Don't copy the string unless it's a new locale, and limit
the allocations as well
Test: unit tests
Flag: EXEMPT minor performance improvement
Change-Id: Icfe433ab211a0ca22882bd579415a96dc40db30a
|
|
Test: Automation
Fixes: 377974898
Fixes: 398541237
Fixes: 398086579
Fixes: 396884481
Fixes: 396992602
Flag: android.content.res.layout_readwrite_flags
Change-Id: Ibdabb27689a95eba7b53490ea8651c947beca226
|
|
99b48bdd872e8b2a48904f513b4b9feb8299750e
Change-Id: I6d6e19bc81842971d6af6aeb3b19fc84b808720a
|
|
|
|
This change introduces hidden API's for setting constraints
for enabling RROs. Currently, the constraints are of the following
types:
1. Display id constraint: This can be set for a RRO if the RRO is
desired to be applied on only the apps running on that specific
display.
2. Device id constraint: This can be set for a RRO if the RRO is
desired to be applied on only the apps running on that specific
device (for apps running on the default device, this would be
Context#DEVICE_ID_DEFAULT, and for apps running on a virtual device,
this would be the id of the virtual device).
An overlay would be enabled when any of the given constraints are met.
Constraints can only be set while enabling a RRO. Re-enabling a RRO
with different constraints updates the constraints for the RRO.
This change facilitates the writing of the constraints for RROs
into the correspodning idmap files, and also persists them as part
of the settings used by OverlayManagerService. The filtering of
resource overlays based on constraints during resource resolution
will be done in a follow-up CL.
Test: atest FrameworksServicesTests
Test: atest idmap2_tests
Test: atest libandroidfw_tests
Test: atest CtsResourcesTestCases
Bug: 371801644
Flag: android.content.res.rro_constraints
Change-Id: I0cad58bfb5b9b90105e2ef839c58147b9a50767c
|
|
8c1b836852
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/3471369
Change-Id: I46d68a04b213a71d2c5a3b4dd7350a669d0fb17e
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
on aosp_cf_x86_64_phone-userdebug, the benchmark result is
libandroidfw_benchmarks#BM_LocaleDataLookupIsLocaleRepresentative: PASSED (0ms)
cpu_time_ns: 55.07607273354898
real_time_ns: 55.19976479889459
libandroidfw_benchmarks#BM_LocaleDataLookupLikelyScript: PASSED (0ms)
cpu_time_ns: 87.99205759931041
real_time_ns: 88.19010674954154
With the unordered_set and unordered_map, the result is
libandroidfw_benchmarks#BM_LocaleDataLookupIsLocaleRepresentative: PASSED (0ms)
cpu_time_ns: 113.01179143336402
real_time_ns: 113.3695957412614
libandroidfw_benchmarks#BM_LocaleDataLookupLikelyScript: PASSED (1ms)
cpu_time_ns: 109.63471229710265
real_time_ns: 109.91545630537807
With std::binary_search, the result is
libandroidfw_benchmarks#BM_LocaleDataLookupIsLocaleRepresentative: PASSED (0ms)
cpu_time_ns: 123.82590108826805
real_time_ns: 123.98891085230711
Let's keep the current implementation, and add a TODO about the disk
size.
Bug: 383096413
Test: atest libandroidfw_benchmarks
Change-Id: Iaa5f1ab5ac4dcc6bbdd3c4b66fe129c61d75c1d1
|
|
- add a test case for the null last entry in sparse types
- add comments explaining what mLength is for sparse types
- remember if the type is sparse in a member
- pragma once
Test: atest libandroidfw_tests
Flag: EXEMPT bugfix / refactor
Change-Id: I7c2e516e8887f5fd1c2ab35b20fb49864b6761b6
|
|
This causes confusion, is hard to debug (because the debuggable="true" behavior is more lenient), and doesn't have any obvious value (since it's trivially worked around by renaming "executable" to "libexecutable.so" anyway).
Flag: EXEMPT bugfix
Bug: https://issuetracker.google.com/160129591
Change-Id: I6a27a5b13df7bdc3fd3f76d8c8682867afded624
|
|
* changes:
Revert "[res] Optimize isUpToDate() for ApkAssets"
Revert "[res] Optimize few functions for dtoh() as a noop"
Revert "[res] Don't create extra asset provider when not needed"
Revert "[res] Dump resources timings in dumpsys"
|
|
Revert submission 31021037
Reason for revert: Droidmonitor created revert due to b/388342212. Will be verifying through ABTD before submission.
Reverted changes: /q/submissionid:31021037
Change-Id: I7d0eeaf7476c66f5276c68320f93f2b56953d531
|
|
* changes:
[res] Dump resources timings in dumpsys
[res] Don't create extra asset provider when not needed
[res] Optimize few functions for dtoh() as a noop
[res] Optimize isUpToDate() for ApkAssets
|
|
LocaleDataLookup.h" into main am: b4966de272 am: 60786ca61d
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/3432461
Change-Id: Ic9e1b2401f0432ed0f1777e216e171e2a17527e4
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
It helps adding new unit tests, and fixing correctness and performance
bugs later.
Bug: 386340812
Test: atest libandroidfw_tests
Change-Id: I4d3ee1333637d2cd22d5fdfad730935951feeccb
|
|
This is the most called function in the whole Resources
codebase, and it often takes a millisecond+ to just check if
the underlying file still exists.
This CL optimizes several aspects of the function
- knowing that all /data/ paths are writable, return early from
the isReadonlyFilesystem() without a syscall
- use the same getFileModDate() function for all native classes
instead of the custom stat-based code
- skip the modification time getter for all readonly filesystems
when we know that the idmap, overlay and target can't change.
- add some default-disabled logging code to print timings for
easier performance measurement
Bug: 319137634
Test: build, boot and atest libandroidfw_tests
Flag: EXEMPT performance-critical code that can't have two
versions
Change-Id: I0f801bef386f202eda775cca9657e2a0b6b55c95
|
|
* changes:
[aapt2] Improve "dump chunks" output
[res] Make type iteration more efficient in aapt2
|
|
This reverts commit e2cc267a14a4eccd54b9fe1f7d3c8d860ac80a4f.
Reason for revert: relanding with the macos build fix
Original comment:
We used to track the modification time in seconds, which is both
imprecise (an apk installation + idmap generation can easily
take less time) and forces us to wait for >1s in the tests to
just check if up-to-date checks work.
This change updates the time to nanosecond resolution where
supported (hm, MinGW for Windows, hm), as the underlying
OS API provides
Test: build + atest libandroidfw_tests idmap2_tests + boot
Flag: EXEMPT minor change
Change-Id: I49c36b0a6ae6e677fa1259090da20ccc7a224b99
|
|
The iterator type that is only used in aapt2 currently
used to perform a binary search for every dereferencing call of
a sparse type table, while it knows for sure the position of the
next element in constant time.
+ Add a test for a sparse type iteration
Test: atest libandroidfw_tests
Flag: EXEMPT bugfix / refactor
Change-Id: I70f74b1a1cfb4deffd1592a87c31501388eaf46c
|
|
ApkResourcesContainer class has a variant that is either a zip
file object, or a full blown AssetManager with ApkAssets with
the same zip file inside. But if transition from one to the
other fails, it could end up in a state with neither, causing a
crash if the users try accessing it.
This change ensures that:
1. The zip file object is only moved into ApkAssets if the
loading succeeds
2. If any part of the further initialization of ResState fails,
we take the zip file out and put it back into the variant
+ Add unit tests for both ApkAssets and libidmap2 to ensure
they don't crash in any of those scenarios (they used to)
+ Enable root tests in libidmap2 as they were never running
Flag: EXEMPT bugfix
Bug: 381108280
Test: atest libandroidfw_tests idmap2_tests + boot
Change-Id: I8f4803fdf03a41ba7a6892e6aed07f04b77788ce
|
|
Idmap format is currently storing sorted mappings for the
overlays: be it target id -> overlay id, or target id ->
frro data, or the reverse overlay id -> target id list
All of these require binary search for finding the right entry,
and this binary search always touches just 4 bytes of the key,
skipping over all remaining bytes of value. This usually doesn't
make much of a difference for the smaller idmaps but in case of
the larger ones binary search has to load a whole bunch of
RAM into the CPU cache to then throw at least half of it away.
This CL rearranges all mappings into two separate lists: the
first one only contains the sorted keys, and the second one
stores the corresponding data in the same order. This means the
search can only touch the minimum amount of RAM and disk pages,
and then jump exactly to the value of the element it found.
We don't have any benchmarks that would _directly_ capture the
speedup here, and the Java resources_perf ones are too noisy to
make a clear call, but overall they look like some 3-5% speedup
for the overlaid lookups
Test: atest libanrdoidfw_tests idmap2_tests libandroidfw_benchmarks
Flag: EXEMPT performance optimization
Change-Id: I450797f233c9371e70738546a89feaa0e683b333
|
|
This reverts commit fff1d48f432741160019a9266728097f10bd2189.
Reason for revert: <Potential culprit for b/365676142 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.>
Change-Id: I6b0a0bd67a14e4738a8cd64be2214840d02eee3f
|
|
We used to track the modification time in seconds, which is both
imprecise (an apk installation + idmap generation can easily
take less time) and forces us to wait for >1s in the tests to
just check if up-to-date checks work.
This change updates the time to nanosecond resolution where
supported (hm, MinGW for Windows, hm), as the underlying
OS API provides
Test: build + atest libandroidfw_tests idmap2_tests + boot
Flag: EXEMPT minor change
Change-Id: I37635e6f3b62aff3b4794912ac585a9ef5ea7a1e
|
|
Test: build + boot
Flag: EXEMPT minor change
Change-Id: I21694756674169388407e2b3c7dce850ff19e354
|
|
When a memory chunk gets returned into BigBuffer, it may have
some data written already. BigBuffer is supposed to give out
zeroed memory, so BackUp() needs to zero it as well
Bug: 336758568
Bug: 342579978
Test: unit test + bundletool on the attached aab
Flag: EXEMPT bugfix
Change-Id: I8ecd60e84dbe16570a92d82370d1633af72599c8
|
|
This is the heaviest operation during the configuration change
handling, as we recreate the asset manager object and rebase
all existing themes on that object as soon as any assets
change. The optimization here replaces the repeated binary
search + insert in a middle of an array with a merge of two
sorted arrays in place, achieving over 7x speedup:
Before:
#BM_ThemeApplyStyleFramework 9722.817566754931 ns
After:
#BM_ThemeApplyStyleFramework 1305.8760730843824 ns
It also adds a detailed explanation of the algorithm and its
assumptions to make it easier to optimize/debug it later.
Flag: NONE A performance regression fix, flag check is too slow
Bug: 345562237
Test: build, boot, atest + performance tests
Change-Id: I979e17cf4837cc8853a8d54cb4cea2a9631c3136
|
|
- Create a new benchmark targeting the Theme::Rebase() method
specifically
- Fix the benchmark data so it doesn't try to run every data
apk as a test on the device, and include the missing projects
- A minor style improvement
Flag: NONE A set of benchmark improvements
Bug: 345562237
Test: build, boot, atest + performance tests
Change-Id: If9d92a288ec9513ef9cefbb77490a49d4fb8d596
|
|
This reverts commit 917043bc2586743afda5a21386893fa8c787800b.
Reason for revert: Roll forward with fix
Test: Automatic
Bug: 296324826
Change-Id: I42a0b48c02fd497b2174c0c65f300265202f7ab1
|
|
6ee36e2b90 am: 6655b76c66 am: e593ac80cf
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/24604702
Change-Id: Ic147b562773897fae7c028a27b2c48ece51a8cea
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Bug: 295394788
Test: make checkbuild
Change-Id: I95264e8bfc96a5adb7f7cc55a24dc0e8c126371d
|
|
"cherrypicker-L84000000961835147:N85300001385845465" into udc-dev am: 76eed81379
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/24029253
Change-Id: I9bd0504bc1add3123ccc0f1b996985cc06464c0c
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/23988011
Change-Id: Ia012b97dfaf169f0cb17c16080e0fc37c87cb626
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
|
|
am: 64441287a5 am: 0e91b72694
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/24484497
Change-Id: I1436ad48bfcbe44c5fc67d41f76cd86cd6a62048
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Bug: 295394788
Test: make checkbuild
Change-Id: I82d6899d8c15a10b15399c39177290012bb5f13b
|
|
This reverts commit c57041138696b7a152a80513c67793fac1cad7c4.
Reason for revert: roll forward with fix
Test: manual
Change-Id: Ic4d1aa892efd9058d21ac88709fc565fd5f61909
|
|
|
|
This reverts commit 04cf00dc276789b890b7eaa717dddd85832e8151.
Reason for revert: causes b/292445325 and b/292321908
Fixes: 292445325
Fixes: 292321908
Change-Id: Idb44723ad7e8b14b737305d194f79dd70630621d
|
|
|
|
This reverts commit cc6ff3876e395040748627353b7384e49d90e4f9.
Reason for revert: Fixed the tests in a separate change
Test: ran the previously failing tests in ab
Change-Id: I588d563375388ab1030c9de2072efe865286425c
|
|
AssetManager needs to lock (promote()) apk asset weak pointers
to use them in pretty much any operation, and often mulitple
times for the same object.
This CL introduces a concept of an 'operation' in AssetManager,
and adds a cache for the locked assets that are retained until
the end of that operation. This way we only need to lock each
assets object exactly once, losing pretty much no performance.
Benchmarks all returned to the pre-memory-safe state values.
Bug: 280951693
Bug: 197260547
Bug: 276922628
Test: UTs + native benchmarks + java benchmarks + boot
(cherry-picked from https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/23146856)
Merged-In: I26ef88df4f6267b5e8b89f1588f2382db74030c0
Change-Id: I26ef88df4f6267b5e8b89f1588f2382db74030c0
|
|
This reverts commit cf6e79f809034386b04ae551db815ab087f76c0a
Updates:
Prepare the shared pointers for the whole operation at once
instead of re-locking them on each iteration.
Still a regression of about 5% for changing theme's
AssetManager object, vs the original 40%
+ change the log message to a warning as it doesn't break
the app
Original comment:
Use reference counted pointers for ApkAssets
The primary reason for memory corruption is freed ApkAssets
Java expected them to only be freed in the finalizers, but
there are explicit close() calls now, destroying objects that
are still in use in some AssetManager2 objects
This CL makes sure those AssetManagers don't assume ApkAssets
always exist, but instead tries to lock them in memory for any
access
It also adds logging in case of deleting an assets object with
any weak pointers still existing. Those will get into the
bugreports attached to related bugs to help with investigation.
Benchmarks don't regress, and the device appears to be working.
Given that the crashes used to be pretty rare, let's wait for
any new reports or lack of those.
+ add a missing .clang-format file to the jni directory
+ enabled C++23 in the project that uses AssetManager headers
Bug: 197260547
Bug: 276922628
Test: unit tests + boot + benchmarks
Old change id: I495fd9e012fe370a1f725dbb0265b4ee1be8d805
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:b3455190124b41e2deb1774d9c05b396b73b41a2)
Merged-In: Id668fbcf07db17b09691a344c04e98df83006f97
Change-Id: Id668fbcf07db17b09691a344c04e98df83006f97
|
|
|
|
This reverts commit 09158c693f2e29bf0a3403355b32ba8750977113.
Reason for revert: causes test failures
Fixes: 290377322
Fixes: 290377794
Fixes: 290377713
Change-Id: I69b6fe1e1ce597656ff80ccd4446f12c76ffc19b
|
|
|
|
Test: manual
Bug: 117306409
Change-Id: I46fcf04e1137cfa4cc6d238f88ad6c683fa87376
|
|
1. Turns out libcxx's try_emplace() on unordered containers is
slower than even find + insert pair. Revert the 'optimization'
back to get the performance back
2. Fix the cache invalidation in AssetManager to keep the caches
coherent.
Bug: 282264161
Test: build + UTs + boot
Change-Id: I823215beb863c0ffaf703c70bb4358c331da8251
|
|
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/23438365
Change-Id: I7e0c9f6d6d93789227a72ae1f6b0042e46e96014
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
|
|
Bug: 213170822
Remove the code that CursorWindow::writeToParcel() uses to ensure slot
data is 4-byte aligned. Because mAllocOffset and mSlotsOffset are
already 4-byte aligned, the alignment step here is unnecessary.
CursorWindow::spaceInUse() returns the total space used. The tests
verify that the total space used is always a multiple of 4 bytes.
Test: atest
* libandroidfw_tests
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:5d4afa0986cbc440f458b4b8db05fd176ef3e6d2)
Merged-In: I720699093d5c5a584283e5b76851938f449ffa21
Change-Id: I720699093d5c5a584283e5b76851938f449ffa21
|
|
Bug: 213170822
Remove the code that CursorWindow::writeToParcel() uses to ensure slot
data is 4-byte aligned. Because mAllocOffset and mSlotsOffset are
already 4-byte aligned, the alignment step here is unnecessary.
CursorWindow::spaceInUse() returns the total space used. The tests
verify that the total space used is always a multiple of 4 bytes.
Test: atest
* libandroidfw_tests
Change-Id: I720699093d5c5a584283e5b76851938f449ffa21
|