Always disable pinning apps to memory regardless of config #152
Conversation
This file contains 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
"App info" screen now has a "Disable" button, which can be used as an alternative to uninstallation.
Directory can be removed by the time listFiles() is called, which makes it return null. Null can also be returned due to an I/O error.
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]>
Commit history: Before Android 13: https://github.com/GrapheneOS/platform_frameworks_base/commits/30ab1eae4cd03270f0dce82a67a0122df7fb7c29 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.
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.
Ported from 12: 9d5a62e
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.
…ng is on" This change was needed by a now-reverted GmsCompat app change.
Desktop mode support remains disabled by default, it's controlled by a dev option.
Split notification shade is used on tablets in landscape mode and on foldables in unfolded state.
This bug led to alarm and DND lockscreen info being misplaced.
This change also moves media info below alarm and DND info to improve transition animation between always-on-display and lockscreen.
Keyguard slice view is replaced by smartspace view in SystemUIGoogle. Smartspace view is not included in AOSP.
…e is used Adjust the original change to addition of keyguard slice view by the previous commit.
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.
|
|
quh4gko8
force-pushed
the
bp1a-dev_03-27_01
branch
from
1751264 to
17e4e26
Compare
quh4gko8
force-pushed
the
bp1a-dev_03-27_01
branch
from
17e4e26 to
dae1be0
Compare
thestinger
force-pushed
the
15-qpr2
branch
5 times, most recently
from
5f3142f to
8edf282
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.