@crepererum@mastodon.online It's now better than it was before Android 13 because the Finalizing step goes much faster meaning you can get updated to the new version very quickly and then the post-boot compilation takes care of most of the work in the background at low priority.
Only has to do work at boot if you install/update apps after Finalizing now. We also made it use 4 threads instead of 2 at boot and 2 threads instead of 1 for the post-boot background compilation so it goes faster now.
@crepererum@mastodon.online Android broke this in Android 13 so we developed our own approach for compiling the apps after booting. We were compiling them with speed-profile at boot and then speed after boot since speed takes far too long to do it during boot. Prior to Android 13, we were doing speed compilation in The Finalizing step. Since we have our post-boot background code implemented now, we switched to doing speed-profile in Finalizing with their new working code for it and speed post-boot.
This is the first release with our major new 2-factor fingerprint unlock feature covered here:
https://grapheneos.social/@GrapheneOS/113738455998741928
It also includes a major overhaul of our ahead-of-time compilation for apps to improve the user experience, a charge limiting toggle with bypass charging support, etc.
@evilcookies98@mastodon.stickbear.me It's simply this text file inside of a signed APK marked as hasCode="false" as a secure way to distribute updates for it with signing:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/blob/config-152/gmscompat_config
Vanadium Config is a similar system for distributing Vanadium content filters and feature flags inside of a signed hasCode="false" APK.
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.
@evilcookies98@mastodon.stickbear.me Updates are fully automatic and happen over-the-air. This release is still only in the Alpha channel and there's an unconfirmed issue report we need to check out before we begin pushing it out via the Beta channel. You're using the Stable channel right now so you don't immediately get the updates as soon as they're released. You get them after they go through Alpha and then Beta testing. Please read and about this.
@leifdavisson@ioc.exchange We've tried to work with several OEMs as a partner.
The largest one we tried to work with ended up deciding to make a badly secured Bitcoin-focused phone instead. It failed and they sold a large portion of their phone business to Google.
A startup we recently tried to work with ended up deciding to make a badly secured Solana-focused phone instead. It failed and their company is out-of-business now.
At least in the latter case, we think they could have succeeded with us.
@leifdavisson We already support every single device with both proper support for an alternate OS and a high level of security. Pixels are the only Android devices with a high level of security. Our official hardware requirements are listed at https://grapheneos.org/faq#future-devices and there are no other devices available providing these properties. It's not within our power to cause other Android OEMs to start caring more about security and alternate OS support so they improve both of those quite a lot.
@neurer@infosec.exchange The first and second points are probably intended changes in the Android 15 QPR1 user interface. Clock issues are a recurring upstream issue. This is a major new quarterly release with quite a lot of changes to the UI so not everything is meant to be the way it was before.
@Trebr63@mastodon.social See if you're experiencing an issue with themed icons on Android 15 QPR1. That's not GrapheneOS specific.
@Trebr63@mastodon.social No, someone else is going to make an application eventually and we can fork it.
@crepererum@mastodon.online Installing the update and finalizing it happens at very low priority, as does the background compilation. Using 2 threads shouldn't hurt usage of the device significantly more since it's low priority. We could make it even lower priority if needed.