Salta al contenuto principale


GrapheneOS based on Android 16 has been through extensive public Alpha/Beta testing and should reach our Stable channel today. We'll continue fixing various upstream Android 16 regressions such as the back button issue impacting the stock Pixel OS we fixed in our latest release.

reshared this

in reply to GrapheneOS

I wonder why the cooperation between the grapheneOS developers and Google is not better. Graphene also fixes bugs in the Google OS
in reply to SmarTekk

@andree4live Their security team wants to collaborate more. Their business side has interfered and blocked it because we aren't an Android OEM and it's not how they do things. It isn't due to their business side having any particular issue with us, we just don't fit into what they see as their business model. Many Pixels have been purchased to use GrapheneOS and they don't seem to realize that's a perfectly good business. GrapheneOS also doesn't stop people using Google apps/services anyway.
in reply to GrapheneOS

@andree4live GrapheneOS puts Google apps and services on an equal playing field with other apps where they don't come included with the OS and have no extra access or control over the device if people install them. Their business side doesn't actually have any issue with this. Their issue with collaboration with us is that we are not an Android OEM licensing Google Mobile Services and therefore do not fit into their narrow idea about what their Android business model is.
in reply to GrapheneOS

July Android Security Bulletin will likely be published today. We obtained early access to the signed partner preview and confirmed no additional patches were required, so we set the 2025-07-01 patch level last month after we backported Pixel 2025-06-05 driver/firmware patches.
in reply to GrapheneOS

Tomorrow will likely be the first monthly update of Android 16 with a new Android Open Source Project and Pixel stock OS release. We won't need to backport Pixel driver/firmware patches since we're on Android 16 and can simply incorporate and ship the monthly update within hours.

reshared this

in reply to Daniel Lakeland

@dlakelan You can see the Pixel 9a is included in all of the Android 16 releases at grapheneos.org/releases#change… and that it has Android 16 available in Alpha and Beta at grapheneos.org/releases#device…. It has been there since our first Android 16 release. It was only separate from the other devices before Android 16 because it launched with a special device branch based on Android 15 QPR1 instead of Android 15 QPR2. It's also why we couldn't backport as much to it from Android 16 as the other devices.
in reply to GrapheneOS

