This is a generic version of the custom title that will
be used in settings dialogs soon. Adding it to settings
lib since others will need to make use of it as well.
Test: robotests pass
Bug: 130251804
Change-Id: I48f8e24a2b2a117e5a8054c5bc0b240ba68fe1ad
Will remove entirely after all references (esp. Play Services) are cleaned up.
Test: atest FrameworksCoreTests:DeviceConfigTest
Bug: 128902955
Change-Id: I1ab11fa2a2bbdb673841364c36b87a7356ba1e28
Based on feedback from developers, they need to query these columns
on the general "Files" table, so we need to promote them to the
general "MediaColumns" common interface to make them available.
Bug: 130254706
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I66afa14799ae42deea519d121177b2c8469889ab
Changed the intents to point to the right settings. The intent in
CellularTile will point to the carrier selected as default for data if
there is one.
Test: manual, using DSDS
Fixes: 122676059
Change-Id: I71a8eac1754eaadda156209315a3a469e7e4f6d0
To let developers focus on specific concrete storage devices in Q,
we need a volume name that can be used to point at the primary
external storage device. We had been using VOLUME_EXTERNAL for that,
but we've heard that certain apps are making deep assumptions that
media item IDs are globally unique across all volumes.
Thus these changes merge all volumes back into a single underlying
database, and VOLUME_EXTERNAL works with all of the currently
attached volumes. The new VOLUME_PRIMARY name can be used to focus
on the primary storage device when desired.
When developers try inserting items directly into VOLUME_EXTERNAL,
we gracefully assume they meant VOLUME_PRIMARY.
Bug: 128451765
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I682ff6e9aaab4f5315a46c9825313a438548c7e6
As pointed out by developers, we already have ARTIST, so we should
also have ARTIST_ID.
Bug: 130193406
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I46b4de38a08a1ebb6951d8329070438d142888ad
From mainline perspective, we should use android flag api
instead of using Settings. Thus, move the definitions into
NetworkStack.
Bug:120013793
Test: atest NetworkStackTests SettingsBackupTest
Change-Id: I8e1fb5b47fff3bf624131ba1f5732daabd991e6d
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
This intent action opens the advanced power usage details screen for
a provided application.
Test: adb shell am start -a \
"android.settings.VIEW_ADVANCED_POWER_USAGE_DETAIL" -d \
"package:com.google.android.deskclock" --ez \
"request_ignore_background_restriction" 1
Bug: 129901520
Change-Id: Ib5ee1376610acdec119c75944b3774d83a784288
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
