Add an iterator to LoadedPackage which allows the caller to iterate over
the resource IDs in the package. This will be used by idmap when
constructing the idmap file.
Bug: 78815803
Test: make libandroidfw_tests
Change-Id: Ia47daa21390d67ea2ef3665e88eb407837c4764f
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
AssetManager2 assumes that RES_TABLE_TYPE_SPEC_TYPEs must immediately
precede their associated RES_TABLE_TYPE_TYPEs. This is not correct.
RES_TABLE_TYPE_SPEC_TYPEs must precede their associated
RES_TABLE_TYPE_TYPEs, but they do not need to immediately precede them.
For example, this is what we currently expect:
RES_TABLE_TYPE_SPEC_TYPE id=1
RES_TABLE_TYPE_TYPE id=1
RES_TABLE_TYPE_SPEC_TYPE id=2
RES_TABLE_TYPE_TYPE id=2
but this is also valid:
RES_TABLE_TYPE_SPEC_TYPE id=1
RES_TABLE_TYPE_SPEC_TYPE id=2
RES_TABLE_TYPE_TYPE id=1
RES_TABLE_TYPE_TYPE id=2
Bug: 73052092
Test: make libandroidfw_tests
Change-Id: I1f3c43760f8108eee24c2c6ed7bc16f70e951c2b
AssetManager2 relied on creating a list of configurations
present in the resource table so as to avoid copying and
converting ResTable_config's from the APK on every
resource retrieval.
ResTable, however, had a better optimization that pruned
the configurations that didn't match the currently set
configuration. This vastly reduced the number of ResTable_configs
to test.
In this CL, AssetManager2 follows suite with this optimization
and only maintains the filtered ResTable_configs, falling back
to the slow path when the configuration is overridden.
Test: mma frameworks/base/libs/androidfw
Test: adb sync system data
Test: adb shell /data/benchmarktest64/libandroidfw_benchmarks/libandroidfw_benchmarks
Change-Id: Ib57b75fbb32e1d310eec146e5a12dfc6de4385f9
AssetManager2 relied on creating a list of configurations
present in the resource table so as to avoid copying and
converting ResTable_config's from the APK on every
resource retrieval.
ResTable, however, had a better optimization that pruned
the configurations that didn't match the currently set
configuration. This vastly reduced the number of ResTable_configs
to test.
In this CL, AssetManager2 follows suite with this optimization
and only maintains the filtered ResTable_configs, falling back
to the slow path when the configuration is overridden.
Test: mma frameworks/base/libs/androidfw
Test: adb sync system data
Test: adb shell /data/benchmarktest64/libandroidfw_benchmarks/libandroidfw_benchmarks
Change-Id: I5d46f8b005a37b72750d00bd75f090e7b5a36f60
AssetManager2 relied on creating a list of configurations
present in the resource table so as to avoid copying and
converting ResTable_config's from the APK on every
resource retrieval.
ResTable, however, had a better optimization that pruned
the configurations that didn't match the currently set
configuration. This vastly reduced the number of ResTable_configs
to test.
In this CL, AssetManager2 follows suite with this optimization
and only maintains the filtered ResTable_configs, falling back
to the slow path when the configuration is overridden.
Test: mma frameworks/base/libs/androidfw
Test: adb sync system data
Test: adb shell /data/benchmarktest64/libandroidfw_benchmarks/libandroidfw_benchmarks
Change-Id: I42d53f703623cf7c3f7cbcf194f5026ff540faf4
This added more up-front cost to loading an APK and didn't provide
a significant benefit to resource retrieval.
Test: make libandroidfw_tests
Change-Id: Idbf993abc433fa8c8950d106c66469b310b66f7f
ApkAssets who have failed verification should still run for
compatibility. Not all resources are accessed, and therefore
errors in the APK are not necessarily fatal. However, this means
we must do bounds checks when retrieving resources, which is
slower.
Test: make libandroidfw_tests && $ANDROID_BUILD_TOP/out/host/<host>/nativetest64/libandroidfw_tests/libandroidfw_tests
Test: make libandroidfw_benchmarks && adb sync system && adb sync data && /data/benchmarktest64/libandroidfw_benchmarks/libandroidfw_benchmarks
Change-Id: I4cc926c064bca0491785d82cdac0419d74d7d9b0
ID types should not be encoded as a map. AAPT and AAPT2 emit
IDs as boolean types.
Some apps exist that for some reason have their ID types encoded
as empty maps. This is the case only for the auto generated IDs
from enum values in <attr> tags.
Allow IDs as maps and ignore their content when processing an APK
for optimizing.
Also fixes an issue with expected size of the ResTable_package struct.
Bug: 35861796
Test: tested against the APK in b/35861796
Change-Id: I29a19cd9777bb10bed6766cd42e35e50e098797b
ResTable_type's size changes due to it containing
ResTable_config. Make sure we check for the minimum size
required to read it.
Bug: 35861796
Test: Manual (don't have an integration test harness setup yet)
Change-Id: Ifb0cd1d732625f59835c8ed0449adb78129636de
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
