Conversation

Replying to

Oh, interesting GrapheneOS as a fork of AOSP. I wonder if people is willing to go without the Play Services, which is what makes Android Phones useful. A phone without apps is mostly useless and most devs only care about Google Play / App store

2

Replying to

You can use Aurora Store. But apps that require Google Play Services will fail. GrapheneOS folks are working on a container of sorts that might fool some apps but not sure how robust that is yet.

1

1

Replying to

and

grapheneos.org/usage#sandboxe is available now so users have the option to install Play services as a fully sandboxed app in profile(s) of their choice. It's meant to be used to make a dedicated profile for apps requiring it. Doesn't give it any additional access vs. libraries in apps.

1

2

2

Replying to

and

Users need to explicitly decide to install the apps since we'll never include it in the OS. Only apps this approach needs to coerce into working are the 3 Play services apps. It teaches them how to function as regular apps by returning placeholder data, etc. so they don't crash.

1

1

Replying to

and

Anything inherently depending on privileged functionality can't work, but most of it doesn't. A lot of the core functionality already works fine. Needs more shims returning placeholder data instead of having it get SecurityExceptions it can't handle and some more fallback code.

1

1

Replying to

and

Since we're not bundling anything with the OS, it's entirely possible to support alternatives in the future. For now, we're going to focus on getting this working really well and trying to make the code as easy to maintain and port to future releases as possible. It's still new.

1

1

Replying to

and

This is a huge project. Kudos to the team. I would expect anything tied to in app purchases to not work, but a fully free and open source mobile OS is a great goal.

1

1

Replying to

and

In-app purchases, etc. should all work fine. There are certain things not working well yet such as apps using Play services APIs for location instead of OS APIs. Many apps use the OS APIs and the OS doesn't use Play services for anything even when a user installs it in a profile.

1

1

Replying to

and

Anything tied to using special access such as access to hardware without asking the user won't work without us implementing compatibility shims. All we provide is code to detect those 3 apps and provide them with the fallback code they're missing to work as fully sandboxed apps.

1

2

Replying to

and

Mostly just means intercepting their attempts to use privileged APIs and returning placeholder data rather than attempting to do it and getting a SecurityException. In some cases, we need to give them an alternate approach using unprivileged APIs, asking user for consent, etc.

1

1

Replying to

and

For example, we started teaching Play Store to use the regular install dialog for installing and updating apps. In Android 12, there's a standard API allowing an app to perform unattended updates of an app it installed. Key pinning + downgrade protection still applies of course.

5:31 PM · Aug 11, 2021Twitter Web App

Replying to

and

The OS has a limited number of privileged APIs, and Play services only uses a subset of those. We need to go through the ones that it can't work without and gradually add shims replacing it with placeholder data, no-op functions and in some cases alternate unprivileged fallbacks.

1