This change adds the file descriptor based ResourceProvider APIs to
the provider formats to test. It also refactors the testing API
so that all test APKs, ARSCs, and splits have the same resources
rather than different formats having different resources.
Bug: 142716192
Test: atest FrameworksResourceLoaderTests
Change-Id: I37da9f6c815ea67629b3115b0e125ebc79cd7c8c
This change refactors the tests for ResourcesLoaders to support the
new concept of loaders owning providers.
Bug: 147359613
Test: atest ResourceLoaderTests
Change-Id: Id61dc27bf5876afe10c25ed57333541131e910b7
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
