ContentProvider has a getCallingPackage() method, which verifies
the remote package name against the current Binder identity. When a
provider wants to clear that IPC identity, they need to clear both
the Binder state and the ContentProvider.getCallingPackage() state
together, so add methods to facilitate that.
Also fix subtle bug so we don't try translating relative paths.
Bug: 117627072
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifa3e1f745334abf625fdcc314b308a047c49ce73
Obtaining a thumbnail for a Uri requires opening it with the slightly
obscure openTypedAssetFileDescriptor(), passing in "image/*" with the
right Bundle of EXTRA_SIZE to hint the target area on screen, and
defensively scaling any returned results.
This is pretty tedious to get right, so offer a convenience method
that does all this for the developer. Internally uses ImageDecoder
to follow best-practices, and replaces older getDocumentThumbnail()
implementation by delegating to this one.
A future CL will teach ImageDecoder about how to read any embedded
EXIF thumbnails, including any required rotation.
Bug: 111268862
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I5c9c09ddf9b480f3b5c6ade0a078cccb68de2f2b
Any app loading untrusted strings should make the strings face. Hence make
the method publicly available.
Test: atest CtsTextTestCases:MakeSafeForPresentationTest GtsContentTestCases:PackageItemInfoTests
Change-Id: Ib0679fe892181535339dac77583c427e0d64dd05
Fixes: 113856697
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
This CL implements the biggest chunk of launch bounds logic in Android
branch and combine ActivityLaunchParamsModifier logic into
TaskLaunchParamsModifier. It left some things to be implemented:
1) It didn't yet consider persisting/recovering data;
2) It didn't implement letterboxing/pillarboxing, but according to
offline chat this should be enforced after launch bounds policies by
system;
3) Immersive mode is not yet implemented, but that's more tied to
recovering previous immersive mode and we won't launch apps to immersive
mode directly in any case;
4) No last seen non-fullscreen bounds are set if display is fullscreen,
which could be useful when display windowing mode changes from
fullscreen to freeform at later time.
There are also some topics that for sure need future discussions, so I
left them out of this CL as well:
1) App controlled apps (not only bounds specified in ActivityOptions);
2) Metadata indicating that the app prefers tablet-like bounds for
freeform windows (i.e. w/o limiting window size to Nexus 5x screen
size);
3) Fixed maximized size, which indicates that the maximized size
shouldn't be changed due to display resolution or orientation changes;
4) What to do if app requests to launch an activity without any flag
that indicates a new task should be used, but with a preferred display
ID/bounds set to a different value than its current window;
5) Should insets be considered in launch bounds (AM side) or on WM side,
IIUC freeform windows don't need to consider insets, and fullscreen
windows are covered by WM.
Our policy also has special treatment for Chrome snapped windows
(side-by-side mode in our tablet), which may not make much sense in
Android.
Bug: 113252871
Test: go/wm-smoke. Try launching some freeform windows on secondary
displays.
atest FrameworksServicesTests:TaskLaunchParamsModifierTests
atest ActivityManagerManifestLayoutTests
Change-Id: I974031725015b6283f33b9076788e7ce45134690
1. migrate set/get roamingType from ServiceState to
NetworkRegState.set/get roamingType
2. migrate set/get roamingStateFromRegstate from ServiceState
to NetworkRegState.regState
3. new System API for neworkRegistration.isRoaming().
Bug: 116127096
Test: ServiceStateTest, ServiceStateProviderTest
Change-Id: Ib89744089c98713819c8d313240d629ddb77d0bf
... as requested per API review.
- Sets require iteration via iterators
- Sets are more expensive to construct
- The advantage of sets (faster .contains) is not used
- The system ensures uniqueness of the entires in the list
Test: Built
Bug: 116798569
Change-Id: I2c3b5c6801b78e0bf942073bde1e90299aee39f6
If a normal app does not have launcher icon, launcher api
will return app details activity instead, so user will
be noticed that the app is still installed.
Bug: 111348460
Test: Installed an app without launcher activity, an app icon is being
shown in launcher allapps, and it forwards user to app details page.
Change-Id: I9c17f5edfdefe19727145e7176d7e113286c997d
The android.content.pm.PackageInstaller install + uninstall APIs are
fully functional. No need to try to keep the intent based APIs
feature compatible.
In the future we will be able to restrict app targeting old targetSDK
levels from using the intent-based API. Even further in the future we
can radically simplify the package installer app.
Fixes: 116616700
Test: Built
Change-Id: Ia225d70fbee3fa31a3c1de388dcb05ff1063dccd
The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.
This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths. Consider this example:
<path-permission android:pathPrefix="/private" ... />
uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);
content://com.example//private
The Uri above will pass the security check, since it's not
technically a prefix match. But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.
Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.
Bug: 112555574
Test: atest android.appsecurity.cts.AppSecurityTests
Test: atest FrameworksCoreTests:android.content.ContentProviderTest
Merged-In: Ibadbfa4fc904ec54780c8102958735b03293fb9a
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
This fix also refactors PackageParser.SigningDetails to move the
pastSigningCertificatesFlags to be a data member of Signature; this
allows the capabilities of a previous signing certificate to be
accessed directly from the Signature object as opposed to relying
on the 1-1 mapping of the past certs and flags in the SigningDetails.
Fixes: 73927696
Fixes: 73925989
Test: adb shell am instrument -w -e class com.android.server.pm.PackageSignaturesTest \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I635f2d2209350d066d1fa2ef07460071da0c023e
Add the relevant methods to read from ProtoInputStream to
various classes.
Also add some framework to handle version changes in
UsageStatsDatabase. There is some risk of users losing all their current
UsageStats data, if something goes horribly wrong. The debug flag and a
keep backup files flag are temporarily set in UsageStatsDatabase with
this change. They will both be unset in the future before the Q release.
Some rough number on the impact of this change:
Proto file size on disk reduces to ~47% of XML file size :)
Proto file read time reduces to ~55% of XML file read :)
Proto file write time increases ~17% over the XML file write :(
There will be a follow up CL to address the file write time regression
Bug: 111422946
Fixes: 111449927
Test: atest UsageStatsDatabaseTest
Change-Id: I084aea796ed2163c42947d52396a36cc7c5562a2
An application can declare that it must be installed with at least
one split using the manifest attribute "android:isSplitRequired".
Setting the attribute to 'true' [default is 'false'], the application
can't be installed with a base-only. It must be accompanied by at
least one split [either feature or config].
Change-Id: I42804af34a4209ba5d6726d681ca705ca2c21a39
Fixes: 111391719
Test: atest CtsAppSecurityHostTestCases:SplitTests
