Bug: 77808145
Test: Tried to install corrupt APK prior to the change, install failed
Test: Tried to install corrupt APK after the change, install succeeded
Test: atest CtsAppSecurityHostTestCases:CorruptApkTests
Change-Id: I19a69e52a17c1080beaf2cc575c32f564b1033a3
This adds support for shared resource libraries in the new
ResTable/AssetManager implementation.
The dynamic package map encoded in resources.arsc is parsed
and stored with LoadedArsc, and combined to form a resolved table
in AssetManager2.
Benchmarks show that this implementation is an order of magnitude
faster on angler-userdebug (make libandroidfw_benchmarks).
Test: libandroidfw_tests
Change-Id: I57c80248728b63b162bf8269ac9495b53c3e7fa0
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
