Idmap now checks if the version of the vendor partition is greater than
or equal to 29 or a development codename to enable enforcement of
overlayable resources.
Bug: 119390857
Test: manual
Change-Id: Ica25800432993beb7464436d4fba7cb391e621ef
idmap2 scan was not allowing oem and odm overlays to fulfill the oem and
odm overlayable policies.
Bug: 129735590
Test: manual
Change-Id: I230f72b37b95a997d32f2ef136b6301d970a413c
This change adds parsing, encoding, and validating of odm and oem
overlayable policies to aapt2, libandroidfw, and idmap2.
Bug: 121033532
Test: aapt2_tests, idmap2_tests
Change-Id: Ifc0d4b6c9f9c37e06b2988abade69dbb277c50c2
If one static overlay fails to have its idmap generated, continue
scanning other overlays.
Bug: 130324774
Test: idmap2_tests and manual
Change-Id: I06a74c844ebc81dcfb5b50e8c9a30a68c7e4ffb0
When printing warning messages while generating idmaps, put the vertical
bar chracater in between the policies.
Bug: none
Test: manual
Change-Id: I8efee753d9ed7ce99ccafd49b6c8744eea031839
Passing policy flags to the Verify command of idmap2 was causing the
command to fail to parse and run create again even when the target and
overlay did not change. This change allows verify in scan to work
correctly again.
Bug: 127860892
Test: confirmed that create is not run on a successive reboot
Change-Id: I7b9c9d81c7aef6b4c80fb8b87a1e929e82fc3b84
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
- Add hasCode=false to overlay packages as a workaround for b/124375490
- Sprinkle Thread.sleeps in InstallOverlayTests in an attempt to make
the tests less flakey when executed on emulator
Test: atest OverlayDeviceTests OverlayHostTests
Change-Id: I745a8477ed5e72db572737a0af0e59478893e42b
Idmap2 is not enforcing overlayable on Q overlays and instead on P
overlays. This corrects this behavior.
Test: idmap2_tests
Bug: 128932015
Change-Id: I7e45a965d3b165dae7ed7377d0911afd62f63983
Change the signature of the idmap2 commands (Create, Dump, ...) to
return Result<Unit> instead of bool. This removes the need to pass in an
ostream for error messages: instead, those messages are part of the
returned Result.
Consolidate error messages: texts in Error objects should not be
prefixed with "error:", that is the responsibility of the outer-most
caller (i.e. main()).
Test: make idmap2_tests
Change-Id: I074881b3d1982ea8f4be5752161ac74b14fcba95
Overlayable policies were not being passed correctly to idmap2 create
from scan. This fixes that and adds better error messages for when
policy failures occur.
Bug: 127860892
Test: manual
Change-Id: I8fae20884a75f4c57a0eb4aafdb4e09da3ebaf93
In order to lift the signature/preinstalled install restrictions on overlays,
we must protect packages that have not migrated to <overlayable> from
being overlaid. If a resources is not specified as overlayable and the
overlay does not define an <overlayable>, require the overlay to be
preinstalled or signed with the same signature as the target.
Bug: 121016681
Bug: 125933494
Test: idmap2_tests
Change-Id: I38f520929031b743e4bbe0366a9be55aac5795c5
Remove the old std::optional based Result class, replace uses with the
new std::variant based Result class.
Test: make idmap2_tests
Change-Id: I401cb36e5af06133a2872d835cf29bfb0b106597
Handles the new signature policy for overlayable resources.
Bug: 119402606
Test: idmap2_tests target
Change-Id: I7961e04a879c40c240ed9097bb510addb8b56680
Thanks to the ART team for art/libartbase/base/systrace.h which served
as inspiration for the SYSTRACE macro.
Bug: 119761810
Test: run idmap2_tests on device while capturing systrace
Change-Id: I81112ae8e58daf20ebed33ef8b0f5a0caa4dbc73
The CRCs stored in the idmap file header are copies of the zip file CRC for the
resources.arsc entry in the target and overlay package apks, and are used to
quickly check if either package's contents has changed, which in turn means the
idmap file must be recreated.
With the introduction of named targets, just checking the resources.arsc file is no
longer sufficient: an overlay package could be installed with targetName="a" and
updated to targetName="b". This change is not reflected in the resources.arsc file,
only in the AndroidManifest.xml.
To account for this, update the CRC in the idmap file header from
CRC(resources.arsc)
to
CRC(resources.arsc) ^ CRC(AndroidManifest.xml)
Test: make idmap2_tests
Bug: 119761809
Change-Id: Ieb0c6b466ac23eb81a2670a32309fa46ade5c5c8
Fix two errors detected by static-checks.sh:
- bpfmt: remove -s flag (sort arrays) since it makes no sense to order
clang-tidy flags alphabetically: flags must be passed to clang-tidy
in the order specified to make sense
- cpplint: allow NOLINT(cert-dcl50-cpp)
Test: cmds/idmap2/static-checks.sh
Change-Id: I6677f8e7504551746edae458acd523e643044c7e
Add a new version of the Result class that functions like the old
Result, but in case of an error, also encodes a string detailing the
error. This will allow us to write the following type of code:
Result<Foo> CreateFoo() {
if (...) {
return Error("errno=%d", errno());
}
return Foo(...);
}
auto foo = CreateFoo();
if (!foo) {
std::cerr << "error: " << foo.GetErrorMessage() << std::endl;
abort();
}
std::cout << "foo=" << *foo << std::endl;
This commit only adds the new Result class. A later change will replace
uses of the old version.
Test: make idmap2_tests
Change-Id: I674d8a06866402adedf85f8514400f25840d5eda
If a package defines overlayable resources, then do not allow resources
that are not defined as overlayable to be overlaid.
Bug:123600120
Test: idmap2_tests and cts-tradefed run cts -m CtsRROTestCases
Change-Id: I35120a97ccf4650e67c7ba65a60f4f3c51b0e627
Adds android:targetName to the overlay manifest attributes and
PackageParser reads the name into PackageInfo. Specifying
android:targetName on an overlay allows the overlay to be associated
with a particular set of overlayable resources. The overlay can only
override the values of the resources defined within the target
overlayable element.
Test: idmap2_tests
Bug: 119390855
Bug: 110869880
Change-Id: I1128274af4cae983f61ae15cdfcbface63233ff2
Deny write access to /data/resource-cache for UIDs other than root and
system. While this is already handled by SELinux rules, add an
additional layer of security to explicitly prevent malicious apps from
messing with the system's idmap files.
Test: make idmap2_tests
Change-Id: Id986633558d5d02452276f05f64337a8700f148a
Bug: http://b/122481018
Upcoming clang update has a clang-tidy warning about using c arrays and
instead use std::array:
warning: do not declare C-style arrays, use std::array<> instead
Disable this warning for now (even before the new clang update lands)
since clang-tidy doesn't complain about flags it doesn't know.
Test: Build with new clang.
Change-Id: I971b84301e6cd1180326bc54711d0be193f09ccb
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
Since static overlays are still managed by the native layer, we must
order the overlays during the initial scan so the are put into the
AssetManager in the correct order.
Bug: 121002654
Test: build_success and manual verification of ordering
Change-Id: Id46baed8f836c3b4b86d19d58aee5fd06ff0b762
