add optional installation of play apps into work profile #4
Conversation
mkg20001
changed the title
|
The commit I'm still working on this, but the changes are in gapps-work-profile-wip. Once they work I'll push them to this branch aswell. I'm keeping the working version arround in this pr so people can try it / hack on it. |
|
Keeping this all tied in, two threads that could potentially benefit from this merge, thanks again for your efforts to get this going in future!:- https://discuss.grapheneos.org/d/1841-ms-intune-company-portal-with-work-profile-not-working/5 https://discuss.grapheneos.org/d/1581-sandboxes-gplay-services-in-a-work-profile/7 |
Commit history: Before Android 13: https://github.com/GrapheneOS/platform_frameworks_base/commits/30ab1eae4cd03270f0dce82a67a0122df7fb7c29 13: a40e627709a7 Signed-off-by: June <[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.
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.
13: e6761e05a9ee
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.
Signed-off-by: anupritaisno1 <[email protected]>
Change-Id: I0b65cac3c3d2fc495b339c34add742bd698b107c
For matching in maybeInstallPlay in DevicePolicyManagerService
…triction This permission is supposed to be granted to apps that are installed in a work profile and should be exempt from the DISALLOW_UNKNOWN_SOURCES restriction that can be set via device policy
When setting up a work profile, GmsCore tries to install Android Device Policy apk For this to work REQUEST_INSTALL_PACKAGES permission needs to be in manifest
Currently when using any DPC app (like Google Device Policy or others) that uses play services in any way it expects it to be present in the newly created work profile, as this is the case on phones with un-sandboxed-gapps. That's currently broken on GOS due to play apps not being global here. This can be solved with installing the play services into the work profile. We automatically detect if the app needs play services and install them into the work profile alongside it. Because this needs to happen at the earliest possible moments in order for the DPC app to do it's job properly (mainly Google Device Policy, likely others aswell), this needs to be part of the profile creation itself.
mkg20001
force-pushed
the
gapps-work-profile
branch
from
8d66946 to
6cc39fe
Compare
|
I added signature checks through extended app info and moved most of the code to it's own class so it's more maintainable I do get your idea to move it out of the service but I couldn't figure out how to Currently play store is getting installed into the profile right after it's created. This is happening in the service so I can't do it "before". I'm not sure if doing it afterwards work out or where I'd best move my code. Without pointers I'm honestly lost on this. |
|
I can either keep the permission USER_TRUSTED_SOURCE or replace it with just a check if it's play store trying to install an app and make sure it has an exception for device policy unknown source restriction. I don't really have other ideas of how to make it non-google-specific. Adding a custom "is this from play store" check would be easier then having this permission arround. (It would still require the "allow from this source" toggle to be on it would just skip play store being blocked by device policy by ignoring the unknown sources restriction for play store) Edit: I could also add a DPC api for adding trusted unknown sources, but since it would be grapheneos-specific it would only make sense if AOSP were to adopt it. |
thestinger
force-pushed
the
15
branch
2 times, most recently
from
61879fc to
2103ff4
Compare
thestinger
force-pushed
the
15
branch
9 times, most recently
from
3d97c25 to
f3469eb
Compare
continuation of GrapheneOS-Archive/platform_frameworks_base-old#559