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
All buttons and axes on DualShock3 and DualShock4 are mapped
explicitly, because some Linux drivers do not map them correctly.
Also, the definition of BUTTON_X/Y in Linux and Android is flipped.
The most significant bit (i.e. 0x8000 and 0x8111) in the "Version"
part of the filename indicates a newer Linux hid-sony driver (>=4.10
for DualShock4 and >=4.12 for DualShock3) which complies to the
mapping in Linux gamepad specifications, and supports all DualShock4
features (i.e. motions sensors, touchpad).
Older Linux driver which does not have the correct mapping will use
the mapping files without "Version".
All files with "Version_8000" and "Version_8100" are meant for
Bluetooth connected DualShock3/DualShock4, and all files with
"Version_8111" are meant for USB connected DualShock3/DualShock4.
Test: Connect DualShock3 and DualShock4, over USB and over Bluetooth.
Test: Check that the Dpad and left analog stick can be used to
navigate the UI.
Test: If newer Linux driver is loaded, check that the touchpad can
be used to navigate the UI.
Bug: 38511270
Change-Id: I5630c495af16185689bbff25943b3e2d3c93e709
These two libraries:
android.hidl.base-V1.0-java
android.hidl.manager-V1.0-java
are being removed from BOOT_JARS. This change facilitates linking to them
for libraries or prebuilts in or before P.
Test: atest android.content.pm.AndroidHidlUpdaterTest
Bug: 77307025
Change-Id: Ic0db24cc68d66f5dbfab126ce7e304eec0bfc969
To implement Settings contextual card. We need this permission to
use CardContentProvider in Settings app.
Test: rebuild and flash ROM
Bug: 114521742
Change-Id: If729b2597a458c26c466e87dfa9b4ddc9c3ef948
To be able to use font file in their apps, provides blob and path to the
font file and locale list as well.
Bug: 26116537
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
CtsGraphicsTestCases:android.graphics.font
Change-Id: I1ae1302c6906b808012e1e91b1e4ab393c887cb6
Currently, the circle button on odie (Asus Gamepad) is mapped to HOME.
But it is not clear which button is which just from looking at the key
layout file.
Add some annotations here.
Bug: 111431828
Bug: 110270125
Test: atest AsusGamepadTestCase (the test is currently in development)
Change-Id: I8d1317be7f403ceaf0c2d72d756623e3cd032559
android.test.* are built with java_sdk_library and api files are added
by running "make update-api".
android.test.base_static is created for allowing to use
android.test.base as a static library.
Bug:77577799
Test: make -j
Test: make checkapi
Test: make checkapi fails with a random change in the txt file
Test: adb shell cmd package list libraries |\
grep android.test.*
And check the android.test.* libraries
Merged-In: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
Change-Id: Ia27612657532e50b077a9c55dbef59ee3ec04b8a
Currently, BUTTON_MODE falls back to MENU.
It is not clear which functionality relies on that. However, many
joysticks currently map their "branded" button, for example, the "XBOX"
key on the Xbox joystick, and "PS" key on the playstation joystick, to
the BUTTON_MODE. On other joysticks, the same button is mapped to
"HOME". So it would make sense to have this button to fall back to HOME
in order to make the behaviour consistent.
Also, remap the "XBOX" button on the Xbox controller to "BUTTON_MODE".
This would give apps the chance to intercept this key and actually use
it, instead of limiting it to the system.
Bug: 37115804
Bug: 77803694
Test: Made a test app to dump out joystick events in response to
dispatchKeyEvent. Then either returned true or false to ensure that the
fallback happens. If returning true, the app has handled the event, and
HOME is not dispatched. If returning false, the app does not care about
the event. Therefore, HOME is generated and the phone goes to home
screen (so the app gets closed).
Change-Id: I023620551f52d34638303db60f8a4ca37f06d4d8
Merged-In: I023620551f52d34638303db60f8a4ca37f06d4d8
In an earlier commit, ag/4071802, (Change-Id:
I33e922a2c52582f44d65f20024d7dca1f9d05a5e), this particular file was
overlooked.
Quick fix here to make everything consistent. We will add the other
variants of these devices in the future.
Test: partial cherry-pick from Sony CL on aosp
Bug: 79881694
Change-Id: I8ab46fde8650724464b1e799cd948682c56e5b52
Merged-In: I8ab46fde8650724464b1e799cd948682c56e5b52
Currently, BUTTON_MODE falls back to MENU.
It is not clear which functionality relies on that. However, many
joysticks currently map their "branded" button, for example, the "XBOX"
key on the Xbox joystick, and "PS" key on the playstation joystick, to
the BUTTON_MODE. On other joysticks, the same button is mapped to
"HOME". So it would make sense to have this button to fall back to HOME
in order to make the behaviour consistent.
Also, remap the "XBOX" button on the Xbox controller to "BUTTON_MODE".
This would give apps the chance to intercept this key and actually use
it, instead of limiting it to the system.
Bug: 37115804
Bug: 77803694
Test: Made a test app to dump out joystick events in response to
dispatchKeyEvent. Then either returned true or false to ensure that the
fallback happens. If returning true, the app has handled the event, and
HOME is not dispatched. If returning false, the app does not care about
the event. Therefore, HOME is generated and the phone goes to home
screen (so the app gets closed).
Change-Id: I023620551f52d34638303db60f8a4ca37f06d4d8
