If for some reason Asset::getBuffer returns a null pointer, error out
instead of dereferencing the null pointer.
Bug: 125943266
Bug: 154461471
Test: boots
Change-Id: I957be4f9b8c49c2a6829e8b82fae0ae8d8d7639e
When the target package update, check if the idmap file must change.
If so, propagate the idmap changes to the targets overlay paths, and
invalidate cached overlay ApkAssets in ResourcesManager.
Bug: 147794117
Bug: 150877400
Test: OverlayRemountedTest
Test: libandroidfw_tests
Change-Id: I6115c30bae3672b188a5ff270720a0eea15b43b5
Currently there is a limitation where ResourcesLoaders cannot be used
on Resources object not created through ResourcesManager. This change
creates an update handler for Resources objects that are not registered
with ResourcesManager.
The handler changes the loaders on the asset manager owned by the
Resources instance.
Bug: 151666644
Test: atest ResourceLoaderValuesTest
Change-Id: I5a89f686386bdb088dc964014e7becc0c2b4770f
Querying in the native layer for assets provided through
AssetsProviders does not currently work. This change refactors the
AssetProvider API to return a file descriptor that is read in the
native layer and can bubble up to the java layer.
This change also removes the InputStream API to favor of developers
using memfd_create.
Bug: 142716192
Test: atest ResourceLoaderValuesTest
Change-Id: I1a7eca0994c3b7cc32008d9a72bf91086ff0e816
This API allows a directory to be loaded as if it was a zipped APK.
This is a substitute for the DirectoryAssetProvider API that
currently does not work in the native layer.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: Ia13e15653e75b421423dd56f9fe89e183ab4cb9a
To add the partner requested ResourcesProvider#loadFromDir APIs, this
change adds format type integer that allows us to reduce the number of
ApkAssets loading overrides.
This change also adds hidden offset and length based ResourcesProvider
APIs that could not make R.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: I926fde257cae701901dcd4ca408024feae8c90a6
Merged-In: I926fde257cae701901dcd4ca408024feae8c90a6
Now that RROs are loaded as shared libraries,
LoadedApk#makeApplication is attempting to find the onResourcesLoaded
method of the overlays. This is a performance hit and causes more
memory than necessary to be allocated during application start up.
Bug: 143314947
Test: com.android.performance.tests.HermeticMemoryTest
Change-Id: I3b8cd22dae83e0164d6678c80279f9fffceb34e6
This change allows RROs to reference their own internal resources as
expected.
Overlays are loaded as shared libraries so they can have their own
resource id space that does not conflict with the resource id space of
the target or other overlays.
References to overlay resources that override target resources now
appear as references to the target resources.
Overlay values that are inlined into the xml file specified using
android:overlayResources are now able to be used at runtime.
See go/rro-references for more information.
Bug: 135943783
Test: idmap2_tests
Test: libandroidfw_tests
Change-Id: Ie349c56d7fd3f7d94b7d595ed6d01dc6b59b6178
ResourceLoaders allow inserting another .apk/.arsc into AssetManager's
resource resolution search. The effect is similar to overlays,
where a entry of >= config later in the path list will return that
ApkAsset's resource value instead.
Because loading from an .arsc is supported, which doesn't contain
any actual files, ResourceLoader exposes loadDrawable and
loadXmlResourceParser to allow an application load those files from
anywhere or create them in code.
The data being loaded is either pushed into an .apk or .arsc that
mocks itself as the package being "overlaid" and is passed in
through ResourcesProvider, an interface with static methods that
supports loading from a readable path on disk or a FileDescriptor.
The APIs are accessed through a Context's getResources(), which
has been changed to be unique per "Context-scope", which is usually
the lifetime of the Java object. The exception is that Activities
who get their Resources object persisted across recreations
maintain that logic for persisting ResourceLoaders.
Bug: 135270223
Test: atest FrameworksResourceLoaderTests
Change-Id: I6929f0828629ad39a21fa155e7fec73bd75eec7d
Do not print warnings when an APK loaded into aapt2's symbol table has a
compressed resources.arsc. This log is helpful at runtime since
compressed arscs take longer uncompress.
Bug: 130617130
Test: manual
Change-Id: I52847663ad8f46ba00d3dd1ebb2292ab54737680
This logic was lost in the AssetManager1 -> 2 migration.
The old AM1 checked the last modification time of the file
and compared it to a previously stored value. This re-adds the
logic to ApkAssets and fixes the checks in the JNI/Java layer.
Unfortunately I couldn't find a failing/practical case where
this check mattered. It only came up when diagnosing an issue
which ended up being unrelated.
Test: manually ran with other overlay changes
Change-Id: I758e4af1d32a9c03b2204a8a3a26e82b7e83feda
Bug: none
Test: m checkbuild
Exempt-From-Owner-Approval: owner is OOO for another week,
it's a fairly minor change to this repository
Change-Id: If4cf57619034ab98b06115ca60beb2fb26c4cd19
List was skipping directories. Include them, and add tests to ensure
the order and precedence is correct.
Bug: 72511641
Test: make libandroidfw_tests
Test: atest CtsContentTestCases:AssetManagerTest
Change-Id: Iadf45883283d3e4aae93bd7c3343745912e34fa0
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
- 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
