strcat

Developers have to go out of their way to implement triggering Play Integrity API checks in their app and then retrieve the results to check on their services. They're putting a lot of effort into banning anything not licensing Google Mobile Services. It's definitely not a security feature since it permits devices with no security updates for more than 8 years but not a far more secure OS than anything Google certifies. Google doesn't allow GrapheneOS to obtain certification and certification comes with highly anti-competitive rules which would be completely unacceptable. Their licensing system has been ruled illegal in South Korea and other countries should not only do the same but ban the Play Integrity API and other related anti-competitive features. These are not actual security features and that's an excuse for the actual purpose of enforcing their GMS licensing model including forcing including a bunch of Google apps with extremely privileged access and using their builds of many OS components shipped from the Play Store.

They don't need to do anything to support GrapheneOS. They only need to stop actively going out of the way to block it and any other alternative OS via the Play Integrity API. They put significant effort into blocking anything other than iOS or a Google Mobile Services Android stock OS certified by Google. They're not only blocking a non-stock AOSP-based operating system but rather anything other than iOS or a Google Mobile Services Android device certified by Google.

The kernel drivers are all published in the GrapheneOS kernel repositories. A subset of the libraries/services in the vendor partition used with those drivers are closed source.

Pixels were headed towards all of the device support code for the OS being open source along with open sourcing large portions of the firmware including for the TEE (Trusty OS) and secure element (OpenTitan). It was ended after the launch of Android 16. It's a major factor in why GrapheneOS is going to be focused on future Motorola Mobility devices. You can still see a large portion of the Pixel userspace driver libraries and services in the AOSP source tree but they stopped pushing new releases for a lot of it.

/e/ has drastically worse privacy and security from the Android Open Source Project or especially and iPhone. It's not a step up from standard AOSP. It lags many months behind on many High/Critical severity patches, years behind on overall patches and rolls back the privacy/security in a bunch of ways. It includes many invasive services.

It has many default enabled highly privileged Google services including downloading Google Play executables such as droidguard and running those with similar privileged access as they have on a Google Mobile Services OS anyway.

No, but all of the kernel drivers are open source and always were. The closed source userspace libraries such as the Mali GPU library aren't a barrier to porting to a new kernel version which is what was said above. We could move to 6.12 ourselves but we choose to wait for them for much broader testing which is happening with Android 17 QPR2.

> GrapheneOS is security before anything else.

GrapheneOS is a privacy project highly focused on usability and compatibility. Privacy depends on security so it has to put a lot of work into security too and it has always been a major focus, but it's a misconception that it's all about security.

> This means they strongly advice against using other software many in their core audience are predisposed to like: Firefox, Signal, plugins for browsers, F-Droid, ect.

GrapheneOS doesn't recommend against Signal but rather it's the main recommendation for end-to-end encrypted chat from the project including via the Molly fork of Signal.

> The explanations are usually quite... blunt, and they're not exactly open for discussion (which makes sense, from a pure security perspective, those apps are indefensible).

This isn't true. GrapheneOS provides nuanced information with detailed explanations for these topics.

For security reasons, GrapheneOS uses ahead-of-time compilation for apps. The stock OS compiles the heavily used parts of the code dynamically in-memory and then does partial ahead-of-time compilation later in the background. The install-time compilation will become more asynchronous in the future so the app can be used right away.