Always disable pinning apps to memory regardless of config #152
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
|
|
quh4gko8
force-pushed
the
bp1a-dev_03-27_01
branch
2 times, most recently
from
17e4e26 to
dae1be0
Compare
thestinger
force-pushed
the
15-qpr2
branch
5 times, most recently
from
5f3142f to
8edf282
Compare
thestinger
force-pushed
the
15-qpr2
branch
10 times, most recently
from
3ec1472 to
ccaf1e6
Compare
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]>
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
quh4gko8
force-pushed
the
bp1a-dev_03-27_01
branch
from
dae1be0 to
2361696
Compare
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.
No description provided.