This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
If the global setting has been explicitly set to 1 or 0 (e.g. via
developer settings) then that takes precedence - so we don't interfere
with what the user has set. Otherwise the default value from
DeviceConfig is used.
Also migrate the associated (not yet used) package whitelist to
DeviceConfig, so we can set both at the same time. The whitelist is
ignored if the user has explicitly enabled or disabled background
starts.
Bug: 129533810
Test: atest WmTests:ActivityStarterTests
Change-Id: I2856edb5cb8c99a8cfef4712732d9dc9c5d7cdb7
If Settings handles the new intent action, a "More" item will appear
in the new default apps list, and clicking it will launch that intent.
Bug: 124452117
Bug: 127745414
Test: build
Change-Id: I4bb08489b77de12fd20d85260edba9e58252712a
The DATA column points at raw filesystem locations, which aren't
always valid when an app is placed into a sandbox, so apps need to
move away from using them.
We had hoped to block this access based on an app targeting Q, but
we've received feedback that it's too painful for apps to transition,
so we'll continue returning paths that can be translated.
Also reduce CPU usage by skipping permission checks when not
processing an IPC, such as when called by ModernMediaScanner.
Bug: 128452447, 125725916
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Ibd41d8ddedfaf9807333560b2d8e64e42ea7a1ba
A major goal of the Q release is to promote user transparency around
permission usage, and to also give user controls over those
permissions. To further this goal, all apps requesting the
internal WRITE_MEDIA_STORAGE permission must also request (and be
granted) the "Storage" runtime permission in order to gain the
associated access.
If the user revokes the "Storage" runtime permission, then the app
must lose all access granted to it via WRITE_MEDIA_STORAGE.
Bug: 129144016
Test: atest android.permission.cts.ProviderPermissionTest#testWriteMediaStorage
Change-Id: I7e747de0107cf9364a0ff2401686906340d31995
Add a new setting that allows a developer to specify where
to load ANGLE libraries from, rather than the default location.
This is only allowed for apps that are dumpable, i.e. can have
libraries injected. That includes debuggable, profileable,
and root.
To use the new setting:
adb shell settings put global angle_debug_package <package>
This allows a developer to build an APK directly from Chromium
and use it with a production build of Android. It will override
pre-installed system packages and updates.
Note: Use of ANGLE Developer Options UI will cease to function
until the debug package is uninstalled.
Bug: 80239516
Test: Apply setting, see new ANGLE used
Test: cts-tradefed run singleCommand cts -m CtsAngleIntegrationHostTestCases
Change-Id: Ib3b1fb52c0eb669e7ea931959a73aba2bd15bedf
With this, users with userdebug/eng builds will be able to initiate a
system heap dump from developer options.
Bug: 77490269
Test: manual
Change-Id: I0f4efec621e0d63b87c2d655a5f0434572cb92ac
Per API council feedback, we are making changes to include only the
namespace in the system API defined in DeviceConfig.java. Strings which
define property names should be defined in code local to the feature
instead.
Bug: 126411407
Test: atest FrameworksCoreTests:DeviceConfigTest
Change-Id: I2a7f22296f73ea6a27e7b430a619fbf150acb58c
* changes:
Overlaying the nav bar frame dimens
Check the overlay state for updating sysui
Removing old resources
Remove the swipe up setting from system
We've converged on explicit scanVolume() and scanFile() methods
which tests should be calling. These are more robust than the
previous broadcast-based events, which could hang for a long time.
Bug: 127323913
Test: atest --test-mapping packages/apps/MediaProvider
Change-Id: I4f7918c70a67bcafab69ae2a71ee8e4bdaff01eb
We're now enforcing the public API schema, so clients like MTP need
to query specific collections when asking for properties that are
specific to those media types.
Also refactor MediaScanner calls to go through MediaProvider, so
they can be handled by ModernMediaScanner. We no longer directly
try inserting items, and instead rely completely on the scanner.
Bug: 127625964, 122263824
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ic86982766606a619afafe725f9c60013a5671840
There was some confusion caused by the names so this CL
changes them to make the differentiation more clear hopefully.
Test: robotests pass, build runs, functionality of clients intact
Bug: 126944845
Change-Id: I626dd8e38c59fb5c061e4d0fdcf8c81701c459a3
Internal feedback asked for more documentation, and feedback from
external teams (at least Photos and Camera) was the ability to store
files at arbitrary directory depths.
We now offer a single PATH column, which gives callers more precise
control over file placement. The old DIRECTORY columns remain
intact for now, and are temporarily accepted to support apps
developing against the preview SDKs.
Bug: 127657692, 123967243
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Icd90d7c89d066d4ab68aa2f543ccc6fbc3b4f596
Per API council feedback, we are making changes to include only the
namespace in the system API defined in DeviceConfig.java. Strings which
define property names should be defined in code local to the feature
instead.
Bug: 126411407
Test: atest FrameworksCoreTests:DeviceConfigTest
Change-Id: I8d5b1f2dab84a1fe1f645cad508bebbc86f2c9c5
