AssetManager2 maintains a set of configurations [as specified in the
resource blob] compatible with the currently set configuration [as
specified via SetConfiguration]. This helps optimize future resource
lookups by limiting the set of configurations to iterate over.
However, when creating idmaps, all configurations must be considered,
including those not compatible with the currently set configuration. Add
an optional flag to SetApkAssets to disable the optimization described
above.
Test: manual (will be tested by upcoming idmap2 implementation)
Change-Id: I7526a323ddf90e2f2f49c36e8c110a2cec25357e
Style resources with circular parental dependencies caused infinite
recursion when calling AssetManager2::GetBag. This fix allows recursion
to cease when a circular dependency is found.
Bug: 77928512
Change-Id: Ib900c36ab1aef5da5b03234a9484c4dad3b63c02
Test: Manual test of b/77928512 and duplicates of 74493983
An app was crashing because in an attempt to retrieve layout
attribute/style data, the app infinitely recursed because its parent was
set to itself. This change checks if the resource bag parent and child
have the same ids, and if so, attempts to find the resource in this bag
alone rather than attempting to also look in parent bags.
Bug: 74493983
Test: Manual testing of Fitbit app
Change-Id: Iea37533a0676bd51b72c9bb235adec9bd04f2ccc
(cherry picked from commit ac04095ba9)
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
When an app is loaded as a shared library (eg. monochrome),
make sure to set the bit that it loaded as such, so that
conversions from package ID 7f -> shared library ID are done.
Bug: 72511998
Test: make libandroidfw_tests
Test: out/host/<host_os>/nativetest64/libandroidfw_tests/libandroidfw_tests
Change-Id: Icd11b7a5adff351165ca16d5853fb5a0002c34b1
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
If the value passed to AssetManager::ResolveReference is not a
reference, the caller may be expecting for the last reference to
not be cleared, as a more appropriate value should most likely be
retained.
This was causing an issue when a caller was manually resolving
references and expecting the last resource ID resolved to be propagated
across calls to ResolveReference.
Test: make libandroidfw_tests
Change-Id: I5b7f586e2cd541059023eaa9ba23e324a21a9a1e
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
This change brings Theme ApplyStyle down to 2x the original performance
and Theme attribute retrieval to less than the original performance.
Yay!
Benchmarks ran on marlin-eng
----------------------------------------------------------------------
Benchmark Time CPU Iterations
----------------------------------------------------------------------
BM_ThemeApplyStyleFramework 8540 ns 8500 ns 82105
BM_ThemeApplyStyleFrameworkOld 5280 ns 5258 ns 148849
BM_ThemeGetAttribute 8 ns 8 ns 88388549
BM_ThemeGetAttributeOld 11 ns 11 ns 63394463
ApplyStyle still takes some time, and the weird thing is that if I
switch the data structure of ThemeType to use an
std::vector<ThemeEntry>, the performance becomes better than the
original implementation! The issue is that std::vector<T> takes up 24
bytes, which would make Themes take up 8 more bytes per ThemeType, which
is unacceptable. Still trying to isolate where the performance gain is
coming from.
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 && adb shell /data/benchmarktest64/libandroidfw_benchmarks/libandroidfw_benchmarks
Change-Id: I0e7a756afd44b6aac1521e69c2b907258c262d3e
Theme copying should behave the way it did with the old AssetManager
(copy only the framework attributes when copying from a Theme object
from a different AssetManager).
Cleanup the dependencies on libziparchive in ApkAssets.
Test: make libandroidfw_tests
Test: out/host/<platform>/nativetests64/libandroidfw_tests/libandroidfw_tests --testdata=frameworks/base/libs/androidfw/tests/data
Change-Id: I973f7e6eb14ce311306e2ec66a623a4790c8d233
Caught by the static analyzer:
frameworks/base/libs/androidfw/AssetManager2.cpp:580:9: warning:
Potential leak of memory pointed to by 'new_bag'
[clang-analyzer-unix.Malloc]
Bug: 27101951
Test: mma. Memory leak warning is gone.
Change-Id: I532585d4dd376cec1abf4358f26d23f5ae3231cf
- Use FileMaps to open Assets (prevents closing of ApkAssets underlying
zip)
- Implement OpenDir and List methods
- Fix issue where DynamicRefTable wasn't properly constructed
Test: make libandroidfw_tests
Change-Id: Ib21a84e1114d028120744aa3bc1c6eb9d9399fa8
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
