add special runtime permissions test cases #176
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
inthewaves
force-pushed
the
srtperms-tests-1.0
branch
3 times, most recently
from
1674cf6 to
999176c
Compare
inthewaves
force-pushed
the
srtperms-tests-1.0
branch
from
999176c to
9bf06fa
Compare
inthewaves
force-pushed
the
srtperms-tests-1.0
branch
from
9bf06fa to
6b613ec
Compare
On some devices, there is a telephony-related app that frequently requests location, so exempting it from privacy indicators is desirable. For example, the Pixel 6 has an IMS service where this applies. Change-Id: I5e99c89367bc3ffd31794736b0d66014fdc4faae
PackageInstaller is being made into an updatable app upstream, but it currently depends on several platform APIs on GrapheneOS.
"App info" screen now has a "Disable" button, which can be used as an alternative to uninstallation.
APK is not yet available at the time of pre-approval request, which is incompatible with the "Allow Network permission" checkbox in the confirmation dialog. See PackageInstaller.Session#requestUserPreapproval() for more info.
It's used by the LogViewer app.
Consumer Pixel devices have "MP1.0" as their hardware revision usually. Devices stolen from Google will have "EVT", "PVT" or "DVT" set in "ro.revision" by the bootloader. Additionally, check the secure boot state prop set by the bootloader, "ro.boot.secure_boot", to ensure it is set to "1", as typically pre-production devices won't have a blown secure boot efuse, completely destroying any concept of verified boot. Check both props, if either check fails, notify the user. Squashed with: 778380b Co-authored-by: Dmitry Muhomor <[email protected]>
Co-authored-by: inthewaves <[email protected]> Co-authored-by: June <[email protected]> Co-authored-by: quh4gko8 <[email protected]> Co-authored-by: Pratyush <[email protected]>
Only user app IDs were written to `mDeviceIdleWhitelistAppIds`, both initially and when `PowerManager.ACTION_POWER_SAVE_WHITELIST_CHANGED` broadcast was received. All other places that listen to that broadcast retrieve both user and system app IDs. The only place where `mDeviceIdleWhitelistAppIds` array is checked is in `isWhitelistedLocked()`, which is called only by `updateTaskStateLocked()` to check whether the app is on the device idle whitelist. It's not clear why DeviceIdleJobsController ignores system apps. File level comment doesn't mention the distinction between system and user apps: "When device is dozing, set constraint for all jobs, except whitelisted apps, as not satisfied." Comment for isWhitelistedLocked() does, however: "Checks if the given job's scheduling app id exists in the device idle user whitelist." However, that method is called for both system and user apps, and returns false for system apps because only whitelist of user apps is checked. This leads to long delays for jobs that were submitted by whitelisted system apps when device is in the Doze mode. No such delays happen with whitelisted user apps. Other places use a different naming for array of app IDs that includes only user apps, eg `mDeviceIdleWhitelistUserAppIds`, not `mDeviceIdleWhitelistAppIds`. I've looked through the Git history of DeviceIdleJobsController and JobSchedulerService, but didn't find a reason for this behavior. Perhaps, system apps were exempted from device idle JobScheduler restricitions in some other place previously, or this was a bug from the start. Tested on an emulator with the Messaging app, which uses JobScheduler during processing of incoming SMS: 1. Check that Messaging app is on system deviceidle whitelist: ``` $ dumpsys deviceidle whitelist | grep com.android.messaging system-excidle,com.android.messaging,10090 system,com.android.messaging,10090 ``` 2. Simulate sending an SMS: it appears immediately 3. Simulate Doze mode: `$ dumpsys deviceidle force-idle` 4. Simulate sending an SMS again. Message doesn't appear, even if the Messaging app is open 5. Exit Doze mode: `$ dumpsys deviceidle unforce`. All pending messages appear immediately 6. Add Messaging app to the user whitelist: ``` $ dumpsys deviceidle whitelist +com.android.messaging $ dumpsys deviceidle whitelist | grep com.android.messaging system-excidle,com.android.messaging,10090 system,com.android.messaging,10090 user,com.android.messaging,10090 ``` 7. Simulate Doze mode again: `$ dumpsys deviceidle force-idle` 8. Simulate sending an SMS, note that it appears immediately this time Also made a test system app to make sure that this issue isn't caused by low targetSdk of the Messaging app (it targets SDK 24). Same issue with targetSdk 32 app. In both cases, applying this patch fixes the issue.
Needed for PackageManagerHooks.shouldFilterApplication() method.
This is done to have the build break in case grantImplicitAccess() starts to get used in more places, which might weaken AppsFilter-based app isolation via PackageHooks.
By default, Settings.{Global,Secure,System} that aren't annotated with `@Readable` are
readable only by preinstalled apps (with some exceptions, see enforceSettingReadable()).
Settings.{Global,Secure} settings are writable only by apps that hold the privileged
WRITE_SECURE_SETTINGS permission. Settings.System are also writable by apps that hold the
WRITE_SETTINGS app-op permission (it's surfaced as "Modify system settings" in the UI).
This commit adds `@Protected` setting annotation, which allows to further restrict settings access
by specifying which system apps are allowed to read and/or write them.
Modified code to use upstream name (isCredentialShareableWithParent with an "e"). Commit name should also be changed
ContentResolver: Stick with the upstream parameter name
In 15-qpr2, `flatExtraArgs` was passed to the argument of `getProcess`, but the argument for `flatExtraArgs` in the `start` method (last parameter) is null.
Flag name was changed from what upstream uses
Rebase note: Needs to be before "bugfix: appropriately set quiet mode when being enabled/disabled" in history
This reverts commit a12700c.
Changes from 16: Adds a check to only set the previous downstream behavior of setting logout userId to system userId on secondary user start, and without an active (device) admin. Methods like #getLogoutUserId() is now used also to determine the logout button presence in SystemUI.
Android 12's privacy dashboard shows permission usage timelines for location, camera, and microphone. However, there's no reason to limit it to those specific permissions; all the infrastructure is in place for other permissions. In Android 16, this will be done for us upstream when the aconfig flags android.permission.flags.record_all_runtime_appops_sqlite and android.permission.flags.enable_sqlite_appops_accesses are enabled. With the enable_sqlite_appops_accesses flag off, all the appops are saved to binary XML. To enable the usage timeline for more permissions, keep discrete app op history for all permission groups shown in the privacy dashboard. The list of permission group -> app op mappings was obtained from AppOpsManager.RUNTIME_AND_APPOP_PERMISSION_OPS with a few additional ops from PrivacyItemController, and each op was resolved to its respective enum ordinal from frameworks/proto_logging/stats/enums/app/enums.proto. Test: adb shell dumpsys appops --include-discrete 0 Change-Id: I6b1c476ea4c0edbc0b3fdf2e3e5cfcb11da77e33
See the README.md for more info. Run tests with atest SpecialRuntimePermsTestCases
inthewaves
force-pushed
the
srtperms-tests-1.0
branch
from
6b613ec to
ed2ad27
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SpecialRuntimePermsTestCases
Test cases for GrapheneOS special runtime permissions.
The tests won't compile if the
OTHER_SENSORSpermission isn't implemeneted (compiles using the newmanifest entry for
android.permission.OTHER_SENSORSand the system message notification id forcom.android.server.ext.MissingSpecialRuntimePermissionNotification).Running tests
Run an active device with internet access (might be best done with
emulator -wipe-data -read-onlyfor a clean slate, and on a userdebug build) and then runThis command will handle building and pushing the APKs onto the device (see
AndroidTest.xml for details).
Specific tests can be run by specifying the test class (and optionally the test function name)
after
:, e.g.Overview of tests
cases (based on the tests from Avoid auto-granting special permissions to unarchived apps #163)
instead of throwing errors
should be posted if an app tries to access sensors when the permission is revoked
Much of the test code and apps are based on existing AOSP CTS tests (
cts/andpackages/modules/Permission/tests/cts). Some CTS test failures were used to build test cases here.Known issues
(
packages/modules/Permission/tests/cts/permission/src/android/permission/cts/LocationAccessCheckTest.java).Sometimes the tests might fail from a
DeadObjectExceptionor other misc failures.TriggerEventListenerlike forSensor.TYPE_SIGNIFICANT_MOTION. Seems more complicated to test (thoughhere's an existing CTS test for it)