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
To support allowing for multiple <overlay> tags in one package, idmap2
must be able to generate an idmap for an individual <overlay> tag.
`idmap2 create` now accepts a --overlay-name flag that specifies which
tag to use to generate the idmap. The value of --overlay-name should be
set to the value of the android:name attribute on the <overlay> tag to
use.
If the flag is not present, idmap2 will look for an <overlay> tag with
no value for android:name.
Bug: 162841629
Test: libandroidfw_tests
Test: libidmap2_tests
Change-Id: I02316d0b88773f02c04a5d462be9825016fa496d
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
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
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
Change the signatures of Idmap::FromApkAssets and
Idmap::FromBinaryStream from
std::unique_ptr<const Idmap> func(..., std::ostream& out_error);
to
Result<std::unique_ptr<const Idmap>> func(...);
The returned pointer is still a unique pointer to ensure the dynamically
allocated memory is automatically released when no longer used. This
means that using the returned value of either function requires one of
two patterns:
const auto idmap = func(...);
if (!idmap) {
return Error(...);
}
(*idmap)->accept(...);
or
auto result = func(...);
if (!result) {
return Error(...);
}
const auto idmap = std::move(*result);
idmap->accept(...);
Note that in the second example, result must be non-const or
the call to std::move(*result) will not compile.
With this change, the entire idmap2 project has been converted to use
Result.
Test: make idmap2_tests
Change-Id: I533f4e03b99645523d94dd5f446ad76fb435f661
Teaches idmap2 to recognize policy restrictions put on overlayable
resources. If overlayable enforcement is turned on for an overlay, then
any resources defined within the overlayable api of the target will have
policy restrictions imposed on them. All resources without overlayable
definitions will continue to be overlayable without policy restrictions.
Bug: 119390857
Test: atest idmap2 and booting
Co-authored-by: Ryan Mitchell <rtmitchell@google.com>
Change-Id: I7e435648eb6e4a87b0b90a7b2a0c3f33c1516ea6
idmap2 is a reboot of the idmap project. The project aims to
- use modern C++
- greatly improve test and debug support
- interface towards AssetManager2 (instead of AssetManager)
- provide a solid foundation to add support for new features
To make it easier to verify correctness, this first version of idmap2 is
feature equivalent to idmap. Later versions will add support for new
features such as <overlayable>.
Bug: 78815803
Test: make idmap2_tests
Change-Id: I1d806dc875a493e730ab55d2fdb027618e586d16
