1. decouple disconnectCause and preciseDisconnectCuase from
preciseCallState.
2. expose preciseCallState to SystemAPI and expose
onPreciseCallStateChanged to System API
3. remove/hide ImsReasonInfo from PreciseDisconnectCuase
4. expose DiconnectCuase and PreciseDisconnectCause to System API
5. new onDisconnectCauseChanged API on PhoneStateListener for CS call
and use ImsCallSessionListener for IMS call(imsreasonInfo)
6. add read_precise_phone_state to shell apk to enable GTS test
Bug: 119890559
Test: atest GtsGmscoreHostTestCases:TelephonyHostTest#testPhoneStateListener
Change-Id: If9256feff16b6bcaef1dfe194c2b0df2a48436b0
(cherry picked from commit 6a942d488af3356fe84b0cef396e613d8d74101e)
Merged-in: If9256feff16b6bcaef1dfe194c2b0df2a48436b0
1. decouple disconnectCause and preciseDisconnectCuase from
preciseCallState.
2. expose preciseCallState to SystemAPI and expose
onPreciseCallStateChanged to System API
3. remove/hide ImsReasonInfo from PreciseDisconnectCuase
4. expose DiconnectCuase and PreciseDisconnectCause to System API
5. new onDisconnectCauseChanged API on PhoneStateListener for CS call
and use ImsCallSessionListener for IMS call(imsreasonInfo)
6. add read_precise_phone_state to shell apk to enable GTS test
Bug: 119890559
Test: atest GtsGmscoreHostTestCases:TelephonyHostTest#testPhoneStateListener
Change-Id: If9256feff16b6bcaef1dfe194c2b0df2a48436b0
Since this app is frequently customized by OEMs, it doesn't
fit in the mainline /system image right now. Move it to
/product.
Bug: 110072687
Test: make
Test: boot blueline
Test: atest SystemUITests
Change-Id: If27bcccd62f239f716db5ee7f4f1418d936e1cf4
The app is moving to /product, so move the permission
grants as well.
Bug: 110072687
Test: boot blueline
Change-Id: I34fcab908db5b7a96a50b45bb45941282b05a82d
This makes it possible to move the permission around separately
from all the other permissions. This permission file is included
automatically when the respective app is included.
Bug: 110072687
Test: make
Change-Id: I91b30561d4a4000334ffbf3b98bb632d962f4b97
Initial prototype disabling location/sensors and enabling airplane mode.
Camera/Mic will come in a followup.
Test: manual
Bug: 110842805
Change-Id: I26132fcc9ffea83e3e78a0e54882d23c99ee590c
... and syncronize it with other privapp permission owner files.
Test: I understood that we want to keep the priv-permisions apps have to
a minimum to reduce the risk
Change-Id: Id2763e1788b9647b738a708159dc9eb5878232bf
If an app declares that is has flagile user data, all the user to choose
to keep the app-data on uninstall.
Test: Unistalled apps that set the new flag and app that did not.
Verified that the KEEP_DATA flag was set when checkbox was
clicked.
Change-Id: I032fb21854352bbc175934ae5eb68a1430b1d403
Fixes: 117578306
Apps might have contributed files. During uninstall the files are
usually left on the system. To avoid filling up the storage we allow the
user to delete the files during uninstall.
Bug: 112002130
Test: Uninstalled an app that contributed files
Change-Id: I7e71ed524055bdda91ce9e66f995540363ceb229
Bug: 120096113
Test: Build with built-in libraries that declares new depedency flag, no
more boot errors (tested with cheets_x86_64 and crosshatch_userdebug)
Change-Id: I6b3e2ab7626ed8f04c0bf1a5b3c32204a2f2c56b
This change updates the permissions design to use app-ops for
controlling write access, which is only extended to the default app
for a particular collection type.
Bug: 119713234
Test: atest android.appsecurity.cts.PermissionsHostTest
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I40811ff175b3b8410b58ed901948a23a56f8a8c2
A small clean-up CL to follow-up on two comments from the original
review:
* Remove the new permission from privapp-permissions-platform.xml as it
is a signature-level permission, not a privileged premission, and as
such does not need to be in that file.
* Do not store the grant state if it's set to false - since the
de-serialization code will only care if there's a "true" value stored.
Bug: 111335970
Test: Manual
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest com.android.cts.devicepolicy.MixedProfileOwnerTest#testKeyManagement
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testKeyManagement
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDeviceIdAttestationForProfileOwner
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testDelegatedCertInstallerDeviceIdAttestation
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegatedCertInstallerDeviceIdAttestation
Change-Id: I8b570220f5652846fccc53b5e4daaa57f89eb824
I688e87cf09ad206f4f517a7be960c2aa01af8fc4, restricted privileged apps from silently becoming Device Admins.
Ia4e1ce9b81756e7f84ed0aa22d97e0b968cd8d89 added privileged APIs for locking the device and resetting the password.
We continue that work by providing an alternative for DevicePolicyManager#setKeyguardDisabledFeatures guarded by android.permission.CONTROL_KEYGUARD_SECURE_NOTIFICATIONS
Bug: 111153365
Bug: 112601004
Test: Secure notifications can be redacted on keyguard
Change-Id: If81cecf6e74f7abcff581a122c4b68cc04ff57c6
In order to allow inclusion of device identifiers in the key attestation
record generated by the profile owner, the platform needs an explicit
signal that it is OK for the profile owner to access those identifiers.
Add a system-privileged method to the DevicePolicyManager that allows
system applications, as well as Managed Provisioning to indicate that the
profile owner may access those identifiers.
In the DevicePolicyManagerService the following has changed:
* The OwnerInfo now contains a flag indicating whether the profile owner
was granted access to the device identifiers or not.
* The permission check for use of the Device ID Attestation flags in
generateKeyPair has been adjusted to allow profile owner (or its
delegate) to use them, if device identifiers access has been granted.
* A couple of utility methods have been added to ease checking of
profile owner presence for a user and whether the profile owner can
access device identifiers.
Additionally, a new adb command has been added to give this grant to an
existing profile owner for testing purposes.
Bug: 111335970
Test: Manual, using TestDPC + ADB command.
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: Additional CTS tests, see cts change in the same topic.
Change-Id: I05f2323d5edacd774cd3ce082ee9c551100f4afd
BatteryStats calculates power usage of the device and various components
(such as apps). This information is used, e.g., in the battery panel of
Settings. We now log it to statsd. It can be used for validating how
good the information displayed in Settings is. In the long-term, it is
likely not ideal for off-device calculations, since that can be
hopefully estimated using statsd's raw data.
Three atoms: one for the total power use, one for the power use of each
uid, and one for each non-uid component. Since they will all likely be
pulled together, StatsCompanionService will provide stale data for
BatteryStats pulls called within a second of a previous BatteryStats
pull.
Also in this cl:
Remove StatsLogEventWrapper.writeDouble. Statsd doesn't support actually
writing doubles into its proto reports, so having this function is
misleading (the data will get to statsd and then be completely ignored).
It's less confusing if we don't pretend it does something.
Change-Id: If80bab8ea938afa4632535bb88ff59879fbe8099
Fixes: 119111972
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testDeviceCalculatedPowerUse
Test: cts-tradefed run cts-dev -m CtsStatsdHostTestCases -t android.cts.statsd.atom.UidAtomTests#testDeviceCalculatedPowerBlameUid
Test: BatteryStatsHelperTest#testDrainTypesSyncedWithProto
Adding a new permission for managed provisioning to access privileged network
operations.
Bug: 115980767
Test: Compiles
Change-Id: I6375c119a7c5e13f1648803c7da5cebd6830d46c
Per requirement of cross profile calendar feature, CalendarProvider will
need MANAGE_USER to get work profile user, and INTERACT_WITH_USER to
access its work profile equivalent.
Personal CalendarProvider needs to get the corp user ID, so it needs to
call userManager.getUsers() which requires
{@link android.Manifest.permission#MANAGE_USERS} permission.
We'll maintain a whitelist of packages set by DPC that are granted access
to cross profile Uris in CalendarProvider, so random personal apps
won't be able to access those Uris.
Bug: 118456304
Test: manual
Change-Id: I59e4a7f39f9abc69f0dcc7ff03d822b8d44b4dbc
This will be installed in /system/etc/permission when the TZ updater
app is installed.
Bug: 119481876
Test: make
Change-Id: I85a9ac353ee0ed0e30bc1db12a37370445e05527
This creates the PowerManager APIs that allow apps with the
appropriate permissions to interact with Dynamic Power Saver.
Bug: 111450127
Test: WIP
Change-Id: I5b9483fa0fba81a4ade622b1f3dbaec580b68a67
Previously reverted due to b/72554856, fix for that in topic.
Original commit message:
Security model for moving sharesheet to systemui
ResolverActivity (still in frameworks) now requests a "permission token"
that it hands to a stubbed system ui activity ChooserActivity.
This permission token allows an app (SysUI) with the signed permission
"START_ACTIVITY_AS_CALLER" to call
ActivityManagerService#startActivityAsCaller. Permission tokens are a
one-time use, limited-time offer.
Test: runtest systemui && manual testing
Bug: 69850752
Change-Id: Ia50e21e2f8c6b6d0ed7207625e3b5aef214396bb
Ia5b3f47b73c9feea924373268a4eee142f555091 introduced a bug where the targetSdk for android.permission.ACCESS_FINE_LOCATION and android.permission.ACCESS_COARSE_LOCATION was set to 28 instead of Q (10000).
Test: CtsAppThatRequestsLocationPermission28.apk requests android.permission.ACCESS_COARSE_LOCATION and android.permission.ACCESS_BACKGROUND_LOCATION
Bug: 118882117
Bug: 111411340
Change-Id: I532379aa2c8a173a516d38e1c8568cff5dbaed33
Instead of defining split permissions in Java file, we now move them to XML allowing us define vendor specific split permissions.
Test: Activity recognition is split correctly and auto granted when below split targetSdk.
Bug: 111411340
Change-Id: Ia5b3f47b73c9feea924373268a4eee142f555091
Also remove the "Usb" from the AIDL function since it's not really
related to USB.
Test: make
Bug: 63820489
Change-Id: Ibf23964665a115a5bc835820dcff98aaf7ba610f
Also create a new MANAGE_ACCESSIBILITY permission to
perform the shortcut.
Bug: 116118615
Test: make, activate accessibility shortcut
Change-Id: Ic65a0cdf7393429e14cb98f4fb0734d20069b05a
This intent is used by the Permissions Hub.
We also give PermissionController the GET_APP_OPS_STATS permission.
Bug: 63532550
Test: Used the Permissions Hub.
Change-Id: If1254f67c12fc5052d6ad5ff8260778a7c59dccc
As the initial version of the OEM customization XML, support
new-named-family customization. This allows OEMs to add new named
family.
Bug: 111544833
Test: atest FrameworksCoreTests:android.graphics
Change-Id: If58711fc038898175fcad0ae095865312bd738e2
