lock screen: fix volume issue on voice_comm streams. #167
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
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.
Squashed with 0a99fc2 by quh4gko8 <[email protected]>
Package permission state is updated automatically for all packages after events that might impact it, e.g. after package install or uninstall, after storage volume mount, after OS update etc. On GrapheneOS, per-package permission policy can be changed via GosPackageState packageFlags. This new method is needed for updating the cached permission state manually after packageFlags change.
Notification is not shown if OTHER_SENSORS was explicitly denied by the user.
Apps sometimes misbehave when INTERNET permission is revoked and a job that they scheduled with a connectivity constraint is executed.
Change-Id: I0b65cac3c3d2fc495b339c34add742bd698b107c
Requires the corresponding changes to system/core and system/sepolicy.
…SELECTED Treat it same way other storage perms are treated for now.
This is a workaround for a bug that auto-dismisses crash dialog for native crash almost immediately after it is shown. Crash dialogs are shown only for foreground apps by default, there's no need to auto dismiss them.
Previous approach was to modify the ContentResolver query result, which doesn't work when Gservices database is read directly, as is done in GmsCore in some cases now that Gservices database is hosted by GmsCore. Instead, use GservicesProvider's built-in support for flag overrides which is implemented by the GSERVICES_OVERRIDE broadcast receiver.
Use the standard com.google.android.gms.phenotype.FLAG_OVERRIDE broadcast, which covers almost all phenotype flag storage/access types, unlike the previous approach.
This reverts commit 138a507.
APEX installation support slightly increases the attack surface.
This was not directly exploitable due to there being 2 layers of update package signature verification and downgrade protection, but the first layer of protection should work properly to avoid a vulnerability in the 2nd layer being exploited.
Avoid calling setNewlyInstalledInUserId() when restoring an archived app to ensure that the special permission auto-granting logic does not reset the user's previous permission state. Fixes: GrapheneOS/os-issue-tracker#5256 Signed-off-by: Andrew Gunnerson <[email protected]>
This is currently only granted for official hardware attestation app (Auditor) bundled in the OS.
Always load ApplicationInfo object needed for RemoteViews Contexts directly from PackageManager. The key used is the package name. Previously this object was read from the RemoteViews bundle, which was provided by the Widget providing app, and this object could not be relied on to have accurate data fields. Bug: 376028556 Flag: EXEMPT Security Fix Test: atest CtsWidgetTestCases:RemoteViewsActivityTest#testApplicationInfo (cherry picked from commit 352fb48) (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:f2251f1222e59b68d083a016bcc07d7c96980aab) Merged-In: Ie263b51fd2c2bdbf9d622533bb3f77d9f3f7181e Change-Id: Ie263b51fd2c2bdbf9d622533bb3f77d9f3f7181e
System components can run in any processes belonging to core uids. If one of such components end up registering a receiver, it will get registered as "android". Bug: 387930030 Bug: 310632322 Test: builds Flag: EXEMPT bugfix (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:a49d3c13aac1aa7d258665e14d8e5cc2ff7638df) Merged-In: I843fbead461062ae3369cc0f21d606fa1cf02ceb Change-Id: I843fbead461062ae3369cc0f21d606fa1cf02ceb
This reverts commit a3c5baa.
Bug: 371536480 Test: atest UserControllerTest Test: atest UserTrackerImplTest Flag: EXEMPT bugfix (cherry picked from commit a3bd1e2) (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:f7efa779da5c59085b38cb73da61ef0d83b672b6) Merged-In: I6fd04b00ab768533df01a3eca613f388bf70e42a Change-Id: I6fd04b00ab768533df01a3eca613f388bf70e42a
thestinger
force-pushed
the
15-qpr2
branch
4 times, most recently
from
fe7b0c1 to
0c8ac15
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.
Summary
This PR resolve the issue when you have a voice call application or any app with VoiceComm/Speech audio attributes running and you lock the device and try to change the volume.
Complete details here:
GrapheneOS/os-issue-tracker#5400