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
Add the getLogRecMaxSize() method, so that
WifiStateMachine tests can verify the log
record buffer size, without having to fill
the buffer.
Bug: 35399013
Test: compile
Change-Id: Ib1bd8d670b7b39e9f740a4dd92ea67463b179ce2
This was done to eliminate some jank while the
service target are animating in due to some
inconsistent padding calculation. Tracking the root
cause there has been elusive, so we're temporarily
using the full height given we have bigger rewrites
we want of this component (e.g. migrating to
RecyclerView).
In the meanwhile this has the unwanted side effect of
letting the user maximize all drawers while pulling up.
bug: 34253328
Test: Manually verified behavior and lack of jank.
Change-Id: I3c5f52ed8180ac2da9e5c9f891879980e49728c0
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
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 638d810099)
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
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
1. Abstracted the fill/save view and window management
in dedicated classs
2. Avoided the need of a second window to detect outside
touches
3. Simplified the fill-ui window management
4. Moved the UI in its own package to ease mmigration to
sys UI.
5. Removed hard-coded colors from the layout
6. Make sure the save UI cannot grow as wide as the screen
as this would not look good on tablets
7. Update the save UI to look closer to mocks
Test: CTS tests pass
Bug: 35708258
Change-Id: Ia74a5aad6f16bba0047a9e8e61958c77af0d358d
