Instant apps are unique in that any application can start them
with a VIEW/BROWSABLE while only very few apps can see an
instant app using queryIntentActivites, etc... In order to
support this dichotomy, we need an internal hook to resolution
for activity start.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Bug: 25119046
Change-Id: If6974c09c733ff0417ef72cabb9d9e9aca86c37c
There were a few places where access to the mStringBlocks were
not protected.
The crashes seen where similar to:
java.lang.NullPointerException: Attempt to invoke virtual method \
'java.lang.CharSequence android.content.res.StringBlock.get(int)' on a null object reference
at android.content.res.AssetManager.getResourceValue(AssetManager.java:222)
at android.content.res.ResourcesImpl.getValue(ResourcesImpl.java:188)
at android.content.res.Resources.loadXmlResourceParser(Resources.java:2110)
at android.content.res.Resources.getLayout(Resources.java:1111)
java.lang.NullPointerException: Attempt to invoke virtual method \
'java.lang.CharSequence android.content.res.StringBlock.get(int)' on a null object reference
at android.content.res.AssetManager.getPooledStringForCookie(AssetManager.java:312)
at android.content.res.TypedArray.loadStringValueAt(TypedArray.java:1212)
at android.content.res.TypedArray.getValueAt(TypedArray.java:1198)
at android.content.res.TypedArray.getColor(TypedArray.java:446)
What happened was that thread 1 was creating a new mStringBlocks in
makeStringBlocks while thread 2 was accessing mStringBlocks. The
makeStringBlocks starts off by overwriting mStringBlocks with a new
empty array and when thread 2 accessed its content NPE happened.
Bug: 30802713
Test: None (just added synchronization to help prevent races)
Change-Id: I810da26b161a6528b0dd241048dde5b239089244
There is a disconnect between the way webview created
classloader and the way makePaths decides if paths are
intended for bundled app.
This change moves decision making out of makePaths method
which allows WebViewZygote to pass correct argument and
have makePath omit java.library.path for libPaths
Bug: http://b/35426785
Test: manual
Change-Id: Iab5a18c0091d0193dafa750498eb00f378411ba0
(cherry picked from commit 638d81009918eae44eec3261e235b78eae44331d)
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Soc vendors also want to add their own configs like odms do.
Additionally they should be allowed to add their own app permission
configs because they can install their own apps in /vendor/app.
So Soc vendors should be able to add system configs around libs,
features, permissions and apps.
Additionally this CL modified codes to allow "privapp-permissions"
only on system partition because we won't allow apps on the partner
partitions to count as privileged.
Test: building succeeded and tested on sailfish.
Bug: 35369237
Change-Id: I7d84d6e351d9e7023931757082d9f661c5a9a80a
We added the notion of a default and whether the system set
the setting. This is used for resetting the internal state and we need
to make sure this value is updated for the existing settings, otherwise
we would delete system set settings while they should stay unmodified.
Test: manual
bug:35317326
Change-Id: Iaffde2e7acab53653fd38e669a644e654cc7cd7d
