@jcs The definition of openness used by Librem 5 is that a fully closed source device with closed source firmware and software would be open and freedom respecting as long as none of the firmware/software can be updated.

Purism prevents updating firmware for the SoC and calls it open even though the SoC is fully closed source hardware and does have closed source firmware, which just can’t be updated. They don’t count secondary components like radios. 99.999% closed source hardware isn’t open.

@jcs Librem 5 has atrocious privacy and security due to using a bunch of low security and outdated components, which are not open and do not have open firmware. Many components including the radios lack proper security updates. Purism does not provide the firmware updates through their OS and has set up a bunch of it in a way where it can’t be updated. They even went out of the way to move things to a locked down secondary processor to block updates. They claim if you can’t update it, it’s open.

@jcs Librem 5 has a fully closed source SoC, which means System on a Chip as opposed to a traditional desktop where the components would be part of a motherboard. The board schematics are for a basic PCB. It’s a nearly entirely closed source device in terms of where the actual complexity is. The SoC is the core component providing nearly all the base functionality. The SSD, memory, touchscreen, battery, Wi-Fi, Bluetooth, cellular, etc. are all closed source, as are various other chips, etc.

@informapirata @informatica It would not be the end of F-Droid, it would only require them to stop incorrectly using package names (application ids) not belonging to them. F-Droid doing that already causes issues and we’ve reported it as an issue many times for several years. Simply doing domain-based verification without ID verification similar to Let’s Encrypt would have caused problems for them too unless developers authorized the usage explicitly.

See our post at https://discuss.grapheneos.org/d/26966-f-droids-delevoper-statements-about-googles-registration/3.

@andreabont @informapirata @morrolinux @gnulinuxitalia We only recommend that apps already using the Play Integrity API and unwilling to remove it move to using this instead. This enables them to support arbitrary other devices and operating systems. Other attestation roots can be supported along with arbitrary alternate operating systems via allowing their verified boot keys. That’s much better than the Play Integrity API. We’d prefer if apps didn’t check the device/OS but they insist on it.

@[email protected] What we changed is that the OS will now set the clock when it’s off by 50ms or more instead of 2000ms or more. When the device is powered on, the clock should not get out-of-sync by more than around 50ms per day unless the hardware is broken. It sounds like you have a hardware issue and that’s not going to be addressed by this. It shouldn’t be necessary for it to need to synchronize very frequently, only at boot and then around once a day afterwards.

@shiva @informatica @informapirata We don’t think these are good recommendations for users who care about privacy and security. There’s a lot more to privacy than simply avoiding Google apps/services.

We recommend https://eylenburg.github.io/android/_comparison.htm for a high quality comparison between Android-based operating systems. The other OSes listed there do not keep up with privacy/security patches which is the bare minimum. CalyxOS updates have also recently been discontinued as a whole (https://calyxos.org/news/2025/08/01/a-letter-to-our-community/).

deleted by creator

@[email protected] Yes, you can configure the channel for each app in the App Store via the menu in the upper right.

This is also an Early Stable release of Chromium so we’re rolling it out more slowly than normal releases. You can see the Chrome rollout percentage here:

https://chromiumdash.appspot.com/releases?platform=Android

0.25% of Chrome users are receiving the update to 139.0.7258.62. 99.5% are on 99.5% and another 0,.25% are receiving 138.0.7204.180 which is the same as 138.0.7204.179 and acts as a control for stats.

deleted by creator

@[email protected] Yes, changes are present there prior to tagging a release. However, there are some issues we need to resolve with the new VPN leak prevention changes causing some app crashes, etc. The approach is correct but there were some implementation bugs. The latest release was cancelled due to this and was only released to Alpha where it’s no longer available.

deleted by creator

@[email protected] The release is tagged prior to the release being announced.

@[email protected] We hadn’t added it to external/GmsCompatConfig yet. It’s there now.

@[email protected] The bundled apps built separately from the OS are updated in the next OS release but they get updated out-of-band via App Store. TalkBack is an exception since we haven’t bothered to start signing it with a dedicated key and distributing it via App Store. They do not regularly release sources for it and their sources have bugs not present in their official releases so there isn’t a great starting point for it.

deleted by creator

@[email protected] It’s because the pre-boot compilation happens in the background after Finalizing completes instead of it waiting until it’s done before it completes. It was a change in Android 16 upstream. It causes GrapheneOS to compile apps during boot if it wasn’t finished pre-boot because we solely ahead-of-time compilation for security reasons instead of in-memory just-in-time compilation.

@[email protected] Booting can take significantly longer since moving to Android 16 likely due to some kind of new quirk with the pre-boot recompilation of apps.

@[email protected] Every release in the Stable channel previously went through Alpha and then Beta. This release is on the way to Stable but needs more testing.

@lusca @ElysianEve We plan to overhaul Contacts, Phone and Messaging overselves. Calculator, Gallery and Clock could be replaced.

Camera is one of our apps rather than an AOSP app and we have massive improvements pending but need to focus on fixing Android 16 regressions and other high priority work before merging those improvements and doing a release.

PDF Viewer is our own app with significant improvements under way, but as with Camera it needs to wait for higher priority work to get done.