History log of /frameworks/base/core/java/android/content/pm/split/SplitAssetDependencyLoader.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
1665d0f028e3a225cb117d3e227bef5c5dace2d4 10-Mar-2017 Adam Lesinski <adamlesinski@google.com> Add support for configForSplit

Applications with the android:isolatedSplits="true" attribute in
their AndroidManifest.xml would have their Split APKs loaded in
isolation of each other, based on a set of dependencies.

Configuration Splits generated for a Feature split would not be properly
loaded before, so this change, along with a tools change, fixes this
issue and completes support for isolatedSplits.

Bug: 30999713
Test: CTS test coming (depends on some tool changes)
Change-Id: Ia4e7b0e69168a9d6637867558e306f7031720fb3
/frameworks/base/core/java/android/content/pm/split/SplitAssetDependencyLoader.java
408afbf06040ea29d1a9d60e9dc50d1923068de4 25-Jan-2017 Romain Guy <romainguy@google.com> Change configuration's color mode based on the display's color mode

Bug: 32984164
Test: CtsContentTestCases

Change-Id: Iedc7d1cc488b80718576082667b6e96956c4f847
/frameworks/base/core/java/android/content/pm/split/SplitAssetDependencyLoader.java
4e8628157ad0c8c52e74b720eb0328086272ffda 22-Nov-2016 Adam Lesinski <adamlesinski@google.com> Add support for Split APK dependcies

Apps can now declare in their base APK AndroidManifest.xml
that they want to have their split APKs loaded in isolated
Contexts. This means code and resources from the split
get loaded into their own ClassLoader and AssetManager.

<manifest xmlns:android="..."
...
android:isolatedSplits="true"
...

In order to make this more useful, splits can declare dependencies
on other splits, which will all get pulled in to the Context
and run as expected at runtime.

A split declares its dependency on another split by using the
tag <uses-split> in its AndroidManifest.xml:

<manifest xmlns:android="...">
...
<uses-split android:name="feature_split_1" />
...

A split can have a single parent on which it depends on. This is
due to the limitation of having a single ClassLoader parent.
All splits depend on the base APK implicitly.

PackageManager verifies that no cycles exist and that each dependency
is present before allowing an installation to succeed.

The runtime will then load splits based on the dependencies.

Given the following APKs:

base <-- split A <-- split C
^----- split B

If an Activity defined in split C is launched, then the base,
split A, and split C will be loaded into the ClassLoader defined
for the Activity's Context. The AssetManager will similarly be loaded
with the resources of the splits.

A split can be manually loaded by creating a Context for that split, defined
by its name:

Context.createContextForSplit("my_feature_split_1");

All installed Activities, Services, Receivers, and Providers are accessible
to other apps via Intent resolution. When they are instantiated, they are
given the appropriate Context that satisfies any dependencies the split they
were defined in stipulated.

Test: WIP (CTS tests to come)
Change-Id: I8989712b241b7bc84381f2919d88455fcad62161
/frameworks/base/core/java/android/content/pm/split/SplitAssetDependencyLoader.java