Content changed notifications are really only valid for content://
Uris, which are really only valid when we have a valid ContentProvider
backing them. This has been implicit for a long time, but we actually
need to start enforcing it based on target API.
We also now tell developers about why their notification requests
are being denied, instead of silently logging.
Test: builds, boots, common operations work
Bug: 34049049
Change-Id: Ie8ab8d8674cff13e3e9269ffddc4ad998cb848c4
We're checking all the other Intent objects, but we forgot this one.
Test: builds, boots
Bug: 34072700
Change-Id: I4f328950f3122258e0bdea7e87f78d7d0afdedbb
ASEC containers have been deprecated since MNC, which is when we
introduced the "adoptable storage" feature. Adoptable storage is a
much better user experience, since we move both the APK and private
app data together as a single unit, making it much easier to explain
to users.
Test: builds, boots
Bug: 32913676
Change-Id: I97385d081a50a79fc005d4e23e09999f9ae6cfc1
As per CDD: The "android.*" namespace for intent constants is reserved for public
Android API in AOSP. (Whether public to the full SDK, @SystemApi or
defined in AOSP support libraries.)
ACTION_CARRIER_SETUP intent is generally useful for carrier privileged
apps which is unbundled carrier apps, thus move to public APIs
Bug: 33679956
Test: Manual
Change-Id: Ie2b5d072406513f04676210d08c43d91623c3cd2
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
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'
A split may be declared in an application's base manifest, but,
defined in a feature split. When resolving such a component,
invoke the installer to download and install the necessary split(s)
At the moment, this only works for instant apps. However, the
implementation is generic and could be applied to any application.
Bug: 25119046
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: I6598abb34becfd049fc03199813226736e5057b1
These intents are handled by some system apps and use the
android.* namespace. So mark them as SystemApi for CTS verification
purposes.
Fixes some of the CTS signature tests.
Change-Id: I18664b3e92bb24a5cf96d89cf47d6abb88b13220
Fixes: 35253923
Test: cts-tradefed run cts-dev -m CtsSignatureTestCases
A ColorStateList should be stateful when it has at least one
non-wildcard state.
Test: Manually
Bug: 35487255
Change-Id: Id94b6a8d172e22a522f73fcb378e342656f95e39
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.
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'
Change-Id: Idc96dae6fc075d5373aa055bbf50e919136d7353
Stop interning string metadata values as well as class names as it's
unlikely there will be much duplication among these.
Also make sure we intern the same set of strings when parsing packages
from their cache entries as we do when parsing them from the package
itself.
This change also improves error reporting for the unit-test and fixes
a failure that was introduced by a previous change (the addition of
static libraries).
Test: PackageParserTest
Bug: 34726698
Change-Id: Ia0d0342b91b3294bd5569756255918d1dc886e05
When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.
Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
The same application can run as either an instant app or an installed
app. Store this setting per-user instead of based upon the install
location.
Bug: 25119046
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.EphemeralTest
Change-Id: Iff565bb1ac10d631499f0bd0f69b401cb073c10e
