This creates a "split permission" from:
- BLUETOOTH to BLUETOOTH_SCAN and BLUETOOTH_CONNECT, and
- BLUETOOTH_ADMIN to BLUETOOTH_SCAN and BLUETOOTH_CONNECT
...for apps targetting SDK<31.
What this means is that any apps that use either the BLUETOOTH or the
BLUETOOTH_ADMIN permission, and target SDK<31, will automatically be
be granted the BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions.
Bug: 181813006
Test: manual
Change-Id: I92a974203fd51e87747e740273a21ba399a81cd0
In Android R, we introduced a platform.xml based
mapping. Unfortunately, it only worked for signature|preinstalled
apps.
To support apps granted the appop (via special app access
permissions), we now check the permission and appop grant state
explicitly and grant the app the external_storage gid appropriately
Test: Manual
Bug: 165515144
Change-Id: Ib91e1b3a7e54ac2c83fb1d94446bed06fd44bcf6
Added interact accross user permission to media uid so that it can query
packages for UID in cases where media service is running for user 0 and
applications runs for different user id (i.e. 10) as is the case in car.
Bug: 181574201
Test: build seahawk (car target)
Test: run media recorder application with RECORD_AUDIO permission
Test: run media recorder application without RECORD_AUDIO permission
Change-Id: I5052c92831978a7e6c8277d3c5a4e6cb5ed8a78b
- gcar_emu_x86_64 starts to crash after commit 1dafc38 is merged.
Bug: 179455284
Test: Build gcar_emu_x86_64 and check if it boots successfully.
Change-Id: I59dad57c846e3a83d71abb58fdd5e57019d99e75
Apps can't request this permission anyways so some apps started
misbehaving when forcing users to grant all permissions without caring
what they are.
Test: Boot
Fixes: 172844303
Bug: 158311343
Change-Id: Ia83ad5433ff3cdae57d901b3a9d781725124c6b9
This dependency is fictitious: hidl manager actually contains a static
copy of hidl base for convenience. Separate libraries were created
later (e.g. android.hidl.manager-java-shallow) in order for users of
these libraries to specify the exact deps they need.
Fixes: 170710203
Test: boot and check logs
:) adb logcat | grep android.hidl.manager-V1.0-java.jar
10-21 00:42:53.173 328 328 D ApplicationLoaders: Created zygote-cached class loader: /system/framework/android.hidl.manager-V1.0-java.jar
10-21 00:43:17.322 329 329 D ApplicationLoaders: Created zygote-cached class loader: /system/framework/android.hidl.manager-V1.0-java.jar
10-21 00:43:31.920 2250 2250 D ApplicationLoaders: Returning zygote-cached class loader: /system/framework/android.hidl.manager-V1.0-java.jar
10-21 00:43:38.884 2847 2847 D ApplicationLoaders: Returning zygote-cached class loader: /system/framework/android.hidl.manager-V1.0-java.jar
10-21 00:43:41.010 2923 2923 D ApplicationLoaders: Returning zygote-cached class loader: /system/framework/android.hidl.manager-V1.0-java.jar
10-21 00:43:42.146 3044 3044 D ApplicationLoaders: Returning zygote-cached class loader: /system/framework/android.hidl.manager-V1.0-java.jar
Change-Id: I024a1b16570bdceb7bef5b2e718c65155c675b4a
There should be no such dependency.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 169137403
Bug: 132357300
Change-Id: Iaa7414be66581c01c6acbf367dc165cd8af78615
Revert "Add dedicated host side tests for permissions and appops"
Revert submission 12439864-PermAppOpsCrossUserCheck-Fixed
Reason for revert: Bug 169044600
Reverted Changes:
I95d015e01:Invalidate package/permission cache if cross-profi...
I2a8a84f57:Check cross-user interactions for permissions and ...
Ie8f0db231:Give all non-package services the power to interac...
I11af434a8:Test package/permission cache invalidation when IN...
Ib6d609a4d:Add dedicated host side tests for permissions and ...
Change-Id: I47d371832c119fe4ce4890e10c1ac87aba92acbc
The two SysConfig xml tags
system-user-whitelisted-app
system-user-blacklisted-app
are deprecated and were never used.
Bug: 139547572
Bug: 137101239
Test: compiles
Change-Id: I0a5a8cb9b178a3742ddc1fe70b9ee1e2737abdba
As part of mainline effort, cellbroadcastreceiver package name has been
renamed. Now its a completely new apk with different uid. That said all
user data e.g, cellbroadcast history and user preference from legacy app
com.android.cellbroadcastreceiver are gone. This change is to support
preserve user data when devices upgrate to R and take cellbraodcast.
mainline module.
1. create legacy cellbroadcast app with old pakcage name
com.android.cellbroadcastreceiver. this app only surface the old data
and should not contains any activities/services to handle emergecy apert
2. legacy cellbroadcast app will be included to the system image by
default. OEMs are free to remove it if they don't care data loss or
after R data migration is done. leagcy app will not be part of
com.android.cellbroadcast apex.
3. the real mainline module rename to com.android.cellbroadcast.module
Bug: 155844209
Change-Id: I5e61c7e777526e038cd8d9971a2c5b87c00eaacb
Merged-in: I5e61c7e777526e038cd8d9971a2c5b87c00eaacb
As part of mainline effort, cellbroadcastreceiver package name has been
renamed. Now its a completely new apk with different uid. That said all
user data e.g, cellbroadcast history and user preference from legacy app
com.android.cellbroadcastreceiver are gone. This change is to support
preserve user data when devices upgrate to R and take cellbraodcast.
mainline module.
1. create legacy cellbroadcast app with old pakcage name
com.android.cellbroadcastreceiver. this app only surface the old data
and should not contains any activities/services to handle emergecy apert
2. legacy cellbroadcast app will be included to the system image by
default. OEMs are free to remove it if they don't care data loss or
after R data migration is done. leagcy app will not be part of
com.android.cellbroadcast apex.
3. the real mainline module rename to com.android.cellbroadcast.module
Bug: 155844209
Change-Id: I5e61c7e777526e038cd8d9971a2c5b87c00eaacb
Convert ACTION_SERVICE_STATE_CHANGED and
ACTION_ANY_DATA_CONNECTION_CHANGED to be non-sticky broadcasts that
require the READ_PHONE_STATE permission to receive. As part of this,
declare READ_PHONE_STATE to be split from READ_PRIVILEGED_PHONE_STATE,
so that system apps holding READ_PRIVILEGED_PHONE_STATE can also receive
these broadcasts.
Also modify affected users to fetch the current value of the broadcast
upon registration instead of relying on the sticky nature of the
broadcast.
Bug: 150155839
Test: manual
Test: atest KeyguardUpdateMonitorTest
Change-Id: I020b1554c4fc59c138d015e787526b4a66c74853
Allow media service to register UidObserver to get uid
state changes. Media transcoding uses uid states for
transcoding job scheduling purposes.
bug: 154734285
bug: 145233472
Change-Id: I20c7b33798ff5ede6620cccf65143da5ad77cba5
Previously, this permission would give the holder the media_rw gid
thereby granting access to the following file paths on disk:
1. /data/media
2. /mnt/media_rw
3. /mnt/expand/<uuid>/data/media
With the introduction of a stacked FUSE filesystem on external
storage, modifying any files directly on the lower filesystem (the
paths listed above) could lead to VFS cache inconsistencies and file
corruption.
To mitigate this risk, this cl blocks unneeded access to the lower
filesystem. Apps relying on this permission should instead use
android.permission.MANAGE_EXTERNAL_STORAGE.
Test: cat /proc/<pid>/status of mediaprovider doesn't have media_rw
Bug: 144914977
Change-Id: I8335d18067231657ac9793f7b1dcf6adb617ecfc
As part of migrating the pullers to the new API, we modify
permission checks within BatteryStatsService. Previously, a Binder
thread within StatsCompanionService (with statsd's calling identity)
called BatteryStatsService functions, which was why statsd was assigned
the BATTERY_STATS permission. Now, that call is being made from the
system process Background thread. Because enforceCallingPermission
outside of Binder threads, we switched to enforceCallingOrSelfPermission.
Test: m -j
Test: adb shell cmd stats pull-source 10039
Test: adb shell cmd stats pull-source 10040
Test: adb shell cmd stats pull-source 10041
Test: atest CtsStatsdHostTestCases:UidAtomTests#testDeviceCalculatedPowerUse
Test: atest
CtsStatsdHostTestCases:UidAtomTests#testDeviceCalculatedPowerBlameUid
Test: atest CtsStatsdHostTestCases:BatteryStatsValidationTests#testPowerUse
Bug: 145565211
Change-Id: Ie009e6eead3e48ecee6b40d9a38c9d571d4d4117
Previously, the power to preempt sound trigger recognition sessions
for the sake of being able to capture audio on platforms that don't
support doing both concurrently, was implicitly granted based on
process (audio_server) co-location with the sound trigger service.
Since this service is now being migrated out of audio_server, a new
permission is introduced and granted to the audio server.
Change-Id: Ifcdfc2a5543d814fb0630a45cdd9bcdba4d92107
Bug: 142070343
This reverts commit 27c4e658b3.
Reason for revert: <potential performance regression. revert for now and looking for possible optimization from ART team>
Change-Id: I5bf728e4f6789d7e6398cf90f22fbf3a24d481c2
And also pre-grant it to all apps that currently get any storage
permission pre-granted
cherry-pick for qt-qpr1-dev Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
Test: - straight cherry-pick
- atest SplitPermissionTest
Bug: 141048840,140961754
Change-Id: Ia2219639a2104965a382ffef647e5ebaa0f9d540
And also pre-grant it to all apps that currently get any storage
permission pre-granted
Test: atest SplitPermissionTest
m -j gts && gts-tradefed run commandAndExit gts-dev -m GtsPermissionTestCases --test=com.google.android.permission.gts.DefaultPermissionGrantPolicyTest#testDefaultGrantsWithRemoteExceptions
Manual testing:
All combinations of
- App targetSdk = 28 and 29 (and 22 for extra credit)
- App having the <uses-permission> tag for
ACCESS_MEDIA_LOCATION or not
- Upgrade from P->Q-QPR and from vanilla Q->Q-QPR
Further upgrade of targetSdk from 28->29 while on Q-QPR
==> All permission behavior should make sense. Sometimes there
are weird, but expected behaviors. Hence we need to
collect the results and then look at the unexpected ones.
See SplitPermissionTest for some tests I added for the
location-background permission which was split from
the fine/coarse-location permissions
Fixes: 141048840,140961754
Change-Id: Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
telephony-common is not intended to used by any apps and
being in boot class is not updatability friendly.
We are removing telephony-common from bootclass and apply
<uses-library> in manifest instead.
for apps targeting < R will auto load telephony-common lib
for app compatibility. For apos >=R, only allow usage for
phone UID.
Bug: 135955937
Test: Build
Change-Id: Ia318661546df6d8516328886e5cc0c54d5cfafe6
The native services should specify their permissions in platform.xml if
they need internet permission, otherwise the eBPF program will block the
socket creation request. Fixing the known services that are in group
AID_INET but didn't specify their permission in the xml file.
Bug: 132217906
Test: CtsJdwpTestCases dumpsys netd trafficcontroller
Change-Id: I84cde7d3757953bc0bf761727d64a715bcdd68bb
Merged-In: I84cde7d3757953bc0bf761727d64a715bcdd68bb
(cherry picked from commit e5d6f0fa6c)
The native services should specify their permissions in platform.xml if
they need internet permission, otherwise the eBPF program will block the
socket creation request. Fixing the known services that are in group
AID_INET but didn't specify their permission in the xml file.
Bug: 132217906
Test: CtsJdwpTestCases dumpsys netd trafficcontroller
Change-Id: I84cde7d3757953bc0bf761727d64a715bcdd68bb
Hence mark the new split permissions as 29 instead of 10000.
Fixes: 132898943
Test: atest SplitPermissionTest
Change-Id: I0aa3e9b4d60cea1a59b891f2fb2d94a734efebf2
If an app can access the fine location it can obviously also access the
coarse location. There is code inside checkPermission that encapsulates
the logic.
This code fixes two issues:
- checkPermission might return for the coarse location even though the
permission is not even mentioned in PackageInfo.requestedPermissions.
Now the coarse location is always added to requstedPermissions when
the fine location is in the manifest even if the app does not have
the coarse location in the manifest
- If the app requests the fine location only we might unintentionally
kill the requesting app.
1. App does not have any permissions granted
2. App request FINE_LOCATION
3. Permission controller reads (and caches) permission state: FINE=revoked,
COARSE=revoked
4. User grants FINE_LOCATION -> Perm controller updates internal
state: FINE=revoked, COARSE=revoke
5. Perm controller applies FINE_LOCATION state to the system
6. Perm controller looks as COARSE and checks if it is granted.
Because it is implied, it now shows up as granted. Hence perm
controller will try to revoke it which kills the app
The solution is that it will be impossible to only request
FINE_LOCATION by itself. This change will automatically add requesting
COARSE_LOCATION, whenever FINE_LOCATION is requested
Fixes: 130358762
Test: Reproduced scenario in bug 130358762
Change-Id: I217c0b23063617f60b98c805af1d122a6ec0608e
- Also remove typed media permissions
- Leave typed media app-ops
Bug: 129716569
Test: Used apps, looked at permissions in the UI
Change-Id: If7714fb1a6955584157e1a60ab72b09e35287827
- Pre-Q apps use the legacy READ/WRITE_EXTERNAL_STORAGE permissions
- Post-Q apps use the READ_MEDIA_* permissions
- Grandfathered Q apps have all storage permission granted fixed. In the
UI they show only the legacy storage permissions
- The OP_LEGACY_STORAGE controls whether an app is grandfathered
Data providers should check both old and new permission model as
permissions that are not used are set as granted.
Test: atest CtsPermissionTestCases:android.permission.cts.DualStoragePermissionModelTest
Fixes: 126785920
Change-Id: I668530e62125d95f122a94ae39f17007391bcaa5
It is a helper in the system process that helps dumpstate and incidentd get
user confirmation to share reports
Bug: 123543706
Test: bit GooglePermissionControllerTest:*
Change-Id: Ia3fe4bd5257044ed89fe56ce683876fa03ba6c36
