Open source privacy and security focused mobile OS with Android app compatibility.
GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.
@[email protected] No, it’s a production release going through the same process as every other release. Please read https://grapheneos.org/releases#about-the-releases. Releases never go directly to the Stable channel but rather get pushed out to Alpha, then Beta and then Stable. You choose how early you get it via the channel selection. There are not separate releases for Alpha and Beta, which is a misconception about how we do things.
GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.
@[email protected] A user has reported it works fine when configured correctly in Owner:
https://discuss.grapheneos.org/d/16820-urgent-sms-registration-is-broken-on-android-15/38
We know there are SMS/MMS regressions brought by Android 15 in secondary users which are not GrapheneOS specific.
@[email protected] @[email protected] Apple makes that fairly clear themselves by the fact they only backport a subset of the patches and don’t really like acknowledging they’re even still providing support since they want people to move on. You can find many sources for it by searching for it but whether those should be considered reliable is another story. We don’t particularly see a reason to reference what someone else says particularly if they often get things wrong.
GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.
GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.
GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.
@[email protected] @[email protected] No, these devices don’t receive proper security patches from day one. They get incomplete patches with significant delays, and years of delays for the full security patches.
With the example of Fairphone, they ship the Android Security Bulletin backports with a 1 or 2 month delay. They don’t ship monthly or quarterly releases, so they miss all those patches. The yearly updates get shipped with at least 1 year of delay, so they can’t ship the current monthly and quarterly releases without fixing that first. The delays get longer as the devices get older, until the point it’s multiple years with the delays portrayed as providing longer support.
@[email protected] With the example of Fairphone, they ship the Android Security Bulletin backports with a 1 or 2 month delay. They don’t ship monthly or quarterly releases, so they miss all those patches. The yearly updates get shipped with at least 1 year of delay, so they can’t ship the current monthly and quarterly releases without fixing that first. The delays get longer as the devices get older, until the point it’s multiple years with the delays portrayed as providing longer support.
For both Android and iOS, only the latest OS release receives full security patches. Android backports more than iOS to older releases, but it’s only the High and Critical severity patches. Nearly all Moderate and lower severity patches aren’t backported including most privacy fixes.
Each month, there’s a new Android release. The monthly security patches are the incomplete backports, not the latest release. Non-Pixel OEMs only ship the incomplete backports at best right now.
Many Android OEMs commit to providing long term security support but don’t follow through on it or do it very poorly. As an example, Fairphone ships the partial security patch backports with 1-2 months of delay and the rest of the patches with up to a year of delay for a new device and longer as the device gets older. They portray shipping updates in 2022 which were released in 2020 as providing 2 more years of support than their competitors. It shouldn’t be challenged more.
GrapheneOS fully supports hardware-based attestation. Google is entirely capable of verifying a device runs the genuine GrapheneOS releases:
https://grapheneos.org/articles/attestation-compatibility-guide
Play Integrity API has nothing to do with security regardless of how it’s marketed. It allows a device to pass if it hasn’t received security patches for 8 years. All it does is check if it’s a Google certified device and tries to stop spoofing within constraints of allowing highly insecure, ancient devices to pass.
> would love to see GrapheneOS develop further and be properly allowed to pass play integrity API.
We fully preserve the privacy/security model and then substantially improve it. We use all of the same hardware-based security features as the stock Pixel OS but also a lot more including MTE (hardware memory tagging), PAC/BTI for userspace too, hardware-level disabling of new USB connections, USB data and the overall port for our USB-C port control feature and other features.
@daedaevibin It’s not a partition. It gets flashed to the secure element via an API provided by the secure element. The fastboot firmware implemented support for flashing it via the image flashing interface. There’s also not actually a bootloader partition but rather those are containers with images nested inside. There a whole bunch of boot firmware images flashed to separate partitions from bootloader.img. An over-the-air update has them as separate images, not bundled into the bootloader.img.
@[email protected] We do provide direct downloads, which are available at https://grapheneos.org/releases#devices. Our CLI install process is documented at https://grapheneos.org/install/cli. The install zip is used for both CLI and web install. It includes the verified boot public key. There’s no reason to make people flash it by hand with an extra command, we just flash it after flashing all the firmware and OS images.
@daedaevibin It’s included in the installation zip and flashed by either the web installer or the command-line flashing script included inside of the zip (flash-all.sh). We previously added the AVB public key to the standard factory images zip format but we recently moved to our own improved install zip format which we generate by converting factory images. Our own format is more efficient and allows installing significantly faster while using less memory and storage, that’s all.
> It seems to be a more efficient way to get it into the system for verification properly instead of other methods I’ve seen.
There is no other way to flash a key to the secure element for verified boot. That is how verified boot is implemented for an alternate OS. Both of our install processes flash the verified boot public key after flashing the OS. We were the first ones to ever use this functionality before they had official documentation, and we made the initial AOSP docs.
GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.