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
The Permission Controller app (a mainline module) needs to be able to
read the SPLIT_PERMISSIONS. Hence this array needs to be exposed at
least as system-api. We need to make sure that the PackageParser,
PackageManager and Permission Controller app agree on which permissions
are split, hence it is best to define them at a single location.
I think exposing the split permissions to developers is useless and
potentially confusing. The app should never request a permission that
was split. The app should just behave as if split permissions do not
exist. The Permission Controller / Package Manager deal with the
split permissions and add them when needed. Hence I don't think we
should expose this data to 3rd parties.
Bug: 110953302
Test: requested permissions
Change-Id: I6951c52979c89ee5c13a4a14da125e1a01f2e234
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
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
Fixes: 112570477
Test: BiometricPromptDemo works
Test: Able to get/use BiometricManager
Test: Tested with enrolled and non-enrolled biometrics
Change-Id: I26231894eccc87c42b5b3007aa0b7c6f09830452
This is in preparation for BiometricManager. Each Manager should have its
own Service.
Bug: 112570477
Test: BiometricPromptDemo works
Change-Id: Ibbbd499a0fd5a2050b329ee038776c6c9f49cdb2
