-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add optional installation of play apps into work profile #4
base: 15
Are you sure you want to change the base?
Conversation
There's a known issue in AOSP 12 caused by it creating overly large intents for the work manager. It's not caused by anything done by end users and they can't work around it so avoid reporting it to them since they get a message each time it tries again.
This will match pre QPR1 clock font. Change-Id: Idef5fb093d81f49e40f2fcf4df69f834804916ae
Safe Volume has many false alarms. And if overridden by the user, at every 20 hours of accumulated(!) audio playback it will intentionally reset - even while the audio is playing. This can ruin the listening experience, and ironically pose a safety hazard when e.g. the user is operating a vehicle... AOSP already opted out of Safe Volume in the overlays for Mobile Country Code 310-316 (= US). Make this universal. Signed-off-by: Rusty Bird <[email protected]>
Cloudflare DNS has a better privacy policy than Google Public DNS while still supporting DNS over TLS.
Signed-off-by: anupritaisno1 <[email protected]>
Cloudflare DNS has a better privacy policy than Google Public DNS while still supporting DNS over TLS.
This change is required by Settings app commits that add extra items to "All files access" and "Install unknown apps" special access permission screens.
Signed-off-by: r3g_5z <[email protected]>
This upstream feature checks that signatures of updated system apps verify against signatures of the corresponding system apps. Such checks are already performed downstream as part of PackageVerityExt, this upstream feature is an extra layer of protection.
This reverts commit 6bddf9b.
…server Add direction-aware overload of shouldBlockPackageVisibility().
- don't block visibility to the Fitbit app, it has special integration with the Pixel Health app - don't block visibility from current launcher to Pixel Health, but keep blocking it in the opposite direction
This reverts commit 9eb04a6.
disableNotificationEffects is removed
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.
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 |
continuation of GrapheneOS-Archive/platform_frameworks_base-old#559