- More moves where possible
- Better interface for PathOrDebugName creation
- function_ref as a callback
- Get rid of some obsolete Util.h code
- Shut up the logging in host mode, and ignore all calls
Bug: 237583012
Test: build + boot + UTs
Change-Id: Ia71fc1c83f17ab5ce3cac1179f74534f7ad2a3cb
No need to copy the strings as we keep them in separate
containers anyway, may just reference them
Bug: 237583012
Test: build + boot + UTs
Change-Id: I2853cd3c992ca482ed6988e0c52a4037b158d999
function_ref should be the default callback type if it's
a function argument and won't get stored anywhere
Bug: 237583012
Test: build + boot
Change-Id: I1957665436f003f7a5e758b229640c9601c28faf
Original code deleted all allocated arrays to new' them back
right away. Now, with new methods in ByteBucketArray the code
only clears the vectors without releasing the capacity, and then
proceeds to free the vectors that ended up not being used.
This speeds up theme changes (accents / dark theme etc) by
about 20%
+ small other improvements in ByteBucketArray
Bug: 237583012
Test: build + UTs + boot
Change-Id: I158af793e5476b4f3215dbe602daa872136d633f
Having keys in a separate vector improves memory usage (because
of a 4-byte padding in the original struct that's gone) and
performance (much better cache utilization when searching only
through the keys)
Test: build + UTs + boot
Bug: 237583012
Change-Id: I5ed3bada42fabfc30dfe5de39946ee5bbab22899
Uses much less space for storage and faster insertions
+ some extra moves nearby
+ get rid of string copies where views are enough
Test: build + boot
Change-Id: I2cf9a05428bf73cb25fc5422c410700c319afa53
Bug: 237583012
Given the large number of simple resources such as strings in
Android resources, their ResTable_entry and Res_value can be
encoded together in a compact way. This allows a significant
saving in both storage and memory footprint.
The basic observations for simple resources are:
* ResTable_entry.size will always be sizeof(ResTable_entry)
unless it's a complex entry
* ResTable_entry.key is unlikely to exceed 16-bit
* ResTable_entry.flags only uses 3 bits for now
* Res_value.size will always be sizeof(Res_value)
Given the above, we could well encode the information into
a compact/compatible structure.
struct compact {
uint16_t key;
uint16_t flags;
uint32_t data;
};
The layout of this structure will allow maximum backward
compatibility. e.g. the flags will be at the same offset,
and a
`dtohs((ResTable_entry *)entry->flags) & FLAG_COMPACT`
would tell if this entry is a compact one or not. For a
compact entry:
struct compact *entry;
entry_size == sizeof(*entry)
entry_key == static_cast<uint32_t>(dtohs(entry->key))
entry_flags == dtohs(entry->flags) & 0xff // low 8-bit
data_type == dtohs(entry->flags) >> 8 // high 8-bit
data_size == sizeof(Res_value)
data_value == dtohl(entry->data)
To allow minimum code change and backward compatibility,
we change 'struct ResTable_entry' to 'union ResTable_entry',
with an anonymous structure inside that's fully backward
compatible. Thus, any existing reference such as:
ResTable_entry *entry = ...
if (dtohs(entry->flags) & ResTable_entry::FLAG_COMPLEX) ...
would still work.
However, special care needs to be taken after an entry is
obtained, and when value needs to be extracted.
A compact entry will not encode a complex value, and hence
complex entries/values are handled the same way.
Change-Id: I15d97a4f5e85fab28c075496f7f0cf6b1fcd73e3
This makes the error message slightly more googleable, and gives a hint as to what kind of ID could be wrong.
This was motivated by me struggling to find the source of this error in my logs.
Change-Id: Ide248edc08d24c5577dd2198233b738641e124ec
Some apps keep adding the same resources to their theme key
objects on e.g. switching dark mode. Need to be prepared to
limit the size of the arrays, otherwise theme switching gets
slower with each toggle
+ a bit more efficient native handling
Bug: 242005877
Test: manual, 10k of theme switches with no noticable slowdown
Change-Id: Icf74770bd41ebeb0a31f527ae3616de00f23b0ae
This also includes the change to use the configs to decide which (if
any) frros to use at runtime
Bug: 243066074
Test: Manual, updated and created automated tests
Change-Id: I3f1d23e2958ad170799880b9f5eb5bd8ceb1fa67
It isn't enough to only dump the theme id and name because there is
no whole theme inheritance map. Developers need the map to figure out
why the attribute value is so strange.
A theme is a kind of style. This patch creates an API to retrieve the
parent id for any style. And, it dumps the whole inheritance between
themes until it can't find the parent style.
Test: manual test described in b/209708201#comment5
Bug: 209708201
Change-Id: I9de0e6e9aaeff7cb9fc89dc9b8a04925e84f975c
Print the best matching configuration from the given resource while
looking up for better understanding why an overlay isn't taken.
Bug: 193701453
Test: atest AssetManager2Test libandroidfw_tests
Test: manually install a target package has values and values-en,
and an overlay package only has values. Then, use overlay
lookup command to check if the output shows related info.
Change-Id: I0cb415b9e932e1d4bfd0be2e1768adeb78e7b7d0
Memory churn is high when swapping the ResourcesImpl of a Resources
object. Each time Resources#setImpl is invoked, all themes based on
that Resources object are assigned new ThemeImpl objects that are
created using the new ResourcesImpl.
ThemeImpls can only belong to one Theme object, so the old
implementation is discarded and the theme takes ownership of the new
ThemeImp.
This creates performance problems when framework overlays are toggled.
Toggling overlays targeting the framework causes all themes across all
processes to recreate and reallocate all of their themes. By rebasing
the ThemeImpl on the new ResourcesImpl without deallocating the native
theme memory, we reduce churn and produce less garbage that needs to
be garbage collected.
Bug: 141198925
Test: atest libandroidfw_tests
Test: atest ResourcesPerfWorkloads
Change-Id: I03fb31ee09c9cfdbd3c41bcf0b605607dab54ed7
Themes are represented in the native layer using an array where the
entry id of resource ids are used to index into the array. This causes
native allocation size of a theme to correlate with the largest
attribute resource id in the styles applied to the theme.
From manual testing, I determined that on average in 1P apps and
system_server only 10-20% of the space allocated for themes actually
hold theme attribute values and the rest is empty/unused space.
Using std::vector and std::lower_bound to create a sparse array
representation will reduce amount of memory allocated by themes while
having a minimal impact on the performance of querying the attributes
defined in a theme.
From testing with ResourcesPerfWorkloads, this increased time spent in
the resources synthetic benchmarks by ~1%.
Bug: 141198925
Test: atest libandroidfw_tests
Test: atest ResourcesPerfWorkloads
Change-Id: Iec512b31b0545b0898ff248cd23f074a20fff45d
Fabricated RROs do not provide assets but are stored on disk. Ensure
that the path to the frro is returned when querying for the ApkAssets
path (which is mostly for debug purposes).
Bug: 181338216
Test: enable frro, use cmd overlay lookup to see path in resolution
Change-Id: Ibf9b1bf0a995325affbf084c71b1e87c5682e734
Fixes BinaryResourceParser loading of alias chunk and makes changes
that did not get committed in 2fedba9a32.
Bug: 183411356
Test: aapt2_test
Change-Id: Ieff9166100019f38ddcfe900014709b15db24e43
To allow apps that compiled against a pre-release SDK to continue
working for a period of time after API finalization, a new tag,
<staging-public-group-final>, has been added to aapt2.
When finalizing the framework resource API, converting
<staging-public-group> tags to <staging-public-group-final> will
cause aapt2 to generate the resource table so that there is a resource
entry for the old non-finalized (staged) resource ID and another entry
for the finalized resource ID of newly finalized resources. This allows
an application that compiled against the pre-release SDK to continue
resolving resources using pre-release resource IDs.
All references to pre-release resource IDs will be rewritten to their
finalized resource IDs through the information stored in the new staged
alias chunk. This allows applications compiled against
<staging-public-group> resources to use the newly finalized
resource ID without re-compilation.
When an application is re-compiled against the SDK with
<staging-public-group-final> tags, the application will use the
finalized resource IDs.
This change limits the use of the alias chunk to the framework for S.
Bug: 183411356
Test: aapt2_test
Change-Id: Iba1c3033c3c2f32de8e4a19b58d3921c971092c4
After Theme#dump is used, all logs with a lower severity than "info"
were not being shown. Removing base::ScopedLogSeverity fixes this
issue. ScopedLogSeverity does not have any purpose in these code blocks
since the dump command is doing the theme logging at a fixed severity.
Bug: 175070283
Test: use debugger to invoke dump and verify that it does not limit
minimum severity
Change-Id: I4564d119b3672398c6b1d11cd946080cca458218
With the introduction of ResourcesProviders, not all ApkAssets have
paths on disk. Theme::SetTo and various AssetManager methods use the
path to perform equality checking on ApkAssets. This equality check
will be performed on the debug string of an ApkAssets if it does not
have a path on disk. This causes ApkAssets with the same debug name
(like "<empty>") to be seen as the same ApkAssets. Rather than using
path, the pointer to the ApkAssets should be used for equality checking
since ResourcesManager caches and reuses ApkAssets when multiple
AssetManagers request the same assets.
Bug: 177101983
Test: atest CtsResourcesLoaderTests
Change-Id: I11f6a2a3a7cc8febe3f976236792f78e41cf07e6
Fabricated Runtime Resource Overlays are overlays that are generated
at runtime and are stored in the data/ partition.
The system can fabricate RROs at runtime to dynamically theme the
device. Idmaps can now be created from APK RROs and fabricated RROs.
Rather than operating on ApkAssets, libidmap2 now operates on abstract
resource "containers" that supply resource values. Target resource
containers implement methods needed to query overlayable and target
overlay information. Currently only APKs can be loaded as target
resource containers. Overlay resource containers implement methods to
supply the mapping of target resource to overlay value and other
overlay information.
The format of a fabricated RRO is as follows:
0x00 - 0x04 : fabricated overlay magic (always FRRO)
0x04 - 0x08 : file format version
0x08 - 0x0c : crc of version + proto data
0x0c - EOF : proto fabricated overlay data
The magic is used to quickly detect if the file is a fabricated overlay.
The version is incremented whenever backwards incompatible changes are
made to the proto file format. Idmap must always be able to upgrade
fabricated overlays from previous versions to new versions, so all
previous versions must be checked into the tree.
Bug: 172471315
Test: libidmap2_tests && libandroidfw_tests
Change-Id: I4c9f29da278672e5695fb57d131a44c11a835180
ResTable_config of every ResTable_type is read from device every time
AssetManager::RebuildFilterList is invoked. For large APKs (like
framework-res.apk), this causes a large number of page faults
when accessing the config from disk. The configs are also used in the
slow path of AssetManager::FindEntryInternal, which makes it even
slower. Instead cache the config on the TypeSpec of its ApkAsset.
Bug: 177247024
Test: libandroidfw_tests
Change-Id: I66d507c4eeb2399f7558f3d9dfc53c157129ada0
Overlay and target package paths can be longer than 256 characters.
Currently, the idmap will fail to be generated if either path
is longer than 256 characters.
This change removes the 256 character limit and makes parsing variable
length strings easier in libandroidfw.
Bug: 174676094
Test: idmap2_tests && libandroidfw_tests
Change-Id: Ic240cdb8700566b2ac2ade08da58bea852e4ae0c
If for some reason the resource id cannot be resolved to a value
(there is no configuration that matches the AssetManager configuration
or some error occurs), set the resource id of the SelectedValue to the
resource id that could not be resolved. This was the behavior before
the AssetManager IncFs hardening refactor.
Bug: 173203252
Test: atest com.google.android.config.pts.PreinstalledAppsTestCase
Test: Chrome icon appears on launcher
Change-Id: Iad1760c0e246da1a4bf64d1c2ec60bb08da32d06
Merged-In: Iad1760c0e246da1a4bf64d1c2ec60bb08da32d06
Remove malloc/free of android::ResTable_entry for inline overlay
values.
Add `target_entry_inline` to the idmap format to encode inline overlay
values separate from direct mapping of target resource to overlay
resource. This reduces the number of bytes needed to represent a direct
mapping of target resource to overlay resource from 9 bytes to 8 bytes
per entry.
Fixed all idmap alignment issues that required the framework to use
"#pragma pack(push, 1)" when loading idmaps.
Bug: 170341022
Test: idmap2_tests and libandroidfw_tests
Change-Id: Iab4d3902508f02773464724913e0ee966e3689e4
If an application targets R+, prevent the application from being
installed if the app has a compressed resources.arsc or if the
resources.arsc is not aligned on a 4-byte boundary. Resources tables
that cannot be memory mapped have to be read into a buffer in RAM
and exert unnecessary memory pressure on the system.
Bug: 132742131
Test: manual (adding CTS tests)
Change-Id: Ieef764c87643863de24531fac12cc520fe6d90d0
Before overlays could reference internal resources, overlays were
added to AssetManagers before shared libraries. Overlays are now
loaded as shared libraries so they must be assigned package ids
after non-overlay shared libraries so enabling and disabling
overlays does not affect the package ids of the non-overlay shared
libraries.
Since overlays are added to the end of the AssetManager by
ResourcesManager, enabling and disabling overlays will not change
the assets cookie of shared libraries loaded through ResourcesManager,
but it will change the apk assets cookie or overlays added through
AssetManager#addAssetPathAsSharedLibrary.
The package ids of shared libraries added through
AssetManager#addAssetPathAsSharedLibrary will not be affected by
overlays since overlay package ids are assigned last.
Bug: 146685730
Test: CtsHostsideWebViewTests
Change-Id: If7ea17d51b18769bf2465e29af3ae6a71004d06c
This change must be reverted because it broke packages with the same
package name but different package ids loaded at once.
Bug: 146685730
Test: MultiSplitInstallTest
This reverts commit fe50d739f7.
Change-Id: If6364fd660c76284452f77e7d4f09a3df9dede1d
This API allows a directory to be loaded as if it was a zipped APK.
This is a substitute for the DirectoryAssetProvider API that
currently does not work in the native layer.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: Ia13e15653e75b421423dd56f9fe89e183ab4cb9a
When shared libraries are assigned package ids in a different order
than compile order, bag resources that use attributes from both
multiple libraries will not be sorted in ascending attribute id order.
This change detects when the attribute ids are not in order and sorts
the bag entries accordingly.
The change is designed to be less invasive. Deduping the GetBag logic
should probably be spun off in a separate bug.
Bug: 147674078
Test: libandroidfw_tests
Change-Id: Id8ce8e9c7ef294fcc312b77468136067d392dbd0
Overlays targeting shared libraries should be loaded into the
resources of every target that depends on the shared library.
Static shared libraries are currently not supported because overlays
should override all versions of static shared libraries and there is
not currently support for an overlay targeting multiple APKs.
Also created a test instrumentation and host test suite for testing
overlays and packages on the system image.
Bug: 140790224
Test: atest OverlayRemountedTest
Change-Id: I20a217b6368d6cf92b2b9f46908fd58012933f72
When a shared library package is loaded into an AssetManager, the
shared library will be assigned a unique package id. Subsequent
AssetManaagers that load a shared library of the same package name
as the original shared library will use previously assigned package
name. Shared libraries will have stable package ids throughout the
lifetime of application.
Bug: 140790224
Bug: 128496033
Test: libandroidfw_tests
Test: third-party app no longer crashes on open
Test: atest CtsHostsideWebViewTests
Change-Id: Idc0315be21ea00b74d1a918b7083ad655104c008
This change allows RROs to reference their own internal resources as
expected.
Overlays are loaded as shared libraries so they can have their own
resource id space that does not conflict with the resource id space of
the target or other overlays.
References to overlay resources that override target resources now
appear as references to the target resources.
Overlay values that are inlined into the xml file specified using
android:overlayResources are now able to be used at runtime.
See go/rro-references for more information.
Bug: 135943783
Test: idmap2_tests
Test: libandroidfw_tests
Change-Id: Ie349c56d7fd3f7d94b7d595ed6d01dc6b59b6178
ResourceLoaders allow inserting another .apk/.arsc into AssetManager's
resource resolution search. The effect is similar to overlays,
where a entry of >= config later in the path list will return that
ApkAsset's resource value instead.
Because loading from an .arsc is supported, which doesn't contain
any actual files, ResourceLoader exposes loadDrawable and
loadXmlResourceParser to allow an application load those files from
anywhere or create them in code.
The data being loaded is either pushed into an .apk or .arsc that
mocks itself as the package being "overlaid" and is passed in
through ResourcesProvider, an interface with static methods that
supports loading from a readable path on disk or a FileDescriptor.
The APIs are accessed through a Context's getResources(), which
has been changed to be unique per "Context-scope", which is usually
the lifetime of the Java object. The exception is that Activities
who get their Resources object persisted across recreations
maintain that logic for persisting ResourceLoaders.
Bug: 135270223
Test: atest FrameworksResourceLoaderTests
Change-Id: I6929f0828629ad39a21fa155e7fec73bd75eec7d
Allows retrieval of a string representation of overlayable resources
that can be compared during CTS testing to verify that the overlayable
resources on device match the expected overlayable API.
Bug: 135052616
Test: libandroidfw_tests
Test: atest OverlayHostTest
Change-Id: I613f28c202a0904a917577f932d072111c1aa7bd
Do not print warnings when an APK loaded into aapt2's symbol table has a
compressed resources.arsc. This log is helpful at runtime since
compressed arscs take longer uncompress.
Bug: 130617130
Test: manual
Change-Id: I52847663ad8f46ba00d3dd1ebb2292ab54737680
These traces are small and noisy, so they hurt performance more than they help.
This reverts commit c37457799b.
Test: m
Bug: 132721345
Change-Id: I9ef719f54f2bc8a54f23e88f46d74e35417a6519
Hard-coded values in styles can be copied between AssetManagers even if
the source package is not present in the destination AssetManager. Only
references and strings should be prevented from being copied over
because they would be invalid in the destination AssetManager.
Bug:126400561
Test: manual
Change-Id: I970a3e961763b2c003c15b950d864a9a0b615022
Target packages use <overlayable> to opt-in to RRO. While this works for
resources, it does not support assets. For security reasons, remove the
ability to overlay assets via RRO for now: a future change may extend
<overlayable> to include assets.
Test: atest OverlayDeviceTests
Bug: 120867881
Change-Id: Ie0b6897f0586ea8b9d75f357e216904e25d4dc7b
Style resid stacks should also be invalidated when invalidating
AssetManager caches.
Bug:117176857
Test: manual
Change-Id: I28224597adf4b0af8326bd788eab289e4ba60418
AAPT2 uses AssetManager2 as the implmentation of its symbol table.
When generating the the R.java, AAPT2 adds information about styleables
in the comments. If the first symbol table checked by the delegate is an
AssetManager2 symbol table and it does not contain the styleable
attribute being searched for, a bogus error is printed and the resource
is found in a later symbol table.
Bug: 126596328
Test: m -j Settings && diffed generated java files
Change-Id: If86a9d62fd72317525dffa862be1267621f93afd
util::mkdirs iteratively creates each directory of a specified path. For
windows, Calling mkdir on only the drive letter or on the extended path
prefix (\?\\) will result in an error. Start after the long path prefix
and the drive letter.
This also changes AAPT2 to use AssetMaanager2 to retrieve symbols from
the symbol table. AssetManager2's zip library uses _wopen to open
windows files.
Bug:123251200
Test: aapt2_tests.exe
Change-Id: I26169d83b22d441485de3c49d63a6c4ed710e292
Add a new, hidden method to AssetManager to extract a mapping
overlayable name -> overlayable actor for all <overlayable> blocks in a
package. [This will eventually be used to check if the caller of the OMS
AIDL API is the registered actor for a given overlay.]
Also, teach AssetManager2 to not accept packages that re-use the same
overlayable name. [Such packages have always been ill-formed.]
Bug: 123894537
Test: make libandroidfw_tests
Change-Id: I1117fd3503f04fe4c73eb7114901e022508f4d9e
