Add automated test cases for runtime resource overlay, iteration 2.
The test cases are a mixture of 'adb shell' commands and regular
instrumentation tests. The device is rebooted between tests to setup
different overlay scenarios for framework-res.apk.
To verify Runtime resoure overlay, iteration 2, run
$ frameworks/base/core/tests/overlaytests/testrunner.py
For a list of supported options, run
$ frameworks/base/core/tests/overlaytests/testrunner.py --help
Change-Id: I692aa1a7ad073efd116b24f9ec7f197dfd65dfef
Support any number of overlay packages. Support any target package.
UPDATED PACKAGE MATCHING
------------------------
In Runtime resource overlay, iteration 1, only a single overlay package
was considered. Package matching was based on file paths:
/vendor/overlay/system/framework-res.apk corresponded to
/system/framework-res.apk. Introduce a more flexible matching scheme
where any package is an overlay package if its manifest includes
<overlay targetPackage="com.target.package"/>
For security reasons, an overlay package must fulfill certain criteria
to take effect: see below.
THE IDMAP TOOL AND IDMAP FILES
------------------------------
Idmap files are created by the 'idmap' binary; idmap files must be
present when loading packages. For the Android system, Zygote calls
'idmap' as part of the resource pre-loading. For application packages,
'idmap' is invoked via 'installd' during package installation (similar
to 'dexopt').
UPDATED FLOW
------------
The following is an outline of the start-up sequences for the Android
system and Android apps. Steps marked with '+' are introduced by this
commit.
Zygote initialization
Initial AssetManager object created
+ idmap --scan creates idmaps for overlays targeting 'android', \
stores list of overlays in /data/resource-cache/overlays.list
AssetManager caches framework-res.apk
+ AssetManager caches overlay packages listed in overlays.list
Android boot
New AssetManager's ResTable acquired
AssetManager re-uses cached framework-res.apk
+ AssetManager re-uses cached 'android' overlays (if any)
App boot
ActivityThread prepares AssetManager to load app.apk
+ ActivityThread prepares AssetManager to load app overlays (if any)
New AssetManager's ResTable acquired as per Android boot
SECURITY
--------
Overlay packages are required to be pre-loaded (in /vendor/overlay).
These packages are trusted by definition. A future iteration of runtime
resource overlay may add support for downloaded overlays, which would
likely require target and overlay signatures match for the overlay to
be trusted.
LOOKUP PRIORITY
---------------
During resource lookup, packages are sequentially queried to provide a
best match, given the constraints of the current configuration. If any
package provide a better match than what has been found so far, it
replaces the previous match. The target package is always queried last.
When loading a package with more than one overlay, the order in which
the overlays are added become significant if several packages overlay
the same resource.
Had downloaded overlays been supported, the install time could have been
used to determine the load order. Regardless, for pre-installed
overlays, the install time is randomly determined by the order in which
the Package Manager locates the packages during initial boot. To support
a well-defined order, pre-installed overlay packages are expected to
define an additional 'priority' attribute in their <overlay> tags:
<overlay targetPackage="com.target.package" priority="1234"/>
Pre-installed overlays are loaded in order of their priority attributes,
sorted in ascending order.
Assigning the same priority to several overlays targeting the same base
package leads to undefined behaviour. It is the responsibility of the
vendor to avoid this.
The following example shows the ResTable and PackageGroups after loading
an application and two overlays. The resource lookup framework will
query the packages in the order C, B, A.
+------+------+- -+------+------+
| 0x01 | | ... | | 0x7f |
+------+------+- -+------+------+
| |
"android" Target package A
|
Pre-installed overlay B (priority 1)
|
Pre-installed overlay C (priority 2)
Change-Id: If49c963149369b1957f7d2303b3dd27f669ed24e
Introduce a new tool 'idmap' to handle generation and verification of
idmap files. The tool is modelled on 'dexopt', and is intended to be
used similarly, notably by 'installd'.
See cmds/idmap/idmap.cpp for further documentation on 'idmap'.
Note: this commit is interdependent on a commit in project build/ to add
'idmap' to PRODUCT_PACKAGES.
Note: the changes to androidfw are only stubs. The actual implementation
will be provided in Runtime resource overlay, iteration 2.
Change-Id: I7131b74ece1e46c8a9c0a31d103e686aa07da2bb
We do not support higher order bound allocations. The
stride is not available to the script so they cannot
walk the allocation correctly.
Change-Id: I9447a5d43c3ae1b88fc9522628a17bd5a317ffc6
This changes BaseObj to support 64-bit IDs. There are a few caveats:
1. Since it is deprecated, RSG will not support 64-bit.
2. Currently, methods that pass arrays of IDs to the driver are not supported in 64-bit. This will be fixed in a later CL.
bug 11332320
Change-Id: If0dbecc8b285e260f767e441e05088b6a1b749a2
Following changes have been done:
[x] Long is used to store native pointers as pointers can be
64-bit.
[x] AssetManager openAsset native function returned -1 if
file name was empty and java function considered any
non-zero value as success. This has been fixed by native
function throwing Illegal Argument Exception as well.
[x] AssetManager incRefsLocked and decRefsLocked now accept
long as input to support 64-bit native references.
[x] AssetManager incRefsLocked method incorrecly used
'this.hashCode()' instead of the passed parameter id.
This has been fixed.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: I095b9f900d49e51f43ad6afc47cbc23116a6a64a
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
Also change the order of parameters in ResTable constructors
to avoid ambiguity.
(cherry picked from commit 00b314436f4fdfada4bbf1e79ec12e9fa38aeaf1)
Change-Id: I874c5d03c134dc3c331fba423b5280366296287c
