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
Fix comments that refer to <overlay-config-signature> as
<config-signature>.
Bug: none
Test: build
Change-Id: I1d3e5e66ec3da993082f3441997b0d243d61520b
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
Alongside SIGNATURE and ACTOR_SIGNATURE policies, add CONFIG_SIGNATURE
policy to overlayable that overlay fulfills if it is signed with the
same certificate as the reference package whose package name is
declared in 'config-signature' tag of SystemConfig and is vetted by
OMS that it's a system pre-installed package.
BUG: 158726924
TEST: regular aapt2, idmap2, OMS tests
Merged-In: I645ee72271496008742886274be0d63a2985201b
Change-Id: I645ee72271496008742886274be0d63a2985201b
If the fulfilled policies change without the contents of the target
and overlay APKs changing, the idmap for the overlay should be
regenerated. This change adds fulfilled policies and enforce
overlayable to the idmap header so that idmap2d can determine if the
polices or enforce overlayable changed from what was used to generate
the idmap.
Bug: 119328308
Test: idmap2_tests
Test: atest RegenerateIdmapTest
Change-Id: I96f970e82b5243be01b205ac2cb6ab249c6100bc
To make it easier to add the actor policy in a follow up CL,
move most of the policy handling to a central location.
The strings and transformation between strings and flags is
now handled in libidmap2policies, with libandroidfw
containing the single source of policy flags.
This also extracts all the test resource IDs into an R.h
so they can be swapped without having to edit a dozen files
each time.
Bug: 130563563
Test: m aapt2_tests idmapt2_tests and run from host test output
Test: atest libandroidfw_tests
Change-Id: Ie533c9cebf938215df7586f00c38763ae467e606
android:resourcesMap is not working at all with shared libraries.
This change fixes that so overlays built as shared libraries can
use the attribute.
Bug: None
Test: idmap2_tests
Change-Id: I767481f88c58892a3818a919616056291b09b57e
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
Add a new variable length string to the idmap file format. This string will
hold debug information like fulfilled policies and any warnings triggered while
generating the file.
Bump the idmap version to 3.
Adjust the idmap header definition in ResourceType.h to take the new string
into account.
Example debug info:
$ idmap2 create \
--target-apk-path frameworks/base/cmds/idmap2/tests/data/target/target.apk \
--overlay-apk-path frameworks/base/cmds/idmap2/tests/data/overlay/overlay.apk \
--idmap-path /tmp/a.idmap \
--policy public \
--policy oem
$ idmap2 dump --idmap-path /tmp/a.idmap
target apk path : frameworks/base/cmds/idmap2/tests/data/target/target.apk
overlay apk path : frameworks/base/cmds/idmap2/tests/data/overlay/overlay.apk
I fulfilled_policies=oem|public enforce_overlayable=true
W failed to find resource "integer/not_in_target" in target resources
0x7f010000 -> 0x7f010000 integer/int1
0x7f02000c -> 0x7f020000 string/str1
[...]
$ idmap2 dump --idmap-path /tmp/a.idmap --verbose
00000000: 504d4449 magic
00000004: 00000003 version
00000008: 76a20829 target crc
0000000c: c054fb26 overlay crc
00000010: ........ target path: frameworks/base/cmds/idmap2/tests/data/target/target.apk
00000110: ........ overlay path: frameworks/base/cmds/idmap2/tests/data/overlay/overlay.apk
00000210: ........ debug info: ...
00000294: 7f target package id
00000295: 7f overlay package id
[...]
Also, tell cpplint to accept non-const references as function parameters:
they make more sense as out-parameters than pointers that are assumed to
be non-null.
Also, switch to regular expressions in the RawPrintVisitorTests: no more
manual fixups of the stream offsets! Tell cpplint that the <regex>
header is OK to use.
Bug: 140790707
Test: idmap2_tests
Change-Id: Ib94684a3b4001240321801e21af8e132fbcf6609
This change modifies the idmap file format to allow for target resources
to map to arbitrary type/value combinations and to allow overlay
resources to be mapped back to target resource ids so references to
overlay resources can appear as references to target resources at
runtime.
The mappings of target resources to overlay resources and vice-versa are
both encoded as sparse arrays. Instead of looking up a resource by
indexing into an array that maps to the overlay resource id, the runtime
will binary search over the sparse array to find the type and value that
overlays the target resource.
Bug: 135943783
Test: idmap2_tests
Change-Id: I5d5344cdb7fe35f4f2e8d6781016299dea5d1e20
This change introduces idmap parsing of <overlay> tags.
The <overlay> tag allows one to explicitly map resources in the target
to either a resource in the overlay or an inline attribute value.
Use the android:resourcesMap atttribute on the <overlay> tag in the
android manifest to specify a file to provide the resource mapping.
Bug: 135943783
Bug: 135051420
Test: idmap2_tests
Change-Id: I1740dcdc01849c43b1f2cb8c6645d666dbb05dba
