GrapheneOS version 2023031300 released

GrapheneOS

GrapheneOS version 2023031300 released: https://grapheneos.org/releases#2023031300.

See the linked release notes for a summary of the improvements over the previous release.

James80

I'm still on the 0400 release the new one from today is not installed yet even if I tap on update....?

Relaks

James80 It's not in stable channel yet.
https://grapheneos.org/releases#stable-channel

[deleted]

Relaks release announcement is just before published in alpha channel

Shiny_Opal

[deleted] well that sucks, but it explains why I also couldn't update yet lol

[deleted]

Shiny_Opal sucks? is the normal behavior on GrapheneOS.

Grkrz

Shiny_Opal you can jump to alpha if you want ,so you will get it right away.

Oggyo

Shiny_Opal
For me, the recent release (2023031500) changelog proves why this method doesn't suck and even the opposite - looks more professional:

adevtool: remove overlay setting config_systemBluetoothStack to the wrong value (caused Bluetooth to break for users with exec-based spawning disabled, which is why the previous release only made it to Beta and not Stable)

gosrox

[deleted] it sucks because it is stupid. GrapheneOS is literally the only software in the entire world that uses "released" for alpha and beta software lol. Alpha and beta != released. released = gold.

ve3jlg

gosrox Agreed.

[deleted]

gosrox other OS and ROMs not are publishing alpha/beta versions or are internally published or alpha/beta versions follows a different path than stable builds. GrapheneOS doesn't works like that. Maybe you should do some reading on how the system works before you say it sucks...

dmzee

Did Bluetooth break for anyone? All my devices flap continuously connecting and disconnecting with the Bluetooth process eventually crashing.

`type: crash
osVersion: google/cheetah/cheetah:13/TQ2A.230305.008.C1/2023031300:user/release-keys
package: com.android.bluetooth:33
process: com.android.bluetooth
processUptime: 5329 + 57 ms

java.lang.SecurityException: Bluetooth is the only caller allowed
at android.os.Parcel.createExceptionOrNull(Parcel.java:3021)
at android.os.Parcel.createException(Parcel.java:3005)
at android.os.Parcel.readException(Parcel.java:2981)
at android.os.Parcel.readException(Parcel.java:2923)
at android.media.IAudioService$Stub$Proxy.handleBluetoothActiveDeviceChanged(IAudioService.java:5306)
at android.media.AudioManager.handleBluetoothActiveDeviceChanged(AudioManager.java:5966)
at com.android.bluetooth.a2dp.A2dpService.setActiveDevice(A2dpService.java:636)
at com.android.bluetooth.btservice.ActiveDeviceManager.setA2dpActiveDevice(ActiveDeviceManager.java:677)
at com.android.bluetooth.btservice.ActiveDeviceManager.-$$Nest$msetA2dpActiveDevice(Unknown Source:0)
at com.android.bluetooth.btservice.ActiveDeviceManager$ActiveDeviceManagerHandler.handleMessage(ActiveDeviceManager.java:251)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.os.HandlerThread.run(HandlerThread.java:67)`

unwat

dmzee

There's an open issue for this.

https://github.com/GrapheneOS/os-issue-tracker/issues/2020

matchboxbananasynergy

dmzee This is fixed in the newest release.

Grkrz

Sometimes the finger scanner is not acting as intended ,for instance after reboot I thought my fingers were removed and the whole function . I was thinking that because the picture of were you put your finger not appeared.
I know the first time after reboot you have to type pin , i am thinking here about second attempt, after tying the pin first time.
Overall the performance of finger print improved.
Regarding Bluetooth issue hanvent tried yet

GrapheneOS

[deleted] The stock Pixel OS uses staged rollouts, as do most Google apps and many non-Google apps on the Play Store. For the OS, they start with the update deployed to 0% of users automatically and then ramp it up from there. Once it goes above 0%, a random percentage of users receive it automatically. Manually checking for updates bypasses the staged rollout. Our approach avoids the randomization and instead users choose a release channel to choose how early they want to release the new production releases. The releases we push out via the Alpha and Beta channels are production releases, not Alpha or Beta releases. We don't push out non-production experimental releases to users automatically.

brookie229

Wow - waiting a whole 2-3 days for an update after the announcement - must be total hell! //s

GrapheneOS

brookie229 It's usually available in the Alpha channel within minutes of the announcement, then the Beta channel within hours and the Stable channel within around 16 to 24 hours. This release (2023031300) had a major issue discovered for users with exec-based spawning disabled causing Bluetooth to break. It was discovered once the release was in the Beta channel. This is why we have these release channels instead of releasing directly to all users at once. We prefer having users choose how quickly they want to receive the updates instead of randomizing it like the stock Pixel OS and Google Play Store. Both our OS update system and our app repository use this approach. If you want releases faster, then use the Beta channel. The only difference is that you receive the releases sooner than the Stable channel. They're the same releases and there aren't Alpha or Beta specific releases. Even when using the Alpha channel, you're only receiving production builds that are intended to get to the stable channel but we want public testing before any release gets there. We just saved a lot of users from having their Bluetooth broken with this approach. The stock Pixel OS is still in the early stages of their rollout and we've released the subsequent release to all our users in the stable channel. Quarterly release being rolled out to 100% of users on Wednesday when it was released on Monday for the stock OS and AOSP is very fast. It will take weeks for the stock OS to reach 100%. They're currently at a much lower rollout percentage.

GrapheneOS

@Shiny_Opal @gosrox @ve3jlg You're wrong about how we do releases. The release notes published at https://grapheneos.org/releases#changelog are for stable production releases and they're immediately available from the update server when the release notes are published via the non-automatic testing channel. They're pushed out via the Alpha channel, then the Beta channel and finally the Stable channel. The stock Pixel OS also uses a staged rollout system for stable releases too, but they do it based on a random percentage and manually checking for an update bypasses the staged rollout. We essentially do the same thing with more user control. Play Store encourages developers to do the same thing we do by using internal and open testing channels followed by promoting the release to production. They encourage never releasing directly to the production channel. They also offer randomized staged rollouts. Many developers use the same approach as we do for their Play Store app releases. Staged rollouts are widely used, and we just prefer having it be entirely an explicit user choice about which rollout stage they get instead of it being randomized.

brookie229

Your sarcasm detector must be malfunctioning - I was being sarcastic (hence the \s at the end of my post) to the op. The update system implemented by GOS is superior to ANYTHING I've ever seen. Good job! Oh, and I prefer the stable releases :)