ImsServiceEntitlement is a headless app for certain carriers requiring
background IMS provisioning only. So the app needs to be allowed to
schedule jobs.
Bug: 189397221
Test: make
Change-Id: Ib910681ef81a417aaa4a13514260cfa26098a048
No longer grant READ_PHONE_STATE as a fixed permission to all apps
holding READ_PRIVILEGED_PHONE_STATE. Also clean up the previous grants
by un-fixing the permission if the app requests it in the manifest, and
removing it altogether if the app only requests READ_PRIV.
Bug: 183537857
Test: manual -- prepare two system apps, one with READ_PRIV and
READ_PHONE and one with only READ_PRIV, then go through the upgrade flow
with this CL.
Change-Id: Id1fac0f9f4391857f46c7109eadafd60420b279d
This allows it to schedule alarms while the device is in doze without
needing SCHEDULE_EXACT_ALARM permission, which is user visible.
Test: adb logcat -s AndroidRuntime
should show no crashes for "com.android.providers.calendar" due to
missing SCHEDULE_EXACT_ALARM.
Bug: 171306433
Change-Id: I3dc358f0de0f6d869c3c6e7d6c2c243dc2348096
This change is part of defining a distinct BLUETOOTH_ADVERTISE
permission to guard the BluetoothLeAdvertiser APIs, since that's a
distinct enough of an operation from SCAN and CONNECT. It'll
continue to be covered under the general "Nearby devices" runtime
permission group.
Bug: 181813006
Test: atest CtsPermission2TestCases
Test: atest CtsPermission3TestCases
Change-Id: I8b62e4d625df1e201f12a73025cd29c431feea79
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