@dlakelan The initial couple months of Pixel 9a support prior to Android 16 were essentially a preview for the stock Pixel OS and Android Open Source Project. It wasn't the latest Android release used on other Pixels. They backported the Android and Pixel security bulletin patches to Android 15 QPR1. It's a weird way of doing things and they previously did the same with the Pixel 8a where it had Android 14 QPR1 instead of Android 14 QPR2 until Android 14 QPR3 was released (there's no 15 QPR3).
in reply to GrapheneOS

Well i guess I'm gonna switch to beta channel for now then, been having some battery issues and the per app battery usage is known not to work on the 15 release so I'll beta test for a little while.
in reply to Daniel Lakeland

@dlakelan We plan on releasing Android 16 to the Stable channel for the Pixel 9a very soon, prior to the other devices. We want to get rid of the problematic Android 15 QPR1 device branch as soon as possible. You might as well temporarily switch to Beta because we're very close to putting it into Stable anyway. People have done extensive testing for it already and it works fine. The remaining reported regressions are minor and there are far more bug fixes than new bugs in Android 16.
in reply to GrapheneOS

Will do. Once I'm on beta and android 16 is released to stable, can I switch channels back to stable? Or is that problematic because of downgrade?
in reply to Daniel Lakeland

@dlakelan You can switch back to Stable immediately. It only determines how quickly you get the production releases. The releases we publish via Alpha, Beta and Stable are the same. They're all production releases and are simply shipped out to users who use Alpha before Beta which is before Stable. If you switch back to Stable, you'll just receive the next production release when it reaches Stable. This current release should reach Stable and it'll be no different if you wait or not.
in reply to GrapheneOS

@dlakelan Our release channel system is just how we roll out a production release to a small subset of users, then a larger subset and finally all of our users. We let people opt-in to getting it sooner to help with testing. It's the same thing regardless of which channel you use. Releases don't proceed past Alpha or Beta if significant issues are found we want to fix before the next channel. That's all. Nothing that's a blocker for Stable channel has been reported yet so it'll go there soon.
in reply to GrapheneOS

Sweet! thank you for your explanations. your scheme makes good sense!
in reply to GrapheneOS

yes exactly how I think. Thank you guys for work, im supporting you on github.
in reply to GrapheneOS

It can be extraordinarily difficult to backport driver/firmware patches due to dependencies on the new major release. We were only able to backport everything required for the 2025-06-05 security patch level because Android 15 QPR2 is much closer to Android 16 than Android 15.
in reply to GrapheneOS

After our Android 16 port was completed yesterday, we started fixing an Android tapjacking vulnerability disclosed last month:

taptrap.click

We have a fix implemented and it will be included in our next release, likely with the monthly Android 16 update tomorrow.

Questa voce è stata modificata (2 mesi fa)
in reply to GrapheneOS

This vulnerability was disclosed to Google in October 2024 and Android still hasn't fixed it. Security researchers should report vulnerabilities to GrapheneOS in addition to Google. This now joins our many other GrapheneOS exclusive fixes for serious Android vulnerabilities.
Questa voce è stata modificata (2 mesi fa)
in reply to GrapheneOS

and Google doesn't allow you to merge those fixes to AOSP, right?
Did GrapheneOS actually contribute to AOSP in the past?
Edit: there is an android documentation page that says one can contribute to AOSP but I have read somewhere that they made all of their development private. Maybe I am wrong.
Questa voce è stata modificata (2 mesi fa)
in reply to Farshid Hakimy / فرشید

@farshidhakimy

> and Google doesn't allow you to merge those fixes to AOSP, right?

We heavily contributed to upstream projects including AOSP in the past but have largely stopped doing so due to poor treatment.

> Did GrapheneOS actually contribute to AOSP in the past?

Yes, significantly, despite how hard they made it. Our main contributing was reporting issues and providing solutions in direct contact with engineers because they make it very difficult to submit and get changes merged.

in reply to GrapheneOS

any chance you (or others) would be willing to explain roughly how one would go about mitigating something like this? Do you restrict the ability of the app to use custom animations or display settings?
in reply to fractal_timescales

@fractal_timescales For user installed apps, we limited custom activity transition animations to transitions between activities provided by the app.
in reply to Demi Marie Obenour

@alwayscurious They will fix it, but they don't tend to take these kind of UI vulnerabilities very seriously. They may not have classified it as High severity as they should have. It may have been classified as Moderate severity and therefore not being fixed as quickly as they can for a vulnerability they determine is serious. They do often take a long time to fix issues, especially ones like this where the simple way to fix it involves disabling part of an aesthetic feature as we did.
in reply to GrapheneOS

We've decided to make another release today with our fix for the Android tapjacking vulnerability because we need to fix a DisplayPort alternate mode regression specific to 8th generation Pixels which doesn't impact 9th generation Pixels.
in reply to GrapheneOS

Ping: @lindorferin @minimalblue
Have you considered disclosing vulnerabilities to GrapheneOS in addition to Google?

Unrelated feedback: it would be nice if your Mastodon profiles would be listed on taptrap.click/#team along proprietary services.

in reply to elgregor

@elgregor @lindorferin That's awesome, so glad to see you took the vulnerability seriously and included a fix into GrapheneOS. We will update the taptrap website accordingly and certainly consider testing GrapheneOS in upcoming research. Also thanks for the unrelated feedback, we're gonna list the profiles there too 😀
in reply to Marco Squarcina

@minimalblue @elgregor @lindorferin

Also from my side, very nice to see GrapheneOS taking TapTrap seriously. Many thanks for the fix!

in reply to Philipp Beer

@beerphilipp @minimalblue @elgregor @lindorferin We only became aware of the issue a few days ago and needed to finish our high priority port to Android 16 first. It's now dealt with in the straightforward way of disabling the transition animations unless they're between the app's own activities. You can see the change listed here:

grapheneos.org/releases#202507…

We would have fixed it earlier if we were aware since from our perspective it's quite serious and far worse than most similar problems.

in reply to GrapheneOS

@beerphilipp @minimalblue @elgregor @lindorferin Here's the fix we implemented:

github.com/GrapheneOS/platform…

It wasn't particularly hard to fix with this approach and there are few downsides. It doesn't seem important for apps to be able to have custom animations for transitions to activities which aren't part of themselves. We can switch to a 'better' fix they implement later and drop this if it's no longer useful but we're fine with this.

We know a lot more UI security improvements are needed.

in reply to GrapheneOS

Will the Android 16 update be delivered just like a normal one or will there be a special process? Sorry, newish user who came from iOS and its my first time jumping major versions.
in reply to heliumlake

@heliumlake It's a normal update and you don't need to do anything special. It has been available in the Alpha channel for a while now and the past couple releases in the Beta channel too. It's in the Stable channel for the Pixel 9a already, but we aren't in a rush for the other devices and want to fix all the major issues before it reaches Stable.
in reply to GrapheneOS

Wonderful! Thanks for all you do and I will patiently wait for it to drop on the stable channel.
in reply to GrapheneOS

is there any known regression concerning NFC payments? Version is 2025070500 on the beta channel.
in reply to GrapheneOS

huh, weird. guess it's a problem with the banking app then. appreciate the reply!
in reply to curopean omission

@silhouette Banking apps often do very misguided things and tend to have poor code quality. Their app may simply be broken on Android 16 due to using private APIs. You should check the app's reviews and discussion about it elsewhere to see if people on the stock Pixel OS are having issues too. Bear in mind other OEMs take a while to update to new Android versions and some app developers use private APIs combined with not testing the Android Beta releases or even new major stable releases.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@davidlove

> Does this suggest that Android 17 will be even more difficult?

No, quite the opposite. We did the work of dealing with AOSP no longer having Pixel device trees. It will be much easier going forward than it was for Android 16. We're going to continue working on improving the automation to prepare for future releases to make it easier.

> Is there anything we can do to help support upcoming efforts?

People can donate and defend the project against ongoing misinformation attacks.

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@ElysianEve The update system checks for updates automatically approximately every 6 hours but you can do manual checks. You can see what's in each release channel at grapheneos.org/releases#device…. Due to the port to Android 16 and needing to finish fixing all major issues, the past several releases have not made it to the Stable channel. If you don't use DisplayPort alternate mode on 8th gen Pixels, there are no other known major issues with the current release in the Beta channel.
in reply to GrapheneOS

Earlier you said you maybe needed to postpone porting a few features (such as second factor authentication, if I remember correctly). Is that still the case, or is everything ported now?

(Just so I know what will happen after I reboot after the update. You are amazing nonetheless.)

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS

@ElysianEve It's a standard Android feature where we didn't choose the woridng. Toggle it on to disable using 2G networks. See here:

source.android.com/docs/securi…

Note that if you use our added 4G only mode, 4G/5G only mode or 5G only mode then 2G will be disabled too, along with more being disabled.

Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@ElysianEve 4G and 5G are the standard ones meaning "4G and below" and "5G and below". What we add are "4G only", "4G or 5G only" and "5G only". If your carrier doesn't support standalone 5G, "5G only" isn't shown as an option. 4G is called LTE for most carriers. 5G is also known as NR but is usually called 5G.
in reply to Gwenn

@gwenn Fairphone's devices don't meet our security and update requirements. Their current devices won't ever be supported and near future devices over the next several years from them are very unlikely to meet our requirements.
in reply to GrapheneOS

Großartig! Vielen Dank für eure Arbeit am besten Android-BS wo gibt! Ich möchte gar nichts anderes mehr nutzen…