Experimental release of GrapheneOS for Pixel 9a(grapheneos.social)
grapheneos.social
Experimental release of GrapheneOS for Pixel 9a
https://grapheneos.social/@GrapheneOS/114327666433966529
265 comments
I love GrapheneOS. The biggest downside is that Google integrity API block wireless payments in Google Pay. All Dutch banks now advertise to install Google pay for wireless payments.
I've tried asking Google to support GrapheneOS but they told me to do a feature request. Which I did and got no reply to. I've contacted the consumer market authority and made a formal complaint since Google and Apple share effectively a contactless payments duopoly and decide which OS distributions get access. Those are closed source and usually bundled with a lot of spyware. I also explained how the Google integrity API might affect banking availability in the future (and already does for some banking apps). They took it very seriously and I hope to hear from them in the future.
You can use Curve Pay for tap-to-pay on GrapheneOS in most of Europe including in the Netherlands. It also works in the UK, not just the EU. It unfortunately hasn't launched in the US yet.
Some of those banks may also still support using their own tap-to-pay. Europe has a standardized system for it and many banks support it. Check https://privsec.dev/posts/android/banking-applications-compa... for those banks. There was a major shift to using Google Pay to reduce their development costs but there may be a major shift away from it now.
https://grapheneos.org/articles/attestation-compatibility-gu... should be sent to companies banning using GrapheneOS via the Play Integrity API. They can keep doing that while permitting GrapheneOS in a more secure way. Our users recently convinced several banks to implement it. Swissquote implemented it for their Yuh app and will hopefully do it for their main Swissquote app soon. It would be nicer if they didn't add Play Integrity API in the first place but progress can be made if users leave lots of reviews, support requests, etc. until they realize it's a big issue and either remove it or implement this as a replacement.
Some of those banks may also still support using their own tap-to-pay. Europe has a standardized system for it and many banks support it. Check https://privsec.dev/posts/android/banking-applications-compa... for those banks. There was a major shift to using Google Pay to reduce their development costs but there may be a major shift away from it now.
https://grapheneos.org/articles/attestation-compatibility-gu... should be sent to companies banning using GrapheneOS via the Play Integrity API. They can keep doing that while permitting GrapheneOS in a more secure way. Our users recently convinced several banks to implement it. Swissquote implemented it for their Yuh app and will hopefully do it for their main Swissquote app soon. It would be nicer if they didn't add Play Integrity API in the first place but progress can be made if users leave lots of reviews, support requests, etc. until they realize it's a big issue and either remove it or implement this as a replacement.
icard NFC payments also work fine
> All Dutch banks now advertise to install Google pay for wireless payments.
That sounds like a very big mistake to me. And a missed opportunity: in some countries, banked work together to develop their own systems. People can send money to each other and pay everywhere with a small app that is not BigTech from the US.
I think there should be such an app in every country; you don't want your payment system to fully depend on US companies.
That sounds like a very big mistake to me. And a missed opportunity: in some countries, banked work together to develop their own systems. People can send money to each other and pay everywhere with a small app that is not BigTech from the US.
I think there should be such an app in every country; you don't want your payment system to fully depend on US companies.
Dutch banks did this, it is called iDeal: https://www.ideal.nl/en/
iDeal is ubiquitous in The Netherlands for individuals sending money to each other, and for online payments. However it does not support NFC payments in physical stores. Dutch banks decided to go with Google/Apple wallet for this. I believe in the longer term Wero https://wero-wallet.eu/ (and potentially the digital euro https://www.ecb.europa.eu/euro/digital_euro/html/index.en.ht...) is supposed to take over this usecase in the EU.
iDeal is ubiquitous in The Netherlands for individuals sending money to each other, and for online payments. However it does not support NFC payments in physical stores. Dutch banks decided to go with Google/Apple wallet for this. I believe in the longer term Wero https://wero-wallet.eu/ (and potentially the digital euro https://www.ecb.europa.eu/euro/digital_euro/html/index.en.ht...) is supposed to take over this usecase in the EU.
That sounds good! Instead of NFC, they could use QR codes. All the payment terminals can show a QR code, and it's even possible to print a QR code on a piece of paper without the need for the terminal.
Twint does that. They started trying to make it "seamless" with NFC, but couldn't do it because of Apple (maybe now with the DMA it may change) and went for some kind of weird bluetooth stuff. Nobody used it. Then they moved to QR codes, and it quickly got very popular.
Everybody understands QR codes. No need to know whether your phone supports NFC or not, no need to go check if NFC is enabled in the settings, nothing. Everybody understands that they need to scan the QR code with their camera, period. Seems perfect to me.
Twint does that. They started trying to make it "seamless" with NFC, but couldn't do it because of Apple (maybe now with the DMA it may change) and went for some kind of weird bluetooth stuff. Nobody used it. Then they moved to QR codes, and it quickly got very popular.
Everybody understands QR codes. No need to know whether your phone supports NFC or not, no need to go check if NFC is enabled in the settings, nothing. Everybody understands that they need to scan the QR code with their camera, period. Seems perfect to me.
> they could use QR codes
It already does for web purchases, so there is no reason it could not. Not sure why this is not more commonplace.
It already does for web purchases, so there is no reason it could not. Not sure why this is not more commonplace.
Banks do that for p2p payments and e-commerce (like iDeal mentioned by sibling comment or BLIK in Poland).
For physical transactions there's barrier of hardware and network effect - everybody has card terminal. Users expect near 100% acceptance for them to use payment method daily.
If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible, but more expensive and often disliked by the users due to inability to easily switch between cards issued by different apps.
For physical transactions there's barrier of hardware and network effect - everybody has card terminal. Users expect near 100% acceptance for them to use payment method daily.
If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible, but more expensive and often disliked by the users due to inability to easily switch between cards issued by different apps.
As mentioned in the sibling comment, Twint goes with QR code. It just works.
It's even better than NFC because a small store can print their QR code on a piece of paper and not need to buy a terminal. Most stores just have the normal card terminal print the QR code and people scan it.
It's even better than NFC because a small store can print their QR code on a piece of paper and not need to buy a terminal. Most stores just have the normal card terminal print the QR code and people scan it.
NFC, for payments, has bidirectional communications and limited scope for MITM. It's a bit too easy to cover a sticker.
The TWINT app says -- if their promo videos are to be trusted -- "Scan only QR codes from trusted sources and check the receiver of the payment in the next step". That doesn't fill me with confidence :(.
A dynamic QR code could be fine -- they have their app, you're able to bootstrap what is effectively a secure channel between the PoS machine and the app to give the vendor confidence their device has received payment and the consumer confidence that they're paying the right vendor. A static QR code is more challenging, and it sounds like they're putting more weight into social protections than I'm comfortable with -- especially considering a technical solution is possible and exists.
I'm especially wary of the warning that individuals can't have QR codes. Why not? Unless it's part of the social protection. But I can personally accept NFC contactless payments (having opened an account with a suitable provider), and indeed I bought a device which means I can accept chip and PIN payments too.
The TWINT app says -- if their promo videos are to be trusted -- "Scan only QR codes from trusted sources and check the receiver of the payment in the next step". That doesn't fill me with confidence :(.
A dynamic QR code could be fine -- they have their app, you're able to bootstrap what is effectively a secure channel between the PoS machine and the app to give the vendor confidence their device has received payment and the consumer confidence that they're paying the right vendor. A static QR code is more challenging, and it sounds like they're putting more weight into social protections than I'm comfortable with -- especially considering a technical solution is possible and exists.
I'm especially wary of the warning that individuals can't have QR codes. Why not? Unless it's part of the social protection. But I can personally accept NFC contactless payments (having opened an account with a suitable provider), and indeed I bought a device which means I can accept chip and PIN payments too.
Multiple things here.
* The vast majority of the payments (almost all of them) are done with dynamic QR codes.
* The static QR code is mostly used by very, very small entities. Like the person asks you to scan their code, enter the amount and show them the confirmation. It is in their interest to show the right QR code.
* Sending money to a friend is done with the phone number as an id. It works, but you need to enter the mobile phone number of the receiver.
* There is one situation where static codes are printed and where phishing has been reported (it's not MITM, it's really just a QR code that sends you to a bad website): when paying for parking. You don't have to use it if you don't feel comfortable, and it is possible to feel comfortable because it actually just opens a website (so if you use it regularly you can learn to check that you are on the legit website before you make the payment).
Overall, it is super popular and it works really well. No need for NFC, and no need to install the Google Play Services \o/.
* The vast majority of the payments (almost all of them) are done with dynamic QR codes.
* The static QR code is mostly used by very, very small entities. Like the person asks you to scan their code, enter the amount and show them the confirmation. It is in their interest to show the right QR code.
* Sending money to a friend is done with the phone number as an id. It works, but you need to enter the mobile phone number of the receiver.
* There is one situation where static codes are printed and where phishing has been reported (it's not MITM, it's really just a QR code that sends you to a bad website): when paying for parking. You don't have to use it if you don't feel comfortable, and it is possible to feel comfortable because it actually just opens a website (so if you use it regularly you can learn to check that you are on the legit website before you make the payment).
Overall, it is super popular and it works really well. No need for NFC, and no need to install the Google Play Services \o/.
I'm sure it does work really well -- the social dynamics are there, it's obviously easy to use. That doesn't mean I have to like the technical characteristics.
A counter-point might be that my credit card doesn't require Google Play Services either. And won't run out of battery. And works with all the local businesses, including the smallest -- while there are some people (mostly outside cities) who still only take cash, I can't imagine them signing up for TWINT either.
There are several providers of services allowing individuals and small traders to accept credit and debit cards, and I've happily accepted cards from foreign banks too.
I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.
A counter-point might be that my credit card doesn't require Google Play Services either. And won't run out of battery. And works with all the local businesses, including the smallest -- while there are some people (mostly outside cities) who still only take cash, I can't imagine them signing up for TWINT either.
There are several providers of services allowing individuals and small traders to accept credit and debit cards, and I've happily accepted cards from foreign banks too.
I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.
> That doesn't mean I have to like the technical characteristics.
I didn't say you have to like them. But if you claim they are insecure, I feel like it's my right to note that you may be wrong.
> A counter-point might be that my credit card doesn't require Google Play Services either.
That is not exactly a counter-point in a discussion between a mobile app doing NFC and a mobile app using QR codes, is it?
> I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.
That's another question. My original point was that non-US banks should not depend on Google Play Services or Apple Pay (which at least until very recently was the only way to pay with NFC on iPhones, wasn't it?).
I didn't say you have to like them. But if you claim they are insecure, I feel like it's my right to note that you may be wrong.
> A counter-point might be that my credit card doesn't require Google Play Services either.
That is not exactly a counter-point in a discussion between a mobile app doing NFC and a mobile app using QR codes, is it?
> I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.
That's another question. My original point was that non-US banks should not depend on Google Play Services or Apple Pay (which at least until very recently was the only way to pay with NFC on iPhones, wasn't it?).
> If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible
Is it? Last time I checked, Apple & Google were also interfacing with banks on the server side, i.e. banks had to integrate with Apple/Google specifically. I'd love to be wrong, though.
Is it? Last time I checked, Apple & Google were also interfacing with banks on the server side, i.e. banks had to integrate with Apple/Google specifically. I'd love to be wrong, though.
It's optional if you want "add to wallet button".
That's not related to ability to create own app - on both ios and Android you can access NFC hardware directly (on iOS it's limited geographically), and send card data as you see fit - Google & Apple do nothing in such case.
That's not related to ability to create own app - on both ios and Android you can access NFC hardware directly (on iOS it's limited geographically), and send card data as you see fit - Google & Apple do nothing in such case.
I believe that for a long time, Apple was preventing the use of NFC (or was it just for payments?). The EU Digital Markets Act is supposed to prevent them from doing that, as part of the "interoperability" part. And I think the DMA is great in that sense.
True, on iOS access to the NFC chip has been a additional blocker. But on Android apps have been able to use the NFC chip just fine and it's still not that easy to write a generic "wallet" app (that's compatible with all banks & cards), see my previous comment.
>But on Android apps have been able to use the NFC chip just fine
The last time I looked at it, it was not possible because Android doesn't let apps control the uid that gets used for NFC.
The last time I looked at it, it was not possible because Android doesn't let apps control the uid that gets used for NFC.
Ah right, good point. I did forget about that.
Either way, even if apps had full control over the chip, my understanding is that building a wallet app would still amount to much more than just interfacing with the NFC chip.
Either way, even if apps had full control over the chip, my understanding is that building a wallet app would still amount to much more than just interfacing with the NFC chip.
You need connection to card scheme, which means you need ton of paperwork, which means you need ton of money. That's biggest issue :-)
For technical side - there are companies selling complete SDKs.
For technical side - there are companies selling complete SDKs.
Could you elaborate? You seem like you know quite a bit about this topic.
While I've known that building a wallet is not as simple as configuring the NFC chip and one would have to interface with banks on the backend etc., I've failed to understand exactly why. What prevents a phone from emulating a regular physical credit card?
While I've known that building a wallet is not as simple as configuring the NFC chip and one would have to interface with banks on the backend etc., I've failed to understand exactly why. What prevents a phone from emulating a regular physical credit card?
On technical level - nothing. Thing is, that payment card is basically private key, that's derived from master key controlled by the bank. This key signs your transactions. Tokenization adds some extra steps (eg. single use keys), but it's fundamentally the same.
What it means - you cannot obtain working card profile if bank doesn't issue it to you. Therefore you need blessing from bank & card scheme to be connected to this ecosystem.
If you want to go deeper into this rabbit hole I can recommend two sources:
* https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization
* https://developer.verestro.com/books/token-requestor - actual solution. It focuses on offering for single issuer, because market for Google Pay competition is pretty narrow, but technically it's mostly the same + way more red tape.
If you ever decide to try - ping me, I happen to know a few guys there :-)
What it means - you cannot obtain working card profile if bank doesn't issue it to you. Therefore you need blessing from bank & card scheme to be connected to this ecosystem.
If you want to go deeper into this rabbit hole I can recommend two sources:
* https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization
* https://developer.verestro.com/books/token-requestor - actual solution. It focuses on offering for single issuer, because market for Google Pay competition is pretty narrow, but technically it's mostly the same + way more red tape.
If you ever decide to try - ping me, I happen to know a few guys there :-)
Thank you so much! That's very enlightening!
> If you ever decide to try - ping me, I happen to know a few guys there :-)
Ha, I have actually been entertaining that idea for quite some time, but it seems rather difficult to penetrate that domain as an outsider. The links you shared only seem to confirm that. :-\ I'm not sure I would even want to compete with the Google/Apple Pay duopoly, for now I'd mostly just be interested in an open-source, privacy-preserving solution for contactless payments.
Anyway, you might want to add your contact info to your HN profile – just in case. ;-)
> If you ever decide to try - ping me, I happen to know a few guys there :-)
Ha, I have actually been entertaining that idea for quite some time, but it seems rather difficult to penetrate that domain as an outsider. The links you shared only seem to confirm that. :-\ I'm not sure I would even want to compete with the Google/Apple Pay duopoly, for now I'd mostly just be interested in an open-source, privacy-preserving solution for contactless payments.
Anyway, you might want to add your contact info to your HN profile – just in case. ;-)
>What prevents a phone from emulating a regular physical credit card?
If this were possible fraudsters would be easily be able to clone people's cards by getting close to them. The protocol was explicitly designed for this to not be possible. There are secrets that live on the card itself and are not exposed
If this were possible fraudsters would be easily be able to clone people's cards by getting close to them. The protocol was explicitly designed for this to not be possible. There are secrets that live on the card itself and are not exposed
> The protocol
Aren't there several protocols? I understand NFC chips or the old-school "phone card" UICCs are probably quite difficult to clone but at least in the US swiping credit cards (+ physically signing the printout maybe) still seems to be quite common.
Aren't there several protocols? I understand NFC chips or the old-school "phone card" UICCs are probably quite difficult to clone but at least in the US swiping credit cards (+ physically signing the printout maybe) still seems to be quite common.
So a phone can totally emulate a regular physical credit card, if it has the private key.
Behaving like a credit card does not mean that the credit card is clonable.
Behaving like a credit card does not mean that the credit card is clonable.
Many NFC chip don't allow setting uid either, and none of the EMV card require cloning uid
Generally what you're describing is in countries that don't have widespread adoption of NFC payments. In Europe almost every country has standardised NFC payments so Apple/Google Pay is the most frictionless option for users.
Switzerland (which is not a country that doesn't know how to do banking :-) ) uses Twint (a Swiss app) with QR codes instead of NFC. To me it's better than NFC (it works with printed QR codes, e.g. on parking payment machines).
I don't know anyone in Switzerland using Apple/Google Pay, which IMO is a national success.
I don't know anyone in Switzerland using Apple/Google Pay, which IMO is a national success.
Switzerland is very backwards on retail banking actually. For example money transfers between bank accounts cost money, aren't instant, and can't be done on weekends.
I agree, but in this banking apps (around me) use the Integrity API anyway.
Thanks for doing that. I tried GrapheneOS a few years ago in the states, and the bank thing wasn’t a huge problem (just carry rfid cards because there’s no google pay/apple pay).
The bigger problem came from apps that threw null point exceptions on startup when probing for google play crap.
The following failed for at least one week over a two month period: parkmobile, multiple ev charging networks, uber, lyft, yelp.
Is this still an issue, or are things more reliable these days? (Ignoring the Google integrity stuff.)
I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox. Then it dropped to advertised. You might want to add that to your complaint. Halving everyone’s battery life is easily quantified economic damage. (Privacy is more important than bundling $50 of battery, then wasting it, but easier for Google to wave away with big words and doublespeak.)
The bigger problem came from apps that threw null point exceptions on startup when probing for google play crap.
The following failed for at least one week over a two month period: parkmobile, multiple ev charging networks, uber, lyft, yelp.
Is this still an issue, or are things more reliable these days? (Ignoring the Google integrity stuff.)
I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox. Then it dropped to advertised. You might want to add that to your complaint. Halving everyone’s battery life is easily quantified economic damage. (Privacy is more important than bundling $50 of battery, then wasting it, but easier for Google to wave away with big words and doublespeak.)
The app crashes I found were always due to the additional security hardening features in GrapheneOS. You can toggle these individually for each app.
> The bigger problem came from apps that threw null point exceptions on startup when probing for google play crap.
>
> The following failed for at least one week over a two month period: parkmobile, multiple ev charging networks, uber, lyft, yelp.
>
> Is this still an issue, or are things more reliable these days? (Ignoring the Google integrity stuff.)
These apps have worked reliability since our sandboxed Google Play compatibility layer added support for them in 2021. There wasn't a time period where these apps weren't compatible with GrapheneOS after they initially became supported. That was a problem with your setup, but there's no way to figure out what was wrong at this point. Updating sandboxed Google Play without keeping the OS updated is not supported. If you fell significantly behind on updates but were still getting sandboxed Google Play updates, that would explain why things broke. We sometimes gate those updates. We do keep things working for legacy extended support devices, but whether people are on a fully supported device or a legacy one they're expected to keep the OS updated. We don't keep compatibility with old OS versions indefinitely. Disabling the Network permission for sandboxed Google Play services or sandboxed Google Play Store is another possible cause. Regardless of the cause, that's not at all normal and doesn't reflect a typical experience.
> I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox.
GrapheneOS will still tend to get better battery life with the same apps installed by the user unless you install a bunch of other Google apps to match the stock Pixel OS out-of-the-box experience. It's easy to make battery life worse by having multiple push messaging systems running at the same time though. Installing sandboxed Google Play in 2 separate profiles you always keep active could easily have worse battery life than the stock Pixel OS since it's 2 whole separate isolated instances of it vs. the stock Pixel OS having them built into the OS as highly privileged cross-profile system services.
These apps have worked reliability since our sandboxed Google Play compatibility layer added support for them in 2021. There wasn't a time period where these apps weren't compatible with GrapheneOS after they initially became supported. That was a problem with your setup, but there's no way to figure out what was wrong at this point. Updating sandboxed Google Play without keeping the OS updated is not supported. If you fell significantly behind on updates but were still getting sandboxed Google Play updates, that would explain why things broke. We sometimes gate those updates. We do keep things working for legacy extended support devices, but whether people are on a fully supported device or a legacy one they're expected to keep the OS updated. We don't keep compatibility with old OS versions indefinitely. Disabling the Network permission for sandboxed Google Play services or sandboxed Google Play Store is another possible cause. Regardless of the cause, that's not at all normal and doesn't reflect a typical experience.
> I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox.
GrapheneOS will still tend to get better battery life with the same apps installed by the user unless you install a bunch of other Google apps to match the stock Pixel OS out-of-the-box experience. It's easy to make battery life worse by having multiple push messaging systems running at the same time though. Installing sandboxed Google Play in 2 separate profiles you always keep active could easily have worse battery life than the stock Pixel OS since it's 2 whole separate isolated instances of it vs. the stock Pixel OS having them built into the OS as highly privileged cross-profile system services.
Thank you for doing that. Integrity API is fucking evil, and Google has somehow managed to sell it as a security measure even though it is all about taking control away from people and concentrating it at Google.
I just use contactless cards now. I’m done with tying my financial capability to a third party device. If I want to pay someone directly it’s PayPal family and friends or direct bank transfer.
Yea, I really don't understand how using a phone is any simpler than just tapping my debit card at the terminal. There's no way in hell I'm letting Google anywhere near my personal finances.
Using a phone is simpler if all you have on you is your phone, which was my use case when my bank hadn't offloaded their wallet app to gpay. That, and having the phone already in hand for customer/loyalty cards.
So yes, it's handy. Jot handy enough to use gpay for it, of course, but handy nonetheless.
So yes, it's handy. Jot handy enough to use gpay for it, of course, but handy nonetheless.
Nfc card payments have a pretty low max limit at least without a pin.
Phone nfc payments do not.
Phone nfc payments do not.
Did you do your complaint at ACM? I want to follow your example
I did using their website form. It needs to be clear from the complaint that Google is violating fair market principles. They also like details about what exactly is happening and who is affected. That was why they called me after I filed the complaint.
I would love to chip in and see if we can get this ball rolling, usually I feel like I'm the only person who cares or files AP/ACM/... complaints and then it's too small beans for them to care. I'd not submit the literal same thing again, but could you share what wording you've used? Specifically in this case I'd also not be sure whether this blocking of Graphene etc. is abuse of market power when there is another option on the market (Apple) and so it's not a monopoly
There's no contact info in your profile so I couldn't reach you. If you don't want to share it here, you could use the email address in my profile
There's no contact info in your profile so I couldn't reach you. If you don't want to share it here, you could use the email address in my profile
Good that you mention it. I will add contact details.
It has been a while so I don't remember the exact wording. I wouldn't use the same wording since it is not a petition and doesn't add value. They want to research if it is an unfair practice. In my opinion banking and wireless payments is a common good. Having two companies, who only approve software of partners, most of them including unremovable spyware, is limiting on access to banking and privacy (although privacy is another department). I mentioned security since that is Google's argument for the block even though GrapheneOS is more secure than approved builds. I gave the number of GrapheneOS users to make clear it doesn't affect only a few individuals. I think LineageOS users might also be affected?
It shouldn't work like a petition, but these organisations do treat it as such unless something is very obviously a major violation. Even with numbers of Graphene users, what part of that is Dutch? What part of that wants to use Google Pay? What part makes use of a workaround? Multiple reports of problems does give some information/signal that this is worth their time
But yes, as said I'd not use the same wording because it shouldn't just be a copy-paste, that's also wasting their time. I could refer to what was already submitted so they can more easily bundle them, but I understand you don't have it anymore so np. Thanks for mentioning you've submitted this in the first place and the additional info, that does motivate me to continue also submitting things and to know better what makes sense to submit :)
But yes, as said I'd not use the same wording because it shouldn't just be a copy-paste, that's also wasting their time. I could refer to what was already submitted so they can more easily bundle them, but I understand you don't have it anymore so np. Thanks for mentioning you've submitted this in the first place and the additional info, that does motivate me to continue also submitting things and to know better what makes sense to submit :)
It’s great. Thanks for doing that.
The French concurrence authority would probably love that type of reasoning. Specially now that the US is officially an adversarial entity.
I was bit confused why this was notable, but the Pixel 9a just released Thursday. So this is an incredibly fast turnaround for a community OS.
I think a lot of the work is in new device bringup, and given that they can start from official Pixel trees, it shouldn't be too much work to adapt them for whatever GrapheneOS-specific build processes they have, and then I'm assuming the rest of the GrapheneOS customizations are framework side which should be device agnostic. I guess they could have kernel changes for hardening, but not sure how easy or hard porting those would be - is the Pixel 9 series on a newer kernel version than say the Pixel 8?
GrapheneOS has various features requiring hardware integration. Our hardening features also uncover bugs across the code especially in drivers, especially the hardware memory tagging integration in our hardened_malloc project and the standard Linux kernel hardware memory tagging support we use in the kernel. Pixels are very similar to each other though so this work is largely but not entirely done for them.
Adding new Pixels including whole new generations tends to be quite easy. When we still supported Snapdragon Pixels in the official GrapheneOS branch, it would have been fairly easy to add support for a theoretical Sony or Motorola device meeting our security requirements (https://grapheneos.org/faq#future-devices). Now that we don't have a Snapdragon device, we'd need to deal with fixing or working around all the bugs uncovered in Snapdragon drivers, integrating support for the USB-C controller into our USB-C port control feature (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...), adding back our code for coercing Qualcomm XTRA into being privacy respecting, etc. Snapdragon doesn't have memory tagging yet like Tensor (and recent flagship Exynos/MediaTek now), but pretending it did, we'd need to solve a lot of issues uncovered by it unless Qualcomm and the device OEM heavily tested with it.
See https://news.ycombinator.com/item?id=43669913 for more info including about kernels. 6th, 7th, 8th and 9th generation Pixels share the same Linux 6.1 source tree and kernel drivers since Android 15 QPR2 in March 2025.
Pixel 9a is still using a branch of Android 15 QPR1 due to how device launches work so most of the work involved taking our last Android 15 QPR1 release from early March and rebasing it onto the Pixel 9a device branch tag where they forked off from an earlier Android 15 QPR1 release and backported current security patches to it. We then had to backport our changes since early March. The device branch will go away in a couple months and it will be on the same branch as everything else until it's end-of-life as usual. We could spend more time to integrate it into our main Android 15 QPR2 based branch ourselves but we can also simply wait a couple months. As an earlier example, the Pixel 8a was released in May 2024 based on Android 14 QPR1 rather than the current Android 14 QPR2. It was incorporated into mainline Android 14 QPR3 in June only a few weeks later. We know Android 16 is already going to deal with this so spending our time on this instead of implementing new privacy, security, usability and compatibility improvements would be a waste.
Adding new Pixels including whole new generations tends to be quite easy. When we still supported Snapdragon Pixels in the official GrapheneOS branch, it would have been fairly easy to add support for a theoretical Sony or Motorola device meeting our security requirements (https://grapheneos.org/faq#future-devices). Now that we don't have a Snapdragon device, we'd need to deal with fixing or working around all the bugs uncovered in Snapdragon drivers, integrating support for the USB-C controller into our USB-C port control feature (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...), adding back our code for coercing Qualcomm XTRA into being privacy respecting, etc. Snapdragon doesn't have memory tagging yet like Tensor (and recent flagship Exynos/MediaTek now), but pretending it did, we'd need to solve a lot of issues uncovered by it unless Qualcomm and the device OEM heavily tested with it.
See https://news.ycombinator.com/item?id=43669913 for more info including about kernels. 6th, 7th, 8th and 9th generation Pixels share the same Linux 6.1 source tree and kernel drivers since Android 15 QPR2 in March 2025.
Pixel 9a is still using a branch of Android 15 QPR1 due to how device launches work so most of the work involved taking our last Android 15 QPR1 release from early March and rebasing it onto the Pixel 9a device branch tag where they forked off from an earlier Android 15 QPR1 release and backported current security patches to it. We then had to backport our changes since early March. The device branch will go away in a couple months and it will be on the same branch as everything else until it's end-of-life as usual. We could spend more time to integrate it into our main Android 15 QPR2 based branch ourselves but we can also simply wait a couple months. As an earlier example, the Pixel 8a was released in May 2024 based on Android 14 QPR1 rather than the current Android 14 QPR2. It was incorporated into mainline Android 14 QPR3 in June only a few weeks later. We know Android 16 is already going to deal with this so spending our time on this instead of implementing new privacy, security, usability and compatibility improvements would be a waste.
Off-topic, but as someone who's followed your work for a long time, it's cool to see you posting again! I hope you're doing better these days.
Thank you for your work and the interesting and insightful comments. I've learned a lot from you.
I wish it was feasible to run GrapheneOS on more devices. For some reason, Google seems to be incapable of selling Pixels world wide.
I wish it was feasible to run GrapheneOS on more devices. For some reason, Google seems to be incapable of selling Pixels world wide.
Thank you for all the hard work you do on GrapheneOS.
Thank you for all the work on GrapheneOS that is done.
I got it on a P7P and love it.
I got it on a P7P and love it.
Am I supposed to trust security information coming from a user named strcat? /s
Quick, someone named strcat_s or strncat correct them!
Quick, someone named strcat_s or strncat correct them!
Incredibly fast.
While the 9a and 9 pro are very similar, for comunity based development this is substantial.
I am often very critial, but I must give props to the grapeneos team.
While the 9a and 9 pro are very similar, for comunity based development this is substantial.
I am often very critial, but I must give props to the grapeneos team.
They are starting from an OS that is made to work on these devices.
Reminds me of iOS and iDevices and how even after months they keep stabilising and then they fail to stabilise and then they release the next version after a year with all those bugs intact and accumulated. In this case that OS is literally made for only those devices and vice-versa, in iron claw control of one control freak corporation that has a net worth more than GDPs many countries would nuke for.
Let’s contrast that with a pure community led effort, motivated by freedom, privacy, and safety, that neither controls the OS nor the devices. It’s not what I tried to saltily explain above.
Respectfully, I hope that sunk in.
Let’s contrast that with a pure community led effort, motivated by freedom, privacy, and safety, that neither controls the OS nor the devices. It’s not what I tried to saltily explain above.
Respectfully, I hope that sunk in.
All Android devices support running the Android Open Source Project via Treble and we could quickly add support for non-Pixel devices doing things in a reasonable way too. Those devices don't meet our hardware security requirements (https://grapheneos.org/faq#future-devices) which is why we don't support them. It wouldn't be that hard to add a Sony or Motorola device but they're missing the expected security features and proper updates. It wouldn't be possible to provide our standard security protections on them which is the real blocking issue, not difficulty. Android has made device support simple, but the rest of the Android device ecosystem is not at all competitive in security with Pixels and iPhones.
We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though.
Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us.
Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a).
We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack.
If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.
We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though.
Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us.
Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a).
We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack.
If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.
Thank you for all the insights.
Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now.
Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?
Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.
Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now.
Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?
Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.
> Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?
We've made significant contributions to the Linux kernel, AOSP and Pixels in the past. We continue doing it to the extent that it helps GrapheneOS users. We no longer spend our time doing work for them if it doesn't have a clear benefit to our users.
Android's security team previously got us security partner access and was in the process of getting us OEM partner access. Android's partner management team blocked us from getting OEM partner access and revoked our security partner access. Due to this, we've reduced our reports of vulnerabilities upstream and have fixed numerous vulnerabilities in GrapheneOS without reporting them. We still report all firmware and hardware vulnerabilities but we make a decision about reporting software vulnerabilities solely based on what's best for GrapheneOS users.
> Many of the security features you are using are already included in AOSP
That's not really the case. The vast majority of our privacy and security features were developed for GrapheneOS. Features being built on top of standard functionality doesn't mean that they're present in AOSP.
For example, GrapheneOS has our own integration of hardware memory tagging into our hardened_malloc project and we turned the overall feature into something which can be used in production without making the OS unusable. We had to fix issues with the standard hardware memory tagging integration in the OS and Vanadium (Chromium) along with fixing numerous bugs uncovered by it. We had to integrate it into our user-facing crash reporting system and had to create a system for opting into using it for user installed apps where users can enable it for either specific user installed apps or for all user installed apps with a per-app opt-out. Android has the foundation for hardware memory tagging support but it's not used as a production feature for hardening and we're not simply enabling it. We have a much better userspace implementation in hardened_malloc and while we currently use the standard kernel allocator integration, we want to improve that to be closer to what we do with it in hardened_malloc. We currently use the standard Linux kernel MTE integration for the kernel allocators and the standard Chromium PartitionAlloc MTE integration but both need to be improved to provide better security properties as hardened_malloc does. They're also missing the other forms of hardening used by hardened_malloc which go nicely with memory tagging. The stock OS developer option for memory tagging is not the same thing and only makes it available for usage without actually using it. It has to then be enabled via ADB but there's no way to use it everywhere we do or in the same way we do. AOSP having that doesn't mean it provides what we do with it at all.
> Do they have a different balancing of performance, stability and compatibility on the one side and security on the other?
Yes, but you're wrong about where our privacy and security features come from.
We've made significant contributions to the Linux kernel, AOSP and Pixels in the past. We continue doing it to the extent that it helps GrapheneOS users. We no longer spend our time doing work for them if it doesn't have a clear benefit to our users.
Android's security team previously got us security partner access and was in the process of getting us OEM partner access. Android's partner management team blocked us from getting OEM partner access and revoked our security partner access. Due to this, we've reduced our reports of vulnerabilities upstream and have fixed numerous vulnerabilities in GrapheneOS without reporting them. We still report all firmware and hardware vulnerabilities but we make a decision about reporting software vulnerabilities solely based on what's best for GrapheneOS users.
> Many of the security features you are using are already included in AOSP
That's not really the case. The vast majority of our privacy and security features were developed for GrapheneOS. Features being built on top of standard functionality doesn't mean that they're present in AOSP.
For example, GrapheneOS has our own integration of hardware memory tagging into our hardened_malloc project and we turned the overall feature into something which can be used in production without making the OS unusable. We had to fix issues with the standard hardware memory tagging integration in the OS and Vanadium (Chromium) along with fixing numerous bugs uncovered by it. We had to integrate it into our user-facing crash reporting system and had to create a system for opting into using it for user installed apps where users can enable it for either specific user installed apps or for all user installed apps with a per-app opt-out. Android has the foundation for hardware memory tagging support but it's not used as a production feature for hardening and we're not simply enabling it. We have a much better userspace implementation in hardened_malloc and while we currently use the standard kernel allocator integration, we want to improve that to be closer to what we do with it in hardened_malloc. We currently use the standard Linux kernel MTE integration for the kernel allocators and the standard Chromium PartitionAlloc MTE integration but both need to be improved to provide better security properties as hardened_malloc does. They're also missing the other forms of hardening used by hardened_malloc which go nicely with memory tagging. The stock OS developer option for memory tagging is not the same thing and only makes it available for usage without actually using it. It has to then be enabled via ADB but there's no way to use it everywhere we do or in the same way we do. AOSP having that doesn't mean it provides what we do with it at all.
> Do they have a different balancing of performance, stability and compatibility on the one side and security on the other?
Yes, but you're wrong about where our privacy and security features come from.
Also, this is the first pixel after this announcement:
https://news.ycombinator.com/item?id=43485950
https://news.ycombinator.com/item?id=43485950
The changes are overstated and it really changes very little for GrapheneOS. See https://discuss.grapheneos.org/d/21315-explanation-of-recent....
Android already published the full source code for Stable releases but barely anything for Beta releases. They didn't publish anything for upcoming releases with support for new devices. AOSP main branch received most changes through the Stable releases being merged into it. Most components were developed internally. Certain components were developed publicly in AOSP so they had to repeatedly merge back and forth between the internal and public main branches.
GrapheneOS would benefit from having early access to the monthly, quarterly and yearly releases as Android OEM partners do. The only benefit of having access to the main development branch would be the ability to backport more fixes than they do along with doing it earlier. We occasionally backported fixes from AOSP main for the few components developed publicly through it, which is what's going to be mostly going away. It was a big help to us as access to the upcoming quarterly and yearly releases would be. Monthly updates are too small for it to really matter but it'd still help.
Also worth noting the monthly security patch backports (Android Security Bulletins) are a separate thing from the new OS release each month. Those are backports of many of the High and Critical severity patches to older Android versions, often a month or two after they were released in the actual OS releases each month which are the monthly, quarterly and yearly releases (it's one of the 3 each month, with 3 quarterly releases and 1 yearly release per year although Android 16 is coming earlier this year instead of a 3rd quarterly release).
Android already published the full source code for Stable releases but barely anything for Beta releases. They didn't publish anything for upcoming releases with support for new devices. AOSP main branch received most changes through the Stable releases being merged into it. Most components were developed internally. Certain components were developed publicly in AOSP so they had to repeatedly merge back and forth between the internal and public main branches.
GrapheneOS would benefit from having early access to the monthly, quarterly and yearly releases as Android OEM partners do. The only benefit of having access to the main development branch would be the ability to backport more fixes than they do along with doing it earlier. We occasionally backported fixes from AOSP main for the few components developed publicly through it, which is what's going to be mostly going away. It was a big help to us as access to the upcoming quarterly and yearly releases would be. Monthly updates are too small for it to really matter but it'd still help.
Also worth noting the monthly security patch backports (Android Security Bulletins) are a separate thing from the new OS release each month. Those are backports of many of the High and Critical severity patches to older Android versions, often a month or two after they were released in the actual OS releases each month which are the monthly, quarterly and yearly releases (it's one of the 3 each month, with 3 quarterly releases and 1 yearly release per year although Android 16 is coming earlier this year instead of a 3rd quarterly release).
Oh wow, how did I miss that! If strcat / Daniel Micay happens to pass by: How much will this impact future development of GrapheneO?
The changes are overstated in the media and has little impact on it. See https://news.ycombinator.com/item?id=43674145. We would benefit a lot from early access to quarterly and yearly releases but that hasn't ever been public and the AOSP main branch only provided the most recent changes for a few components, and not any of the ones we actually need most.
Thanks!
Anyone know why drivers in this OS can't be ported to Linux, so it could support newer phones as well?
Android Open Source Project and operating systems based on it like GrapheneOS are Linux distributions. The kernel drivers are Linux kernel drivers. The userspace drivers are part of Android's Treble hardware abstraction layer providing forwards compatibility with future Android releases and SELinux-based sandboxing with the drivers split up into isolated processes. Most of the driver complexity is in userspace with most kernel drivers acting as shims between the isolated drivers and the hardware. It's done that way for practical reasons on Android but it's good for security.
Treble's compatibility system isn't very relevant to us right now. There's a new Android release every month: a monthly, quarterly or yearly release. The devices we currently support (Pixels) receive each of these updates officially. Most Android devices do not get the monthly or quarterly updates, only the yearly ones. Other devices rely on partial backports of security patches (Android Security Bulletins) to an initial release, which are provided for ~3-4 years after the initial yearly release. If we supported typical Android devices with that situation, then we'd at least partially rely on Treble to provide the latest OS version. Pixels are currently the only devices meeting our hardware security requirements listed at https://grapheneos.org/faq#future-devices. Having proper updates for 7 years from launch is just part of that, most of the requirements are for hardware-based security features like the secure element features, hardware memory tagging, pointer authentication, USB controller support for blocking new connections and disabling USB data, etc.
GrapheneOS uses the 6.1 and 6.6 long term support branches of the Linux kernel with 6.12 as the next one that's likely going to be used to replace 6.6 for on-device virtual machines and the emulator with Android 16.
Treble's compatibility system isn't very relevant to us right now. There's a new Android release every month: a monthly, quarterly or yearly release. The devices we currently support (Pixels) receive each of these updates officially. Most Android devices do not get the monthly or quarterly updates, only the yearly ones. Other devices rely on partial backports of security patches (Android Security Bulletins) to an initial release, which are provided for ~3-4 years after the initial yearly release. If we supported typical Android devices with that situation, then we'd at least partially rely on Treble to provide the latest OS version. Pixels are currently the only devices meeting our hardware security requirements listed at https://grapheneos.org/faq#future-devices. Having proper updates for 7 years from launch is just part of that, most of the requirements are for hardware-based security features like the secure element features, hardware memory tagging, pointer authentication, USB controller support for blocking new connections and disabling USB data, etc.
GrapheneOS uses the 6.1 and 6.6 long term support branches of the Linux kernel with 6.12 as the next one that's likely going to be used to replace 6.6 for on-device virtual machines and the emulator with Android 16.
> The kernel drivers are Linux kernel drivers.
But they're drivers that are not upstreamed and which therefore make it hard to move to a newer kernel, right?
But they're drivers that are not upstreamed and which therefore make it hard to move to a newer kernel, right?
> But they're drivers that are not upstreamed and which therefore make it hard to move to a newer kernel, right?
It's no harder than it would be dealing with them if they were upstream. Google ports all the Pixel drivers to newer LTS branches and a recent branch of the mainline kernel themselves.
With the recent Android 15 QPR2 release last month (March 2025), 6th/7th generation Pixels moved from the 5.10 branch to 6.1 and 8th generation Pixels moved from 5.15 to 6.1. 6th, 7th, 8th and 9th generation Pixels share the same kernel and kernel driver source tree now. They have them ported to 6.6 and mainline kernels too, it's just not ready to ship yet. 6.6 is used for virtual machines run on the devices and the emulator. 6.12 will be what's used for Android 16.
You can see at https://android.googlesource.com/kernel/google-modules/aoc/+... that they still port the 6th gen Pixel drivers to newer mainline kernels. They're ported to 6.13 and probably moving along to 6.14 soon. It doesn't mean they're going to ship them. Only LTS branches make sense to ship and they need long term stabilization first. The likely model is going to become ~12 months of stabilization and then ~12 months of usage since LTS kernel branches are moving back to 2 years of support. It was essentially increased to 6 years for 6th gen Pixels having 5 years of support, but they moved along to upgrading to newer LTS branches for 8th gen Pixels moving to 7 years of support. Greg KH works for and with Google on the LTS kernel maintenance / testing so it's actually quite Android centric rather than server centric. Long term support desktop/server distributions historically maintain their own LTS branches so they're not really the ones involved in that for the most part.
Drivers that are upstream don't actually get much free maintenance and testing. People making API changes blindly update the drivers without testing them. They get lots of updates and refactoring, but not much ongoing maintenance. Maintainers still need to deal with it. It's very common for upstream drivers to continuously regress. They can go a long time without actually working properly across releases due to how few people use them. Most people are using distributions with frozen package versions like Debian, not a rolling, and people using a rolling release like Arch Linux can use an LTS kernel branch to avoid a lot of this. The drivers for embedded hardware and things not used much by enthusiasts on desktops often break without it being noticed.
Android made a Generic Kernel Image system with ABI stability for drivers which does not benefit Pixels because they update the drivers to match the latest GKI kernel they ship. Similarly, Pixels don't really need the Treble HAL ABI forwards compatibility because they update all the vendor code to the latest monthly, quarterly and yearly OS releases anyway. It's helpful that drivers don't need to add all the new standard features to keep providing working support for new OS versions though. It's nice having it all nearly all neatly standardized and stable. We like Treble because of the sandboxing. The forwards compatibility benefits are largely unrealized because the vendors needing it aren't doing updates much anyway. Qualcomm is moving to 8 years of full update support for Snapdragon to partially match Pixels anyway.
It's no harder than it would be dealing with them if they were upstream. Google ports all the Pixel drivers to newer LTS branches and a recent branch of the mainline kernel themselves.
With the recent Android 15 QPR2 release last month (March 2025), 6th/7th generation Pixels moved from the 5.10 branch to 6.1 and 8th generation Pixels moved from 5.15 to 6.1. 6th, 7th, 8th and 9th generation Pixels share the same kernel and kernel driver source tree now. They have them ported to 6.6 and mainline kernels too, it's just not ready to ship yet. 6.6 is used for virtual machines run on the devices and the emulator. 6.12 will be what's used for Android 16.
You can see at https://android.googlesource.com/kernel/google-modules/aoc/+... that they still port the 6th gen Pixel drivers to newer mainline kernels. They're ported to 6.13 and probably moving along to 6.14 soon. It doesn't mean they're going to ship them. Only LTS branches make sense to ship and they need long term stabilization first. The likely model is going to become ~12 months of stabilization and then ~12 months of usage since LTS kernel branches are moving back to 2 years of support. It was essentially increased to 6 years for 6th gen Pixels having 5 years of support, but they moved along to upgrading to newer LTS branches for 8th gen Pixels moving to 7 years of support. Greg KH works for and with Google on the LTS kernel maintenance / testing so it's actually quite Android centric rather than server centric. Long term support desktop/server distributions historically maintain their own LTS branches so they're not really the ones involved in that for the most part.
Drivers that are upstream don't actually get much free maintenance and testing. People making API changes blindly update the drivers without testing them. They get lots of updates and refactoring, but not much ongoing maintenance. Maintainers still need to deal with it. It's very common for upstream drivers to continuously regress. They can go a long time without actually working properly across releases due to how few people use them. Most people are using distributions with frozen package versions like Debian, not a rolling, and people using a rolling release like Arch Linux can use an LTS kernel branch to avoid a lot of this. The drivers for embedded hardware and things not used much by enthusiasts on desktops often break without it being noticed.
Android made a Generic Kernel Image system with ABI stability for drivers which does not benefit Pixels because they update the drivers to match the latest GKI kernel they ship. Similarly, Pixels don't really need the Treble HAL ABI forwards compatibility because they update all the vendor code to the latest monthly, quarterly and yearly OS releases anyway. It's helpful that drivers don't need to add all the new standard features to keep providing working support for new OS versions though. It's nice having it all nearly all neatly standardized and stable. We like Treble because of the sandboxing. The forwards compatibility benefits are largely unrealized because the vendors needing it aren't doing updates much anyway. Qualcomm is moving to 8 years of full update support for Snapdragon to partially match Pixels anyway.
Two thoughts (and a half, I suppose).
First: I did momentarily forget that you're only targeting Pixel devices that are actively getting updates from Google. In light of that, so long as Google stays on top of maintaining those devices, yeah in your case that's probably fine. I'm somewhat accustomed to less responsible vendors and a lot of my views are shaped by that.
That said, I'm not wholly convinced that Google's downstream kernels are as good as running from upstream. AFAICT, for example, GrapheneOS is currently shipping a kernel for the Pixel 6 that's 3 minor versions behind. Trying to track things through the Android development process is... unintuitive... to me, so forgive me if I've missed something... If I go to https://github.com/GrapheneOS/device_google_raviole-kernels_... , grab a .ko file that shows as being committed yesterday, and run modinfo on it, I get a version of 6.1.131 which https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... says is from March 13 and has been superseded by 6.1.134 at this writing (from checking https://www.kernel.org/ ). Contrast https://archlinux.org/packages/core/x86_64/linux-lts/ which says that Arch's LTS kernel is at 6.12.23 which is the latest of that line. EDIT: Actually, the much better comparison is that Debian 12 is shipping 6.1.133 according to https://packages.debian.org/stable/kernel/linux-image-arm64 now. So the super stable slow moving distro is in fact still ahead of Android, even slightly lagging as it is.
As to breakage/testing... Yes, someone has to test new versions. Ideally that'd be a CI farm flashing and testing devices, but I appreciate that it's not exactly a trivial problem. Nonetheless, if that results in Graphene not shipping the latest bugfixes, I feel like that's an extremely awkward position to be in.
First: I did momentarily forget that you're only targeting Pixel devices that are actively getting updates from Google. In light of that, so long as Google stays on top of maintaining those devices, yeah in your case that's probably fine. I'm somewhat accustomed to less responsible vendors and a lot of my views are shaped by that.
That said, I'm not wholly convinced that Google's downstream kernels are as good as running from upstream. AFAICT, for example, GrapheneOS is currently shipping a kernel for the Pixel 6 that's 3 minor versions behind. Trying to track things through the Android development process is... unintuitive... to me, so forgive me if I've missed something... If I go to https://github.com/GrapheneOS/device_google_raviole-kernels_... , grab a .ko file that shows as being committed yesterday, and run modinfo on it, I get a version of 6.1.131 which https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... says is from March 13 and has been superseded by 6.1.134 at this writing (from checking https://www.kernel.org/ ). Contrast https://archlinux.org/packages/core/x86_64/linux-lts/ which says that Arch's LTS kernel is at 6.12.23 which is the latest of that line. EDIT: Actually, the much better comparison is that Debian 12 is shipping 6.1.133 according to https://packages.debian.org/stable/kernel/linux-image-arm64 now. So the super stable slow moving distro is in fact still ahead of Android, even slightly lagging as it is.
As to breakage/testing... Yes, someone has to test new versions. Ideally that'd be a CI farm flashing and testing devices, but I appreciate that it's not exactly a trivial problem. Nonetheless, if that results in Graphene not shipping the latest bugfixes, I feel like that's an extremely awkward position to be in.
Having the kernel that is being shipped to customers be less than 1 month behind is not that bad.
>So the super stable slow moving distro
Slow isn't referring to the speed Debian takes for hot fixes. It is referring to how long Debian stays hot fixing packages over updating to the latest version.
>So the super stable slow moving distro
Slow isn't referring to the speed Debian takes for hot fixes. It is referring to how long Debian stays hot fixing packages over updating to the latest version.
You can see that we're on the latest 6.1.134 and 6.6.87 now because Greg KH caught up the Android GKI LTS branch to the kernel.org LTS branch. That will be included in our upcoming OS release in the next couple days.
We ship GKI LTS updates quickly but the GKI LTS branch can sometimes lag behind by up to a few weeks as it was doing when you looked. You happened to look at the maximum point it lags behind. It should really be kept closely in sync with the kernel.org releases but it's almost entirely Greg KH dealing with it and he deals with a lot of other stuff too.
We ship GKI LTS updates quickly but the GKI LTS branch can sometimes lag behind by up to a few weeks as it was doing when you looked. You happened to look at the maximum point it lags behind. It should really be kept closely in sync with the kernel.org releases but it's almost entirely Greg KH dealing with it and he deals with a lot of other stuff too.
Linux 6.12 is not better for security than Linux 6.1 or Linux 6.6. It doesn't work that way. Newer kernels have substantially more attack surface and complexity. They also have tons of new bugs. Bug density is far higher in new or recently changed code. Bug density drops over time. However, backporting patches gets increasingly less complete for the older branches. There's a balance between the new and older branches. 6.12 is far too new to be a reasonable choice. Google already ported Pixels to Linux 6.12, etc. It's not what is shipped because it's full of serious bugs. Separately from that, if you believe using an LTS release and shipping the latest revisions means you avoid regularly having serious regressions, that's very wrong with the Linux kernel.
Pixels only recently started moving to new LTS releases and will likely be moving to a new LTS release each year going forward. Moving the older generations to 6.1 to match current devices was done in March 2025. They'll likely move along together to a new branch each year going forward.
Linux kernel LTS revisions are nothing like LTS revisions of most other projects. They're largely untested patches blindly applied by the LTS maintainers based on patches to mainline being marked for stable backports. If the patches apply cleanly, they ship. If they don't apply cleanly, they largely don't ship. Whether it works is an open question.
> GrapheneOS is currently shipping a kernel for the Pixel 6 that's 3 minor versions behind
That's not quite right.
We're shipping the latest Linux 6.1 and Linux 6.6 GKI LTS branch releases from Greg KH. They're currently in between 2 upstream revisions upstream, not on a specific one. The devices all use both 6.1 and 6.6, not just 6.1. They use 6.1 for bare metal and 6.6 for virtual machines. Even the Pixel 6 has been ported to 6.13 by Google but that doesn't mean that's a stable enough kernel ready to ship.
The Android kernel branches also have a bunch of backports not included in the kernel.org LTS releases, including security patches and improvements they decided were important. Google does their own backporting and fixes in the GKI branch and Greg KH merges those into the GKI LTS branch. The kernel branch we use is the combination of the Google GKI backporting/fixes with the kernel.org backporting. The kernel.org LTS releases are far messier than you realize, and combining these things is messy too.
Linux LTS kernels are not very well tested and have tons of regressions. Quickly updating to the new LTS versions is problematic and we regularly encounter major regressions, especially in certain areas like f2fs and USB. We still update right away to the new GKI LTS versions. We're currently on the latest GKI LTS releases for each branch.
You'd have to ask Greg KH why there are still delays despite Google supporting it. It still seems to be him doing most of the kernel.org LTS and also GKI LTS work by himself, without nearly as much review or help by others as you would think. This is also tied into the severe regressions regularly happening with the LTS releases. Those can be security regressions too. Immediately updating to them is not necessarily a great idea with how much goes wrong at the moment.
They unfortunately sometimes lag behind the kernel.org releases. We used to merge the latest upstream kernel.org LTS releases ourselves but Greg KH convinced us we don't need to do that anymore and should just use the GKI LTS branch instead. We're not completely happy with it since it's not fully kept in sync but we're using our resources elsewhere at the moment.
> Actually, the much better comparison is that Debian 12 is shipping 6.1.133 according to https://packages.debian.org/stable/kernel/linux-image-arm64 now. So the super stable slow moving distro is in fact still ahead of Android, even slightly lagging as it is.
Debian is usually further behind than Greg KH's GKI LTS branch. Comparing at a snapshot in time doesn't mean much. GKI LTS branch should really be kept in sync but the GKI ABI stability system makes maintenance hard and is entirely worthless for Pixels. We would prefer if the whole GKI system did not exist. For Pixels, the kernel image and all the drivers are built with the same kernel source tree for Pixels so the whole system for driver ABI compatibility is just making things more complex and worse.
> As to breakage/testing... Yes, someone has to test new versions. Ideally that'd be a CI farm flashing and testing devices, but I appreciate that it's not exactly a trivial problem. Nonetheless, if that results in Graphene not shipping the latest bugfixes, I feel like that's an extremely awkward position to be in.
We do heavily test them. Our community helps with it. We OFTEN find regressions in the new LTS kernels. It often takes months before the issues we find and work around get fixed upstream. It's worth noting that due to mistreatment we've largely stopped helping them except for firmware, hardware or things we don't want to maintain downstream for some reason. It would be better if everyone collaborated on maintaining LTS kernels but instead it's largely 1 person and a couple others doing it with support from Google for testing, etc.
Pixels only recently started moving to new LTS releases and will likely be moving to a new LTS release each year going forward. Moving the older generations to 6.1 to match current devices was done in March 2025. They'll likely move along together to a new branch each year going forward.
Linux kernel LTS revisions are nothing like LTS revisions of most other projects. They're largely untested patches blindly applied by the LTS maintainers based on patches to mainline being marked for stable backports. If the patches apply cleanly, they ship. If they don't apply cleanly, they largely don't ship. Whether it works is an open question.
> GrapheneOS is currently shipping a kernel for the Pixel 6 that's 3 minor versions behind
That's not quite right.
We're shipping the latest Linux 6.1 and Linux 6.6 GKI LTS branch releases from Greg KH. They're currently in between 2 upstream revisions upstream, not on a specific one. The devices all use both 6.1 and 6.6, not just 6.1. They use 6.1 for bare metal and 6.6 for virtual machines. Even the Pixel 6 has been ported to 6.13 by Google but that doesn't mean that's a stable enough kernel ready to ship.
The Android kernel branches also have a bunch of backports not included in the kernel.org LTS releases, including security patches and improvements they decided were important. Google does their own backporting and fixes in the GKI branch and Greg KH merges those into the GKI LTS branch. The kernel branch we use is the combination of the Google GKI backporting/fixes with the kernel.org backporting. The kernel.org LTS releases are far messier than you realize, and combining these things is messy too.
Linux LTS kernels are not very well tested and have tons of regressions. Quickly updating to the new LTS versions is problematic and we regularly encounter major regressions, especially in certain areas like f2fs and USB. We still update right away to the new GKI LTS versions. We're currently on the latest GKI LTS releases for each branch.
You'd have to ask Greg KH why there are still delays despite Google supporting it. It still seems to be him doing most of the kernel.org LTS and also GKI LTS work by himself, without nearly as much review or help by others as you would think. This is also tied into the severe regressions regularly happening with the LTS releases. Those can be security regressions too. Immediately updating to them is not necessarily a great idea with how much goes wrong at the moment.
They unfortunately sometimes lag behind the kernel.org releases. We used to merge the latest upstream kernel.org LTS releases ourselves but Greg KH convinced us we don't need to do that anymore and should just use the GKI LTS branch instead. We're not completely happy with it since it's not fully kept in sync but we're using our resources elsewhere at the moment.
> Actually, the much better comparison is that Debian 12 is shipping 6.1.133 according to https://packages.debian.org/stable/kernel/linux-image-arm64 now. So the super stable slow moving distro is in fact still ahead of Android, even slightly lagging as it is.
Debian is usually further behind than Greg KH's GKI LTS branch. Comparing at a snapshot in time doesn't mean much. GKI LTS branch should really be kept in sync but the GKI ABI stability system makes maintenance hard and is entirely worthless for Pixels. We would prefer if the whole GKI system did not exist. For Pixels, the kernel image and all the drivers are built with the same kernel source tree for Pixels so the whole system for driver ABI compatibility is just making things more complex and worse.
> As to breakage/testing... Yes, someone has to test new versions. Ideally that'd be a CI farm flashing and testing devices, but I appreciate that it's not exactly a trivial problem. Nonetheless, if that results in Graphene not shipping the latest bugfixes, I feel like that's an extremely awkward position to be in.
We do heavily test them. Our community helps with it. We OFTEN find regressions in the new LTS kernels. It often takes months before the issues we find and work around get fixed upstream. It's worth noting that due to mistreatment we've largely stopped helping them except for firmware, hardware or things we don't want to maintain downstream for some reason. It would be better if everyone collaborated on maintaining LTS kernels but instead it's largely 1 person and a couple others doing it with support from Google for testing, etc.
Right, no, I wasn't particularly objecting to 6.1, I was pointing at the patch level on it. I would personally take [quickly checks kernel.org] 5.15.180 (latest 5.15) over 6.1.130 (not-latest 6.1), because I'm more concerned with bugfixes than feature releases at this point. If the GKI LTSs are backporting fixes, that may well cover it, although that starts to veer into making me nervous because I rather agree with
> Linux kernel LTS revisions are nothing like LTS revisions of most other projects. They're largely untested patches blindly applied by the LTS maintainers based on patches to mainline being marked for stable backports. If the patches apply cleanly, they ship. If they don't apply cleanly, they largely don't ship. Whether it works is an open question.
I'm also not super fond of frankenkernels. And... I'm confused how you feel about them? If backports suck, shouldn't you want to be chasing the very bleeding edge? I wasn't originally intending to argue that everything had to ride the very latest and greatest, but if backporting is inherently fragile and bug-prone, shouldn't you want to be on the very latest stable version (so as of this writing, 6.14.2)?
> Linux kernel LTS revisions are nothing like LTS revisions of most other projects. They're largely untested patches blindly applied by the LTS maintainers based on patches to mainline being marked for stable backports. If the patches apply cleanly, they ship. If they don't apply cleanly, they largely don't ship. Whether it works is an open question.
I'm also not super fond of frankenkernels. And... I'm confused how you feel about them? If backports suck, shouldn't you want to be chasing the very bleeding edge? I wasn't originally intending to argue that everything had to ride the very latest and greatest, but if backporting is inherently fragile and bug-prone, shouldn't you want to be on the very latest stable version (so as of this writing, 6.14.2)?
We want to be on an LTS branch, but we'd prefer to be on a newer LTS branch. We would currently want to be on 6.6 with a near future move to 6.12 once it was stabilized enough. However, we would much rather be on what Google is heavily testing than using a kernel they're not using on their CI infrastructure and production devices.
Pixels moving 6th, 7th and 8th gen devices to 6.1 happened in March 2025. It's the first time they've moved to new LTS branches. It's likely going to move to using a newer LTS release where it would currently be using 6.6 and then moving to 6.12 after the next one comes out. We expect they move to having around a year to stabilize the new LTS and then use it for around a year before moving to the next. That fits nicely into the new 2 year lifespan for LTS kernels. This is a transition period. Once the longer than 2 year LTS kernels are gone, the quality of the LTS kernels will rise because there won't be as many to maintain. There are currently too many combined with too few people working on it. Greg KH having to handle both the kernel.org LTS and GKI LTS doing a huge portion of the work is clearly a problem. We'd also like to see the end of GKI ABI stability but that's highly unlikely. Yearly moves to new LTS kernels will at least make it a lot better.
> I would personally take [quickly checks kernel.org] 5.15.180 (latest 5.15) over 6.1.130 (not-latest 6.1)
Latest 5.15 has far fewer fixes backported for the same time periods than 6.1. The missing fixes in 5.15 are far more than a couple minor revisions. Similarly, 6.6 has more than 6.1 for the same time period and 6.12 has more than 6.6.
> And... I'm confused how you feel about them? If backports suck, shouldn't you want to be chasing the very bleeding edge? I wasn't originally intending to argue that everything had to ride the very latest and greatest, but if backporting is inherently fragile and bug-prone, shouldn't you want to be on the very latest stable version (so as of this writing, 6.14.2)?
Linux kernel code quality, review and testing is quite low. The bleeding edge kernels are nearly unusable in production for this use case (users running all kinds of software, using all kinds of different Bluetooth, USB, etc. accessories and so on while caring deeply about battery life) and have a ton of newly added security bugs which aren't found and fixed yet. We think that's a much bigger issue. We happily use Arch Linux for a lot of stuff but we use the LTS kernel package which is 6.12 at the moment.
If LTS quality was increased substantially, then we'd want to be on the latest LTS branch a while after the initial release, i.e. 6.12.15+ or so. However, at the moment, some serious regressions take them so long to find that it's still too new. We have high stability requirements where we can't have niche USB functionality, Bluetooth, video recording, etc. functionality regressing. The out-of-tree drivers are an area we don't have as much pain with since they're nearly all made for Exynos / Pixels and the drivers from the vendors so changes actually get tested well. The regressions are in the upstream code. More stuff coming from upstream would make LTS updates more, not less, painful, other than the GKI ABI stability nonsense we don't want.
Pixels moving 6th, 7th and 8th gen devices to 6.1 happened in March 2025. It's the first time they've moved to new LTS branches. It's likely going to move to using a newer LTS release where it would currently be using 6.6 and then moving to 6.12 after the next one comes out. We expect they move to having around a year to stabilize the new LTS and then use it for around a year before moving to the next. That fits nicely into the new 2 year lifespan for LTS kernels. This is a transition period. Once the longer than 2 year LTS kernels are gone, the quality of the LTS kernels will rise because there won't be as many to maintain. There are currently too many combined with too few people working on it. Greg KH having to handle both the kernel.org LTS and GKI LTS doing a huge portion of the work is clearly a problem. We'd also like to see the end of GKI ABI stability but that's highly unlikely. Yearly moves to new LTS kernels will at least make it a lot better.
> I would personally take [quickly checks kernel.org] 5.15.180 (latest 5.15) over 6.1.130 (not-latest 6.1)
Latest 5.15 has far fewer fixes backported for the same time periods than 6.1. The missing fixes in 5.15 are far more than a couple minor revisions. Similarly, 6.6 has more than 6.1 for the same time period and 6.12 has more than 6.6.
> And... I'm confused how you feel about them? If backports suck, shouldn't you want to be chasing the very bleeding edge? I wasn't originally intending to argue that everything had to ride the very latest and greatest, but if backporting is inherently fragile and bug-prone, shouldn't you want to be on the very latest stable version (so as of this writing, 6.14.2)?
Linux kernel code quality, review and testing is quite low. The bleeding edge kernels are nearly unusable in production for this use case (users running all kinds of software, using all kinds of different Bluetooth, USB, etc. accessories and so on while caring deeply about battery life) and have a ton of newly added security bugs which aren't found and fixed yet. We think that's a much bigger issue. We happily use Arch Linux for a lot of stuff but we use the LTS kernel package which is 6.12 at the moment.
If LTS quality was increased substantially, then we'd want to be on the latest LTS branch a while after the initial release, i.e. 6.12.15+ or so. However, at the moment, some serious regressions take them so long to find that it's still too new. We have high stability requirements where we can't have niche USB functionality, Bluetooth, video recording, etc. functionality regressing. The out-of-tree drivers are an area we don't have as much pain with since they're nearly all made for Exynos / Pixels and the drivers from the vendors so changes actually get tested well. The regressions are in the upstream code. More stuff coming from upstream would make LTS updates more, not less, painful, other than the GKI ABI stability nonsense we don't want.
Ton of information here.
But was hoping to find out how mobile Linux distros (mobian, postmarket, pureos, new ones) could support newer phones, like these Pixels. I still don't know after reading this thread. :-D
I don't want to use Android, I want to use Linux and Phosh or similar. But so far, the supported hardware is junk.
I don't want to use Android, I want to use Linux and Phosh or similar. But so far, the supported hardware is junk.
GrapheneOS is a mobile Linux distribution. It's not systemd and GNOME which makes it a Linux distribution but rather the Linux kernel. There's nothing stopping people from running a traditional desktop Linux software stack on the same hardware we support. That doesn't interest us since it would be a massive privacy and security regression from the Android Open Source Project. It would also give a lot of usability, robustness and the huge mobile app ecosystem including a large number of open source mobile apps.
The Linux kernel is increasingly the elephant in the room when it comes to security and hasn't experienced anything like the massive progress made in Android's security in userspace. Piling on many more exploit mitigations to the Linux kernel won't really change this. We need to do a lot more work on it than we already do.
GrapheneOS has hardware virtualization support, which is going to be one of the ways to avoid depending so much on the Linux kernel's fragile security. The main usage for it in GrapheneOS will be running nested GrapheneOS instances for better sandboxing rather than running other operating systems. Android supports using the virtualization support to run other operating systems via the Terminal app and we have support for GUI applications, speaker, microphone and opt-in GPU acceleration backported to the Terminal app. The main use case for that app will be running desktop applications from other operating systems for the desktop mode. Windows 11 support would be a compelling addition to it and we may implement that in the next year or so.
The Linux kernel is increasingly the elephant in the room when it comes to security and hasn't experienced anything like the massive progress made in Android's security in userspace. Piling on many more exploit mitigations to the Linux kernel won't really change this. We need to do a lot more work on it than we already do.
GrapheneOS has hardware virtualization support, which is going to be one of the ways to avoid depending so much on the Linux kernel's fragile security. The main usage for it in GrapheneOS will be running nested GrapheneOS instances for better sandboxing rather than running other operating systems. Android supports using the virtualization support to run other operating systems via the Terminal app and we have support for GUI applications, speaker, microphone and opt-in GPU acceleration backported to the Terminal app. The main use case for that app will be running desktop applications from other operating systems for the desktop mode. Windows 11 support would be a compelling addition to it and we may implement that in the next year or so.
I'd like a mobile OS where I can reuse my existing knowledge. Write software for it with Rust, Python, pipewire, systemd, Wayland, etc. Login with ssh.
No interest in Android apps or Windows (hah). (Though maybe I'll try Waydroid one of these days.)
I don't know anything about your distro, not the graphics stack or what the package manager is or even if there is one? Meanwhile my starlite tablet is awesome because it works just like my desktop Fedora or Mint, though I installed Phosh on it.
Security is nice, but not before there is even a single feasible device on the market. Librem is just barely limping along, and I mean barely with a five year old handset that was obsolete when it debuted.
If your kernel is so advanced it really should be upstreamed, so these other distros could use it and support new Pixels. Y'all working together with other mobile projects would be so much better than the current surveillance dystopia we are currently living in. Maybe it's hard, but it is incredibly important. I can help though have limits.
No interest in Android apps or Windows (hah). (Though maybe I'll try Waydroid one of these days.)
I don't know anything about your distro, not the graphics stack or what the package manager is or even if there is one? Meanwhile my starlite tablet is awesome because it works just like my desktop Fedora or Mint, though I installed Phosh on it.
Security is nice, but not before there is even a single feasible device on the market. Librem is just barely limping along, and I mean barely with a five year old handset that was obsolete when it debuted.
If your kernel is so advanced it really should be upstreamed, so these other distros could use it and support new Pixels. Y'all working together with other mobile projects would be so much better than the current surveillance dystopia we are currently living in. Maybe it's hard, but it is incredibly important. I can help though have limits.
Sounds like Android is making a microkernel out of Linux.
There are some huge drivers from companies like Broadcom and Qualcomm. There's still a massive amount of kernel driver code along with the massive amount of core kernel code. Android is the main driving force behind the push for Rust for Linux kernel drivers because Google wants all these SoC and device drivers to start being written in Rust for security reasons but also for stability too. Driver memory corruption bugs are a huge source of both security and stability issues. A majority of new code in Android releases since Android 13 has been in memory safe languages. The Linux kernel is increasingly the elephant in the room with the monolithic kernel driver (zero isolation / sandboxing within the kernel) combined with memory unsafety. It's largely the opposite of Android's extensive work to improve security in userspace. They've worked hard on getting exploit mitigations into the kernel but those tend to be much weaker than they are in a lot of userspace (browser renderer processes have similar issues).
For entire classes of applications, you can treat Linux as a black box. Things like syscalls, /proc & /sys, are all incredibly stable. So that's what Go does with its syscall package; it completely sidesteps libc, ld.so, and whenever it can, it just produces static builds - at least on Linux.
They tried to get away with it on OpenBSD, macOS, etc and got their hand chewed off.
They tried to get away with it on OpenBSD, macOS, etc and got their hand chewed off.
There are a few reasons I avoid Go, and their syscall pacakge is on the list. It breaks a bunch of tooling that requires LD_PRELOAD or static linker interposition. (One example: Interposing on the clock to test timeout logic.)
I wish they had an option that just used libc. Maybe, someday someone will add a target architecture/port that just uses posix. I’d prefer that in Linux too.
I wish they had an option that just used libc. Maybe, someday someone will add a target architecture/port that just uses posix. I’d prefer that in Linux too.
Intercept at the syscall level instead with seccomp. Like I'm doing here:
https://github.com/lukasstraub2/intercept-anything
Go is hardly the only thing where LD_PRELOAD doesn't work.
https://github.com/lukasstraub2/intercept-anything
Go is hardly the only thing where LD_PRELOAD doesn't work.
That's not Go-specific, it's just how static linking works. As nolist_policy advised, it's more useful and precise to intercept programs at the syscall (rather than library call) boundaries. Programs are free to do all sorts of insane stuff, there was e.g. a Scheme interpreter that kept growing the stack until it caught SIGSEGV, at which point it'd run a compacting GC and reset the stack pointer. ¯\_(ツ)_/¯
Regarding LD_PRELOAD, I highly doubt that this is required by POSIX. macOS (which is a certified UNIX) uses DYLD_INSERT_LIBRARIES instead. OpenBSD (which is known for their pedantic documentation) uses LD_LIBRARY_PATH, doesn't mention any standards, and refers the reader to SunOS 4.0. If this is somehow standardised, I'd love to read the actual document.
Regarding LD_PRELOAD, I highly doubt that this is required by POSIX. macOS (which is a certified UNIX) uses DYLD_INSERT_LIBRARIES instead. OpenBSD (which is known for their pedantic documentation) uses LD_LIBRARY_PATH, doesn't mention any standards, and refers the reader to SunOS 4.0. If this is somehow standardised, I'd love to read the actual document.
I installed GrapheneOS on my Pixel 4a after Google deleted the battery life[0], and while the initial move was frustrating with things not working, I've adapted and have a nice feeling of security while using my device again. It feels like it's mine, and I don't have to worry about who will spy on me or rug-pull me next.
[0] https://grapheneos.social/@GrapheneOS/113917226566692707
[0] https://grapheneos.social/@GrapheneOS/113917226566692707
Of all the selling points for GrapheneOS, I don't think battery life is one I'd highlight. Their Google Play services shim smokes my battery. Like 20-30% discharge while overnight idle kind of bad.
That's not at all normal. Sandboxed Google Play doesn't consume more batter than privileged Google Play in a standard Google Mobiles Services device. It indicates something is very wrong with your setup.
Its definitely pretty close to normal. Battery drain is probably the top mentioned drawback in any online post discussing GrapheneOS.
No, it's not at all normal. Here's a poll someone did on Mastodon with 124 anonymous responses from our community:
https://23.social/@mj1982/114210416377875387
54% Battery consumption is lower under GrapheneOS
13% Battery consumption is lower under stock Android
33% Can't tell the difference.
For users with a single profile with sandboxed Google Play installed before other apps, it should be very similar to the stock Pixel OS if you installed the dozens of Google apps they bundle on GrapheneOS and disable the various privileged apps they integrate which aren't usable on GrapheneOS. The stock OS drains more power with a typical simple setup because it has so much more installed and running. If you make it similar, it's nearly the same. If you use a more complex setup with multiple profiles and multiple push implementations on GrapheneOS, that's going to use more power. It still shouldn't drain nearly as much as you said above without something seriously wrong with the setup.
It's very easy to make battery life much worse. Using multiple push messaging implementations simultaneously is inefficient. As an example, using sandboxed Google Play in your Owner user, sandboxed Google Play in a work profile and a Private Space without it with various apps doing their own push would of course be far less efficient than a single Firebase Cloud Messaging push connection shared across the entire device. Having 2 installations of sandboxed Google Play you always keep running would be less efficient than privileged Google Play. Regular privileged Google Play shares the same processes and connections across profiles since it's built deeply into the OS and is implemented that way for efficiency like many OS services. If you compare having a single privileged Google Play vs. multiple sandboxed Google Play alongside apps doing their own push, of course privileged Google Play would be more efficient. You can use GrapheneOS with a similarly efficient setup and battery life will not be worse. You likely just have an inefficient setup. It can still be hard to narrow down what's really draining battery usage despite Android's battery stats getting much better over time.
https://23.social/@mj1982/114210416377875387
54% Battery consumption is lower under GrapheneOS
13% Battery consumption is lower under stock Android
33% Can't tell the difference.
For users with a single profile with sandboxed Google Play installed before other apps, it should be very similar to the stock Pixel OS if you installed the dozens of Google apps they bundle on GrapheneOS and disable the various privileged apps they integrate which aren't usable on GrapheneOS. The stock OS drains more power with a typical simple setup because it has so much more installed and running. If you make it similar, it's nearly the same. If you use a more complex setup with multiple profiles and multiple push implementations on GrapheneOS, that's going to use more power. It still shouldn't drain nearly as much as you said above without something seriously wrong with the setup.
It's very easy to make battery life much worse. Using multiple push messaging implementations simultaneously is inefficient. As an example, using sandboxed Google Play in your Owner user, sandboxed Google Play in a work profile and a Private Space without it with various apps doing their own push would of course be far less efficient than a single Firebase Cloud Messaging push connection shared across the entire device. Having 2 installations of sandboxed Google Play you always keep running would be less efficient than privileged Google Play. Regular privileged Google Play shares the same processes and connections across profiles since it's built deeply into the OS and is implemented that way for efficiency like many OS services. If you compare having a single privileged Google Play vs. multiple sandboxed Google Play alongside apps doing their own push, of course privileged Google Play would be more efficient. You can use GrapheneOS with a similarly efficient setup and battery life will not be worse. You likely just have an inefficient setup. It can still be hard to narrow down what's really draining battery usage despite Android's battery stats getting much better over time.
To back up your survey with a reproducible experiment:
On my 6 pro, I got 2x advertised battery life until I installed one copy of Google Play services. Then I got advertised battery life.
It should be easy enough to uninstall Google’s stuff for a week and measure battery drain, then put it back.
Even with it though, I wasn’t losing 30% overnight. There’s probably some other problem. Maybe wipe + reinstall, then try with and without the 24/7 surveillance daemons?
On my 6 pro, I got 2x advertised battery life until I installed one copy of Google Play services. Then I got advertised battery life.
It should be easy enough to uninstall Google’s stuff for a week and measure battery drain, then put it back.
Even with it though, I wasn’t losing 30% overnight. There’s probably some other problem. Maybe wipe + reinstall, then try with and without the 24/7 surveillance daemons?
I know, I had the problem when I got the Pixel. Already with the stock Android and then when installing Graphene. It took one or two weeks of tweaking until the battery life was on par with LineageOS. Not sure if I'd be able to reproduce it, but I think a combination of display settings and stand-by/background services. It's a thin line though, also making sure that Whatsapp notifications still work.
[deleted]
> deleted the battery life[0]
Such a bizarre phenomenon to me that people are still griping about a software update that stops a 4-year-old battery from detonating when the same company will also fix the phone for free or just hand you $50 if you prefer that.
Such a bizarre phenomenon to me that people are still griping about a software update that stops a 4-year-old battery from detonating when the same company will also fix the phone for free or just hand you $50 if you prefer that.
The fixing offer is only valid in some locations, would require you to be without your phone for some time, and since Android still doesn't have anything that would be considered working backup and restore, I can't imagine many people being comfortable mailing their phone out for a replacement.
The $50 "cash" offer came with so many downsides that just ignoring it would be the smarter choice for anyone who values their time (someone already provided a link).
The $50 "cash" offer came with so many downsides that just ignoring it would be the smarter choice for anyone who values their time (someone already provided a link).
> or just hand you $50 if you prefer that.
Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
They never ack'd the reason why they did it. My wife's phone was basically bricked, and the google offer for "free fix" was functionally worthless because the contracted companies wouldn't repair it. See many articles online (including ars technica editor who personally was screwed).
I just bought a replacement battery from ifixit and replaced it myself as the original battery was worn out only to now suddenly have garbage battery life on a brand new battery for no good reason.
I doubt that they'll give me any sort of money or do repairs on a phone that I opened up.
It's frustrating as I thought I would be able to get several more years of life out of this phone.
I doubt that they'll give me any sort of money or do repairs on a phone that I opened up.
It's frustrating as I thought I would be able to get several more years of life out of this phone.
I don't have any idea what the situation is here and whether it's as black and white as you paint it, but regardless, surely something as significant as this should be presented to the user as an option rather than the manufacturer deciding for you that your phone that you own and paid for should now be unusable?
[deleted]
I was never even notified for my 4a and when I try to check it's eligibility it simply says my pixel 4a "is not eligible for a repair, cash payment, or discount." without any additional information.
Does this mean my pixel 4a battery was unaffected for some reason... or simply that the lawyers managed to weasel out of paying 100% of active pixel 4a owners back and my phone is still dangerous or degraded? ¯\_(ツ)_/¯
Does this mean my pixel 4a battery was unaffected for some reason... or simply that the lawyers managed to weasel out of paying 100% of active pixel 4a owners back and my phone is still dangerous or degraded? ¯\_(ツ)_/¯
Yes, not all 4a's were affected. Of two of mine, one was eligible, but the other was not.
Yeah it's really great, before switching to GrapheneOS I used LineageOS for years so battery life is already good in that case. But the whole access control, and checking every few months which apps are hardly used is just super practical. I don't do online banking on my phone though, I guess for people who do it's not feasible. The only thing I don't like is that it only works with Google Pixels
Online banking (anecdotally) works great, though may use the sandboxed google play services. At least here in Switzerland with Swiss banking apps I've never had issues with it.
I would recommend people to install the play services and play store in the main profile. Then, install apps in the main profile too but remove all permissions and abilities, restrict and disable them. After that, enable them in a "banking" profile. One can then selectively enable and disable the play store to update these apps which propagate to the other profiles. The disabled apps are still updated normally by the play store.
I do believe that they are working on a feature to limit app intercommunication in a similar vein as the other scopes. This would be cool because it would allow one to allow "point to point" communication of certain apps with the play services but otherwise restrict them. Though I don't know the state of development for this feature.
I would recommend people to install the play services and play store in the main profile. Then, install apps in the main profile too but remove all permissions and abilities, restrict and disable them. After that, enable them in a "banking" profile. One can then selectively enable and disable the play store to update these apps which propagate to the other profiles. The disabled apps are still updated normally by the play store.
I do believe that they are working on a feature to limit app intercommunication in a similar vein as the other scopes. This would be cool because it would allow one to allow "point to point" communication of certain apps with the play services but otherwise restrict them. Though I don't know the state of development for this feature.
I think GrapheneOS is one of the most important projects going. Many people walk around with all-purpose spying devices in their pocket, oblivious to how much power they are giving up. They have no control over these devices, and they don't even understand.
GrapheneOS gives us a way to resist. The convenience of having a modern phone is hard to give up, and with GrapheneOS you can have 90% of that convenience while reducing much of the surveillance and attack surface. Now, we just need a pixel phone with two big hardware switches, sliders on each side of the phone: one kills the radios, and the other kills the sensors (cameras, microphones). When you want to take a call, just flip the big slider switch up to activate cameras and mics.
Thank you to strcat and the rest of the team! If you don't use GrapheneOS, I would consider it. You can donate here: https://grapheneos.org/donate And if you have the right kind of programming skills, why not help out?
GrapheneOS gives us a way to resist. The convenience of having a modern phone is hard to give up, and with GrapheneOS you can have 90% of that convenience while reducing much of the surveillance and attack surface. Now, we just need a pixel phone with two big hardware switches, sliders on each side of the phone: one kills the radios, and the other kills the sensors (cameras, microphones). When you want to take a call, just flip the big slider switch up to activate cameras and mics.
Thank you to strcat and the rest of the team! If you don't use GrapheneOS, I would consider it. You can donate here: https://grapheneos.org/donate And if you have the right kind of programming skills, why not help out?
We plan to include a sensor kill switch on our own future hardware but the value is lower than most people believe on one of their primary computing devices. If it was successfully exploited, an attacker would get all of the data including documents, photos, videos, browser history, login sessions, passwords and much more. They'd also have control of the sensors whenever they're enabled including any calls, etc.
A kill switch for all of the radios is much less useful for this threat model because even regular apps know how to queue up all their data for later usage. If the goal is preventing detection location detection, that really requires disabling all the radios and sensors rather than just radios. If the goal is dealing with an attacker able to exploit radio firmware but not the OS from there due to the IOMMU isolation and hardened kernel/userspace drivers in GrapheneOS, that could potentially be useful, but they'd already lose access on a reboot as long as it power cycled the radio as long as the radio doesn't have any significant persistent state due to verified boot.
A kill switch for all of the radios is much less useful for this threat model because even regular apps know how to queue up all their data for later usage. If the goal is preventing detection location detection, that really requires disabling all the radios and sensors rather than just radios. If the goal is dealing with an attacker able to exploit radio firmware but not the OS from there due to the IOMMU isolation and hardened kernel/userspace drivers in GrapheneOS, that could potentially be useful, but they'd already lose access on a reboot as long as it power cycled the radio as long as the radio doesn't have any significant persistent state due to verified boot.
Thanks for the thoughtful reply!
One of the advantages of hardware kill switches, shutters on cameras, and the like is social signaling: other people can see them, and can see them being used. If I put my mass-manufactured phone on the table, and you can see the hardware sensors switch is "off", you can be quite sure I'm not recording you.
I think there's a chance for us to normalize this sort of thing, and make it table stakes for a lot of interactions. In a meeting room and there isn't a shutter on the camera? That's breaking the rules and we need to find one. And so on.
Relevant to this discussion, another thought I had is location- and QoS-aware enabling and disabling of the cell radios so I'm using wifi whenever I can, automatically. If I have a good internet connection other than through the cell radio, the cell radio is shut off.
Thank you again for your thoughtful reply and your work.
One of the advantages of hardware kill switches, shutters on cameras, and the like is social signaling: other people can see them, and can see them being used. If I put my mass-manufactured phone on the table, and you can see the hardware sensors switch is "off", you can be quite sure I'm not recording you.
I think there's a chance for us to normalize this sort of thing, and make it table stakes for a lot of interactions. In a meeting room and there isn't a shutter on the camera? That's breaking the rules and we need to find one. And so on.
Relevant to this discussion, another thought I had is location- and QoS-aware enabling and disabling of the cell radios so I'm using wifi whenever I can, automatically. If I have a good internet connection other than through the cell radio, the cell radio is shut off.
Thank you again for your thoughtful reply and your work.
How "private" is graphene?
How much do I gain from switching to it instead of say, remaining on the Stock Android?
Edit: This looks comprehensive — https://staging.grapheneos.org/features
How much do I gain from switching to it instead of say, remaining on the Stock Android?
Edit: This looks comprehensive — https://staging.grapheneos.org/features
It's extremely private. It doesn't have Google services by default, but makes it easy to install them as unprivileged apps that - apart from giving you more control over what they can do and limiting certain access by default - work mostly exactly the same way as their privileged installs on other versions of Android. It also lets you disable Internet access privileges to any app that you don't want to have phone home.
Beyond that, most of the other advantages will be less visible. They have hardened memory allocators that make various classes of security beaches significantly more difficult. There's a lot less superfluous background services eating resources. All that and more are listed on their website. It's well worth a read.
Beyond that, most of the other advantages will be less visible. They have hardened memory allocators that make various classes of security beaches significantly more difficult. There's a lot less superfluous background services eating resources. All that and more are listed on their website. It's well worth a read.
That sounds really good. What are the downsides? How does it fare in terms of PlayIntegrity and SafetyNet etc?
I may be wrong but I think most bank apps won't run on those devices. Anyone can confirm ?
I can't say for "most" apps but I've never had any issue with banking nor digital identity apps.
Same here, no problems. You can run Google Play Services and Google apps sandboxed using the built-in GrapheneOS App Store. There's nothing like it.
I wouldn't say most, but a large portion. You should be able to look up in advance which ones are funny about custom roms, the key words are safetynet or play integrety api.
My solution to this is put the bank apps that are annoying about it on an old phone (I knew I'd find a use for one eventually!)
My solution to this is put the bank apps that are annoying about it on an old phone (I knew I'd find a use for one eventually!)
YMMV. I'm on mobile but I think someone maintains a wiki page of compatibility.
Remarkably, Nationwide (UK) runs perfectly even without Google services. (Except it doesn't poll for payment confirmations but that's understandable. They're always fetched when you open the app though. Or it could be my setup). It's actually quite shocking and it speaks to Nationwide as being a decent organisation.
It's also not necessarily a downside. Having your banking app on your phone can be a risk of you often take your phone out in public
The absolute blocker is Google Pay. That isn't supported
Remarkably, Nationwide (UK) runs perfectly even without Google services. (Except it doesn't poll for payment confirmations but that's understandable. They're always fetched when you open the app though. Or it could be my setup). It's actually quite shocking and it speaks to Nationwide as being a decent organisation.
It's also not necessarily a downside. Having your banking app on your phone can be a risk of you often take your phone out in public
The absolute blocker is Google Pay. That isn't supported
Here it is:
https://privsec.dev/posts/android/banking-applications-compa...
with its github backend
https://github.com/PrivSec-dev/banking-apps-compat-report
If you are in Europe, Curve recently enabled mobile payments without Google Pay, and that might solve the issue (but I haven't tried it myself).
Some app that don't work because they require strong integrity are listed here: https://grapheneos.org/articles/attestation-compatibility-gu...
https://privsec.dev/posts/android/banking-applications-compa...
with its github backend
https://github.com/PrivSec-dev/banking-apps-compat-report
If you are in Europe, Curve recently enabled mobile payments without Google Pay, and that might solve the issue (but I haven't tried it myself).
Some app that don't work because they require strong integrity are listed here: https://grapheneos.org/articles/attestation-compatibility-gu...
> Curve recently enabled mobile payments without Google Pay,
This could be very useful. My Google skills came up short. Do you have a link?
This could be very useful. My Google skills came up short. Do you have a link?
Not sure my search engine skills are any better but here are a few links:
From 2 years ago: https://www.reddit.com/r/GrapheneOS/comments/126nd51/comment... -> Sounds like Curve (without Google Pay) wasn't officially supported in Europe and didn't work for most people.
However, this seems to have changed a couple days ago:
https://www.reddit.com/r/curve/comments/17txz6u/comment/mkwl...
https://discuss.grapheneos.org/d/443-gpay-alternatives-for-g...
https://discuss.grapheneos.org/d/475-wallet-google-pay/105
https://discuss.privacyguides.net/t/curve-pay-available-as-a...
This is in line with an interview with the CEO of Curve from last month, https://paymentsconsulting.com/qa-with-shachar-bialick-at-cu...
> We are launching Curve Pay in beta for Android soon and plan to release it on iOS thereafter. This will allow customers to use Curve as their default wallet, just like Apple Pay or Google Pay.
…and with various German news sites reporting that Curve Pay is now available in Germany (and likely other parts of the EEA).
From 2 years ago: https://www.reddit.com/r/GrapheneOS/comments/126nd51/comment... -> Sounds like Curve (without Google Pay) wasn't officially supported in Europe and didn't work for most people.
However, this seems to have changed a couple days ago:
https://www.reddit.com/r/curve/comments/17txz6u/comment/mkwl...
https://discuss.grapheneos.org/d/443-gpay-alternatives-for-g...
https://discuss.grapheneos.org/d/475-wallet-google-pay/105
https://discuss.privacyguides.net/t/curve-pay-available-as-a...
This is in line with an interview with the CEO of Curve from last month, https://paymentsconsulting.com/qa-with-shachar-bialick-at-cu...
> We are launching Curve Pay in beta for Android soon and plan to release it on iOS thereafter. This will allow customers to use Curve as their default wallet, just like Apple Pay or Google Pay.
…and with various German news sites reporting that Curve Pay is now available in Germany (and likely other parts of the EEA).
Great thanks for linking! I'm sleep deprived and was being lazy.
Awesome to read the support chat from nationwide saying it's explicitly supported. I figured as it works so well.
They're a very decent building society/bank if anyone is looking for a new one!
Awesome to read the support chat from nationwide saying it's explicitly supported. I figured as it works so well.
They're a very decent building society/bank if anyone is looking for a new one!
I'm in Switzerland, and both Neon (Hypothekarbank Lenzburg) and Zak (Banque CLER) work perfectly fine.
Google Wallet does not work, therefore I cannot use my phone to pay wirelessly with my Neon card, which is a shame.
The only apps I had trouble with were Twint (had to install it with F-Droid, as Play kept telling me it was not compatible with my device), and... the McDonald's app (which forces me to move my fat ass to one of their kiosks to order my food instead of doing it from the table).
Google Wallet does not work, therefore I cannot use my phone to pay wirelessly with my Neon card, which is a shame.
The only apps I had trouble with were Twint (had to install it with F-Droid, as Play kept telling me it was not compatible with my device), and... the McDonald's app (which forces me to move my fat ass to one of their kiosks to order my food instead of doing it from the table).
As a GrapheneOS user I can speak of my experience: the app for my bank was working fine until 2 months ago, when after an upgrade it stopped working because of Integration API.
I will contact them to try to get them to support GrapheneOS, but I will not be holding my breath. I uninstalled it in the meantime and use my computer. If they ever require the app I would likely switch to a different bank.
I will contact them to try to get them to support GrapheneOS, but I will not be holding my breath. I uninstalled it in the meantime and use my computer. If they ever require the app I would likely switch to a different bank.
https://privsec.dev/posts/android/banking-applications-compa...
Many seem to work, if you apply some tweaks. Google Wallet NFC payments totally don't, I believe.
Many seem to work, if you apply some tweaks. Google Wallet NFC payments totally don't, I believe.
All bank apps I've tried works.
Which, I mean, I'm willing to buy that, but it would be helpful if you named names.
There's a crowd-sourced list of banking apps known to work on GOS at <https://privsec.dev/posts/android/banking-applications-compa...>.
[deleted]
Balatro is not installable from the Play Store on my Pixel 7 due to Play Integrity.
Side note, balatro-mobile-maker works really well as an unofficial port to Android. https://github.com/blake502/balatro-mobile-maker
Side note, balatro-mobile-maker works really well as an unofficial port to Android. https://github.com/blake502/balatro-mobile-maker
One downside (that may be a very manageable one) is limited device support (which enables all that).
The features page you've linked is the best place to look for an overview of what we provide. It lists what we change and add compared to the latest release of the Android Open Source Project or the stock Pixel OS. Lots of important features are listed together in a single section, particularly in the exploit protection section / sub-sections covering a huge portion of what we provide in terms of security. It covers most of what we provide other than assorted smaller changes. Also worth noting we remove features from the list when they become standard Android features, and we successfully got various features we implemented into the Linux kernel or Android Open Source Project.
Here's an example demonstrating the impact of our security improvements:
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
February 2025 Cellebrite Premium documentation was posted by someone further down in the thread, which is essentially the same overall situation.
https://discuss.grapheneos.org/d/20401-grapheneos-improvemen... has some details on how we've improved that since early 2024.
The stock Pixel OS is approximately AOSP with a bunch of Google apps deeply integrated into it. Pixels don't actually change anything compared to the AOSP code, they just substitute various components with their own and add a bunch of overlays, apps, etc. AOSP has all the stuff they need to provide that included already. They give extensive privileged access to Google Play and various other apps via privileged permissions, SELinux MAC/MLS policy (which is included in AOSP) and various allowlisting, etc. They also use Play services, etc. as backends for various AOSP APIs. One of our major features is our sandboxed Google Play compatibility layer enabling running Google Play services, Google Play Store, Google Search, etc. as regular sandboxed apps with no special access at all where users don't even need to grant them the regular non-privileged permissions like Contacts, Location, etc. to use most of their functionality (some functionality requires that such as if you wanted to use Google Maps location sharing or Google Contacts sync).
Here's an example demonstrating the impact of our security improvements:
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
February 2025 Cellebrite Premium documentation was posted by someone further down in the thread, which is essentially the same overall situation.
https://discuss.grapheneos.org/d/20401-grapheneos-improvemen... has some details on how we've improved that since early 2024.
The stock Pixel OS is approximately AOSP with a bunch of Google apps deeply integrated into it. Pixels don't actually change anything compared to the AOSP code, they just substitute various components with their own and add a bunch of overlays, apps, etc. AOSP has all the stuff they need to provide that included already. They give extensive privileged access to Google Play and various other apps via privileged permissions, SELinux MAC/MLS policy (which is included in AOSP) and various allowlisting, etc. They also use Play services, etc. as backends for various AOSP APIs. One of our major features is our sandboxed Google Play compatibility layer enabling running Google Play services, Google Play Store, Google Search, etc. as regular sandboxed apps with no special access at all where users don't even need to grant them the regular non-privileged permissions like Contacts, Location, etc. to use most of their functionality (some functionality requires that such as if you wanted to use Google Maps location sharing or Google Contacts sync).
Do you think you are target (idk, by maybe three letter agencies or black hat groups) for the work you do? Do you have any special OPSEC to account for something like this?
Graphene is not for everyday casual users. It really only works well if you don't rely on any apps that depend on Google play, like steam or discord. If you're on AT&T, you don't get caller ID or voicemail.
This is an OS for people who care more about privacy and security than having an everyday usable phone. It is very much not for normal people.
This is an OS for people who care more about privacy and security than having an everyday usable phone. It is very much not for normal people.
> Graphene is not for everyday casual users.
GrapheneOS is intended for everyone.
> It really only works well if you don't rely on any apps that depend on Google play, like steam or discord.
Steam, Discord and the vast majority of Android apps work perfectly on GrapheneOS. Sandboxed Google Play is a robust feature which works very well. If you're choosing to completely avoid using Google Play, that's your choice. Steam and Discord both still likely work without it, but without push notifications since they have no alternative to FCM as certain other apps do.
> If you're on AT&T, you don't get caller ID or voicemail.
You do get caller ID and voicemail on AT&T. Visual voicemail doesn't work with AT&T with the built-in Dialer app because it uses a protocol not supported by AOSP. It does work with Google Dialer based on user feedback on our forum.
> This is an OS for people who care more about privacy and security than having an everyday usable phone. It is very much not for normal people.
GrapheneOS is very usable as an every day usage phone for regular people. Nearly every Android app can be used on it. It sounds like you were choosing to use it without sandboxed Google Play, which is a choice to have a more limited app and service ecosystem. That's not the same as a choice to use GrapheneOS. It can be used like a regular Android phone with 1 profile containing sandboxed Google Play, or people can use sandboxed Google Play in a specific profile with most of their apps in another profile. Using it without sandboxed Google Play in a secondary profile is something many GrapheneOS users do successfully but it's in no way required or expected. We wouldn't have made that huge feature if we didn't want it to be used by a lot of people.
GrapheneOS is intended for everyone.
> It really only works well if you don't rely on any apps that depend on Google play, like steam or discord.
Steam, Discord and the vast majority of Android apps work perfectly on GrapheneOS. Sandboxed Google Play is a robust feature which works very well. If you're choosing to completely avoid using Google Play, that's your choice. Steam and Discord both still likely work without it, but without push notifications since they have no alternative to FCM as certain other apps do.
> If you're on AT&T, you don't get caller ID or voicemail.
You do get caller ID and voicemail on AT&T. Visual voicemail doesn't work with AT&T with the built-in Dialer app because it uses a protocol not supported by AOSP. It does work with Google Dialer based on user feedback on our forum.
> This is an OS for people who care more about privacy and security than having an everyday usable phone. It is very much not for normal people.
GrapheneOS is very usable as an every day usage phone for regular people. Nearly every Android app can be used on it. It sounds like you were choosing to use it without sandboxed Google Play, which is a choice to have a more limited app and service ecosystem. That's not the same as a choice to use GrapheneOS. It can be used like a regular Android phone with 1 profile containing sandboxed Google Play, or people can use sandboxed Google Play in a specific profile with most of their apps in another profile. Using it without sandboxed Google Play in a secondary profile is something many GrapheneOS users do successfully but it's in no way required or expected. We wouldn't have made that huge feature if we didn't want it to be used by a lot of people.
Steam app crashes unless Play services are active. Discord doesn't deliver push notifications without play services running. A good fraction of play store apps fail to work properly unless you let play services run in the background forever, which defeats the purpose.
You do not get caller id on AT&T, and you do not get voicemail notifications until sometimes hours or days after the fact. I ran this on my pixel 8 for months. I had to actively call into my voicemail number like it's 2005.
The secondary profile stuff is just about useless. It's one step above having multiple independent devices. I did try having a Google profile, but you can't get notifications between profiles. You get a notification that there is a notification, so you then have to go through the entire 30 second process of switching profiles, which disconnects your Bluetooth headphones to check the other profile.
If you think regular users and normal people want to put up with this, you should really re-evaluate what you think an average user is. This is for hyper nerds who care more about security ideals than functionality. Graphene is not for the average person who wants caller id, voicemail, camera, and a web browser.
You do not get caller id on AT&T, and you do not get voicemail notifications until sometimes hours or days after the fact. I ran this on my pixel 8 for months. I had to actively call into my voicemail number like it's 2005.
The secondary profile stuff is just about useless. It's one step above having multiple independent devices. I did try having a Google profile, but you can't get notifications between profiles. You get a notification that there is a notification, so you then have to go through the entire 30 second process of switching profiles, which disconnects your Bluetooth headphones to check the other profile.
If you think regular users and normal people want to put up with this, you should really re-evaluate what you think an average user is. This is for hyper nerds who care more about security ideals than functionality. Graphene is not for the average person who wants caller id, voicemail, camera, and a web browser.
Not sure if you've used GrapheneOS recently? If apps are heavily tied to Google Play Services you can install that and, in the vast majority of cases, get very good compatibility.
Compatibility with carriers also improved a lot a few years ago. Configurations for most carriers are pulled in from the stock Pixel OS. Some US carriers do weird things that depend upon having highly privileged apps bundled into the OS which, for security reasons, GrapheneOS doesnt include. I dont recall AT&T being one of them.
GrapheneOS is very usable and fine as a everyday phone for normal people.
Compatibility with carriers also improved a lot a few years ago. Configurations for most carriers are pulled in from the stock Pixel OS. Some US carriers do weird things that depend upon having highly privileged apps bundled into the OS which, for security reasons, GrapheneOS doesnt include. I dont recall AT&T being one of them.
GrapheneOS is very usable and fine as a everyday phone for normal people.
Six months ago on a pixel 8.
It is not usable for normal people who want to use their phone to stay in contact with others.
It is not usable for normal people who want to use their phone to stay in contact with others.
I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own.
Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.
Graphene thinks you can't be trusted with your own device. But don't worry, they definitely know what's best for you and it's a totally different kind of control from what Google has. Really, just trust them, it's totally fine, promise.
I switched to Lineage after a few months.
Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.
Graphene thinks you can't be trusted with your own device. But don't worry, they definitely know what's best for you and it's a totally different kind of control from what Google has. Really, just trust them, it's totally fine, promise.
I switched to Lineage after a few months.
>I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own.
What specific ways do you feel are "more locked down" than stock? It's not recommended, but you can install magisk + root if you really wanted to. It won't try to prevent you.
>Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.
That's fine. The homepage of grapheneos says:
"The private and secure mobile operating system with Android app compatibility"
Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed? A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.
What specific ways do you feel are "more locked down" than stock? It's not recommended, but you can install magisk + root if you really wanted to. It won't try to prevent you.
>Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.
That's fine. The homepage of grapheneos says:
"The private and secure mobile operating system with Android app compatibility"
Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed? A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.
> Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed?
Absolutely not.
> A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.
In both cases, yes, a user may choose to bypass a security measure. In most threat models, that's fine. If malware needs me to give it permission to compromise the system, I consider that a secure system.
Absolutely not.
> A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.
In both cases, yes, a user may choose to bypass a security measure. In most threat models, that's fine. If malware needs me to give it permission to compromise the system, I consider that a secure system.
> Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed?
Absolutely not. With that logic, Google shouldn't allow people a say in what ROM it runs but I think the people in this thread are rather happy with having such choices
Absolutely not. With that logic, Google shouldn't allow people a say in what ROM it runs but I think the people in this thread are rather happy with having such choices
> "security" and "giving users a say in how their phone works" are diametrically opposed
Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there.
I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs, don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone. They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.
> It's not recommended, but you can install magisk + root if you really wanted to.
Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.
FWIW I don't agree with the OP, just replying to your comment in particular.
Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there.
I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs, don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone. They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.
> It's not recommended, but you can install magisk + root if you really wanted to.
Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.
FWIW I don't agree with the OP, just replying to your comment in particular.
> Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there.
We don't reduce the functionality or configuration of AOSP.
> I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs
The overall audience using it is not super technical. The community of people active in the chat rooms on Matrix and Discord really doesn't reflect the overall userbase. There are around 300k people using it, who largely went out of the way to purchase a phone for it and then installed it via the web installer. Many people also purchase devices with it preinstalled.
It's easy to use and we're focused on making it easier including filling in gaps like the recently added network location support which will be added to the initial setup wizard.
We also protect against a lot more than sophisticated targeted attacks against someone.
> don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone.
GrapheneOS exists to provide a high level of privacy and security while maintaining usability and app compatibility. It's working towards being as usable as the stock Pixel OS. It's meant to be an OS for everyone, we just don't have unlimited resources to quickly build most of the things we want. It has never been aimed at power users tinkering with and customizing their device. The level of functionality and usability we want to provide is the stock Pixel OS experience. Features unrelated to privacy or security which are not present in the stock Pixel OS are mostly out of scope.
> They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.
Software being open source doesn't mean it's trustworthy or privacy respecting. Running everything without basics like a strong app sandbox and permission model isn't a good idea on a desktop either. Linux doesn't imply not having a strong application security model.
Supporting and normalizing applications depending on having incredibly invasive access where they can access all of the user's sensitive data, etc. is the opposite of what we want to do. We don't see apps being able to request more invasive permissions and refusing to work without them as user control. User control is being able to avoid that without the app knowing. Giving root access to a huge portion of the OS and to apps is the opposite of what we're building. You seem to want GrapheneOS to be something it's not for an audience that it's not targeting. We never said GrapheneOS is for power users who want to have a bunch of customization and to grant more invasive access to apps.
GrapheneOS supports hardware-based virtualization across all the supported devices and that's the way people will be able to more freely do things like software development without compromising the security of the base OS.
> Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.
Those apps wouldn't be willing to support GrapheneOS if we didn't maintain the standard security model. We're already going to be pushing the limits of what some apps will tolerate via our alternatives to permissions, etc. but we don't plan to eliminate parts of the security model. At the moment, nearly every app using the Play Integrity API would be willing to support GrapheneOS if they understood what it was and that they could verify it. It's an issue with lack of knowledge and unwillingness to do extra work for it rather than any apps actually wanting to ban GrapheneOS. It's something which can be addressed but it will get worse before it gets better as apps adopt the Play Integrity API. Growing the userbase by an order of magnitude or more will help solve this. Apps using the Play Integrity API are already feeling increasing pressure to permit using it and several have done so recently.
We don't reduce the functionality or configuration of AOSP.
> I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs
The overall audience using it is not super technical. The community of people active in the chat rooms on Matrix and Discord really doesn't reflect the overall userbase. There are around 300k people using it, who largely went out of the way to purchase a phone for it and then installed it via the web installer. Many people also purchase devices with it preinstalled.
It's easy to use and we're focused on making it easier including filling in gaps like the recently added network location support which will be added to the initial setup wizard.
We also protect against a lot more than sophisticated targeted attacks against someone.
> don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone.
GrapheneOS exists to provide a high level of privacy and security while maintaining usability and app compatibility. It's working towards being as usable as the stock Pixel OS. It's meant to be an OS for everyone, we just don't have unlimited resources to quickly build most of the things we want. It has never been aimed at power users tinkering with and customizing their device. The level of functionality and usability we want to provide is the stock Pixel OS experience. Features unrelated to privacy or security which are not present in the stock Pixel OS are mostly out of scope.
> They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.
Software being open source doesn't mean it's trustworthy or privacy respecting. Running everything without basics like a strong app sandbox and permission model isn't a good idea on a desktop either. Linux doesn't imply not having a strong application security model.
Supporting and normalizing applications depending on having incredibly invasive access where they can access all of the user's sensitive data, etc. is the opposite of what we want to do. We don't see apps being able to request more invasive permissions and refusing to work without them as user control. User control is being able to avoid that without the app knowing. Giving root access to a huge portion of the OS and to apps is the opposite of what we're building. You seem to want GrapheneOS to be something it's not for an audience that it's not targeting. We never said GrapheneOS is for power users who want to have a bunch of customization and to grant more invasive access to apps.
GrapheneOS supports hardware-based virtualization across all the supported devices and that's the way people will be able to more freely do things like software development without compromising the security of the base OS.
> Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.
Those apps wouldn't be willing to support GrapheneOS if we didn't maintain the standard security model. We're already going to be pushing the limits of what some apps will tolerate via our alternatives to permissions, etc. but we don't plan to eliminate parts of the security model. At the moment, nearly every app using the Play Integrity API would be willing to support GrapheneOS if they understood what it was and that they could verify it. It's an issue with lack of knowledge and unwillingness to do extra work for it rather than any apps actually wanting to ban GrapheneOS. It's something which can be addressed but it will get worse before it gets better as apps adopt the Play Integrity API. Growing the userbase by an order of magnitude or more will help solve this. Apps using the Play Integrity API are already feeling increasing pressure to permit using it and several have done so recently.
Thanks for your thought-provoking response. I agree with most of it.
The vibe I generally get from Graphene users is that they feel that they are taking control over their device by installing Graphene onto it (which is almost always a manual process, at least for now). I probably exaggerated when I said the vast majority of users care deeply about this, but I think it's still a major selling point of Graphene for a lot of people.
And yes, I do agree that sandboxing actually provides more control to the user, not less! I'd just hate to see Graphene become more like iOS over time and start intentionally omitting features that would otherwise empower the user, for security's sake. If "security" and "giving users a say in how their phone works" really are diametrically opposed, and user freedom isn't a concern, then it would probably make sense to start gutting out stuff like developer mode, adb, and sideloading for the user's own safety. But the project's track record has been pretty good so far from what I can tell, and I don't think this will happen.
The vibe I generally get from Graphene users is that they feel that they are taking control over their device by installing Graphene onto it (which is almost always a manual process, at least for now). I probably exaggerated when I said the vast majority of users care deeply about this, but I think it's still a major selling point of Graphene for a lot of people.
And yes, I do agree that sandboxing actually provides more control to the user, not less! I'd just hate to see Graphene become more like iOS over time and start intentionally omitting features that would otherwise empower the user, for security's sake. If "security" and "giving users a say in how their phone works" really are diametrically opposed, and user freedom isn't a concern, then it would probably make sense to start gutting out stuff like developer mode, adb, and sideloading for the user's own safety. But the project's track record has been pretty good so far from what I can tell, and I don't think this will happen.
In general, we don't remove functionality. An exception is if something is explicitly insecure and has no reasonable use case. We removed support for instant apps, booting a Google signed GSI, adding new users while locked and pattern lock.
In very rare cases, someone complains about the removal of pattern lock, but it's a terrible feature and shouldn't be included in modern Android. It's a much worse variant of a PIN which gives people a false sense of security and encourages choosing an insecure lock method. We also didn't want to support it for our duress PIN/password feature or our upcoming random PIN/password generation feature. It's not really suited to either of those things. Pattern lock is genuinely an awful feature and shouldn't be included in modern Android, but they don't want to upset people by removing it. Extremely few people care that we remove it, and we've helped them by getting them to use a PIN instead especially if they use a proper random PIN.
> developer mode, adb, and sideloading
These things can be disabled with a device management app already, if what you mean by sideloading is installing apps via an APK or arbitrary app store. Sideloading an OS update to recovery has all of the usual signature verification and downgrade protection.
In very rare cases, someone complains about the removal of pattern lock, but it's a terrible feature and shouldn't be included in modern Android. It's a much worse variant of a PIN which gives people a false sense of security and encourages choosing an insecure lock method. We also didn't want to support it for our duress PIN/password feature or our upcoming random PIN/password generation feature. It's not really suited to either of those things. Pattern lock is genuinely an awful feature and shouldn't be included in modern Android, but they don't want to upset people by removing it. Extremely few people care that we remove it, and we've helped them by getting them to use a PIN instead especially if they use a proper random PIN.
> developer mode, adb, and sideloading
These things can be disabled with a device management app already, if what you mean by sideloading is installing apps via an APK or arbitrary app store. Sideloading an OS update to recovery has all of the usual signature verification and downgrade protection.
I installed GrapheneOS on a spare Pixel 4a recently...through a browser window. I thought at first that I had to download a firmware flasher or something, but no, it updated the device from that webpage! That was impressive.
The other thing I would like to mention: Chromium is installed, so PWAs can be installed instead of connecting to a sandboxed google play or something. The PWAs I tried looked just like on an iPhone or desktop. Yes, we are far, far away from PWAs being a complete replacement. But it is in theory possible:
An independent mobile OS with platform-independent apps. No Apple/Google ID needed, no appstores. That was the point of this test install, and it worked.
An independent mobile OS with platform-independent apps. No Apple/Google ID needed, no appstores. That was the point of this test install, and it worked.
One cool thing about GrapheneOS when I recently got a new Pixel 9 was how easy it was to install it with just my older Pixel phone. Because the installer is WebUSB based it works in the Vanadium browser. I just connected the two phones together with a USB cable and could install the OS on my new phone from the browser.
One currently missing thing is a "transfer" or backup functionality otherwise. There's really no good solution other than to manually port over applications and use their built-in import/export features if available.
One currently missing thing is a "transfer" or backup functionality otherwise. There's really no good solution other than to manually port over applications and use their built-in import/export features if available.
There's a built-in encrypted backup system in Settings > System > Backup. It works similarly to the Google Play device-to-device transfer system. It uses the same underlying device-to-device transfer mode for the Android backup infrastructure and should back up exactly the same data as the Google Play transfer system moves. It backs up a lot more than Google Play cloud backups because it uses device-to-device mode.
So, is the current recommendation to create such a backup to an external storage and then restore it on a new device? There is currently no direct device-to-device transfer feature using this, correct?
We should normalize having a "sceenshot" menu in the navigation again. Not their social, website has any. Is this a text based operating system?
GrapheneOS looks almost exactly like AOSP and doesn't add any visual features, so screenshots would be somewhat pointless.
It would answer my question properly if I'd seen that it looks just like the stock Android UI, so even though it's almost exactly the same, that's still quite valuable for me rather than pointless.
I've also done some image search and it does change a bit with apps and they look quite good. So I'm still baffled why this aversion to images is decided. Or just overlooked maybe?
I've also done some image search and it does change a bit with apps and they look quite good. So I'm still baffled why this aversion to images is decided. Or just overlooked maybe?
Probably just overlooked, yes.
> it does change a bit with apps and they look quite good
Hmm, I haven't noticed any difference. Which apps are you referring to?
> it does change a bit with apps and they look quite good
Hmm, I haven't noticed any difference. Which apps are you referring to?
In this article there are a few screenshots with grayscale icons:
https://9to5google.com/2024/04/16/grapheneos-review-de-googl...
Is that the default?
Is that the default?
Our own apps and the currently basic forks of Android Open Source Project sample apps use black, white and gray as their icon color scheme. It's similar to how other organizations choose a few colors for their apps. The icons aren't grayscale, those are just the current colors we use for our own.
No, the grayscale icons are for built-in GrapheneOS apps only. Non-GOS apps look as they would on any other phone.
It's still a custom ROM and it's not uncommon for those to be reskinned in interesting or weird ways. Plus, their website already uses the outline of a phone with their logo inside of it, why not make that a screenshot of their ROM with their logo as a background?
Furthermore, I'm interested in what their solution for email, calendars, and all the other Google services look like. If it's AOSP, that's a good reason not to use this ROM. I suspect it's not actually using AOSP's apps, though.
Furthermore, I'm interested in what their solution for email, calendars, and all the other Google services look like. If it's AOSP, that's a good reason not to use this ROM. I suspect it's not actually using AOSP's apps, though.
> Furthermore, I'm interested in what their solution for email, calendars, and all the other Google services look like.
There are no built-in apps for that. The only custom apps GOS provides are Auditor (https://attestation.app/), Camera, Calculator¹, Contacts¹, Files¹, Gallery¹, Messaging¹, a hardened PDF viewer, and Vanadium (a hardened version of Chromium). Everything else is up to you.
¹) AOSP app or fork of the AOSP app.
There are no built-in apps for that. The only custom apps GOS provides are Auditor (https://attestation.app/), Camera, Calculator¹, Contacts¹, Files¹, Gallery¹, Messaging¹, a hardened PDF viewer, and Vanadium (a hardened version of Chromium). Everything else is up to you.
¹) AOSP app or fork of the AOSP app.
I've been eying GrapheneOS for a few years. But there is one thing holding me back, Auto Call Recording.
I'd love to make the switch.
I'd love to make the switch.
It's a planned feature but isn't a high priority. It's hard for us to get to it with all the other things we want to implement. We'll add it one day. We need to keep hiring more developers and expanding to do more.
I have a question you may be able to answer. Are contributions to GrapheneOS in general welcome? If yes, where would one start, is there a page about setting up a development environment or outlining a list of features/areas that could need work/help? I have quite a few spare Pixel phones that are currently just idling but I'd love to try building and installing GOS myself to start out.
I use ACR Phone app with the APH app and removed Network permissions.
Does it record 2-way audio in good quality?
Ear & speaker & Bluetooth
It uses the phone's microphone (Android OS limitation), so if it's Bluetooth in the car, it should pick up everything (just like the people in the next car over can hear your conversation, fyi), but if it's a Bluetooth headset, I don't think it will pick up their side.
Audio quality is very good. By all means test it out in different configurations before relying on it.
A native implementation would still be better. I hope the GrapheneOS devs can pull it off.
Audio quality is very good. By all means test it out in different configurations before relying on it.
A native implementation would still be better. I hope the GrapheneOS devs can pull it off.
The Pixel 9a is really tempting for someone like me who’s tired of living in Apple’s walled garden (1), but wants a decent device at a fair price that’ll be supported for a good long time - the Pixel 9a ticks all of those boxes.
1: Why? File management and getting files into apps is the #1 area where Android wins.
For example, iOS has me copying or saving audiobooks into a folder only to import them into BookPlayer, whereas Android’s Smart Audiobook Player lets me copy my book to my audiobooks folder and hit ‘rescan’.
Funnily enough, one of the only music apps on iOS that offers the same functionality - copy a folder into your library and rescan - is the same Neutron Player I used to use on Android. The interface is clunky, but that’s a small price to pay.
1: Why? File management and getting files into apps is the #1 area where Android wins.
For example, iOS has me copying or saving audiobooks into a folder only to import them into BookPlayer, whereas Android’s Smart Audiobook Player lets me copy my book to my audiobooks folder and hit ‘rescan’.
Funnily enough, one of the only music apps on iOS that offers the same functionality - copy a folder into your library and rescan - is the same Neutron Player I used to use on Android. The interface is clunky, but that’s a small price to pay.
I wish I didn’t have to pay google of all companies to escape Apple.
I wonder how much Google actually makes on these. I won't be surprised if they basically make nothing on them.
It is a bit fun that seemingly the best way to de-google and de-apple yourself is to buy an actual Google device and install grapheneos on it.
It is a bit fun that seemingly the best way to de-google and de-apple yourself is to buy an actual Google device and install grapheneos on it.
When installing graphene os I would consider very carefully if you want to relock the bootloader. In the past I have installed graphene os on my pixel 7a and a normal system update broke my system and made it unbootable. Because of the locked bootloader you can't reflash the os without wiping your data. It may be a very uncommon bug that may never happen to you, but honestly it shouldn't have happened to me either.
I've been using GrapheneOS since the Pixel 3a and this is the first time I'm hearing of such an issue. To me, the ability to relock the bootloader and rely on verified boot is a big security advantage compared to other custom ROMs. I would not want to give that up lightly.
Ive been using GrapheneOS for years and was in the chat rooms a fair bit, this isnt something common. Sounds like it may be hardware failing.
Having bootloader locked you get verified boot, big security benefits and automatic healing of operating system files damaged by the drive degrading.
Having bootloader locked you get verified boot, big security benefits and automatic healing of operating system files damaged by the drive degrading.
What you're describing is highly unusual and likely due to making changes to the OS. Hardly anyone has reported this kind of issue over the many years GrapheneOS has existed. A/B updates have automatic rollback if the OS doesn't boot to the home screen. If it doesn't boot all the way, then it's automatically completely undone by the firmware and all changes to OS data are undone because the data is initially mounted in a mode which only appends to the filesystem log and doesn't persist any of the changes. The update system is very robust and can handle an update not booting automatically. It's also very unlikely for updates not to boot properly considering that they're tested on each device model before reaching Alpha and then go through both public Alpha and Beta testing before the Stable channel.
Leaving the device unlocked makes it far more likely something will go wrong and data will be lost. Disabling or revoking permissions from core system components which are not user-facing apps or making low-level changes with ADB to unsupported settings, etc. are other examples of how people can screw things up entirely on their own. If people disable something like the OS permission manager component and the OS can't boot anymore without a factory reset, that's not a bug. This is likely the kind of issue which happened to you.
We recommend against using developer options on a production device, particularly making changes with ADB. We also recommend against disabling core system components or their permissions in the Settings app via the Show system menus. Android allows users to break the OS via developer options or disabling core system components. It may not happen until after a reboot or update. We don't think the Android Settings app should allow disabling as much as it does but we didn't design that and taking away options from people in the GUI would make a lot of people angry even if it can still be done via ADB.
Not locking the device is an extremely poor security and robustness decision. It's not considered a completed GrapheneOS installation without locking.
> but honestly it shouldn't have happened to me either
It depends on what you changed. Android doesn't block power users from breaking the OS and needing a factory reset. That's not GrapheneOS specific. We did eliminate a few common ways people locked themselves out of their device like disabling the built-in keyboard if they use a different one which can then break or might not support running Before First Unlock via Direct Boot support.
Leaving the device unlocked makes it far more likely something will go wrong and data will be lost. Disabling or revoking permissions from core system components which are not user-facing apps or making low-level changes with ADB to unsupported settings, etc. are other examples of how people can screw things up entirely on their own. If people disable something like the OS permission manager component and the OS can't boot anymore without a factory reset, that's not a bug. This is likely the kind of issue which happened to you.
We recommend against using developer options on a production device, particularly making changes with ADB. We also recommend against disabling core system components or their permissions in the Settings app via the Show system menus. Android allows users to break the OS via developer options or disabling core system components. It may not happen until after a reboot or update. We don't think the Android Settings app should allow disabling as much as it does but we didn't design that and taking away options from people in the GUI would make a lot of people angry even if it can still be done via ADB.
Not locking the device is an extremely poor security and robustness decision. It's not considered a completed GrapheneOS installation without locking.
> but honestly it shouldn't have happened to me either
It depends on what you changed. Android doesn't block power users from breaking the OS and needing a factory reset. That's not GrapheneOS specific. We did eliminate a few common ways people locked themselves out of their device like disabling the built-in keyboard if they use a different one which can then break or might not support running Before First Unlock via Direct Boot support.
You are right, it may have been a unusual bug that hardly occurs, but it definitely happened to me. I also agree that having a unlocked bootloader is a security risk (how big of security risk depends on one's thread level I would say).
I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
I think the error message that I got was the "No valid operating system found" one. Maybe the issue would have resolved itself, if I had rebooted my phone a few times more, through the A/B slot mechanic. I honestly didn't know all this in that situation and only found some vague forum posts about it. I think it would have helped if there was a bit of official documentation about boot loops and what to do when one occurs on the graphene os website.
The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
I think the error message that I got was the "No valid operating system found" one. Maybe the issue would have resolved itself, if I had rebooted my phone a few times more, through the A/B slot mechanic. I honestly didn't know all this in that situation and only found some vague forum posts about it. I think it would have helped if there was a bit of official documentation about boot loops and what to do when one occurs on the graphene os website.
The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
> You are right, it may have been a unusual bug that hardly occurs, but it definitely happened to me.
This doesn't mean that it was a GrapheneOS issue.
> I also agree that having a unlocked bootloader is a security risk
It's a major reduction in security. It completely ruins the defenses against data extraction and significantly reduces security against a remote attacker persisting access. It also reduces robustness.
> I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
Based on the error message you give below, it wasn't any of those things because the error message isn't from the OS and is from before the OS boots.
> I think the error message that I got was the "No valid operating system found" one.
This is an error message from the firmware indicating that there's no OS installed on the current slot. If that happened after an update, it would have automatically rolled back. What you're describing was either caused by a firmware bug or a hardware failure. It indicates data loss on the SSD. If you had the device unlocked and modified the OS, it indicates that went wrong. It's highly unlikely that this had anything to do with an OS bug or misconfiguration.
> The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
You're describing a Pixel firmware bug or hardware failure such as SSD data loss. It could have occurred with the stock OS too. It's not really feasible that it was an OS bug. The error is from the firmware, not the OS, and if the firmware was working properly with no hardware failure involved it would roll back automatically if it had happened after an update. If it wasn't after an update, then it indicates data loss for the existing OS images.
This doesn't mean that it was a GrapheneOS issue.
> I also agree that having a unlocked bootloader is a security risk
It's a major reduction in security. It completely ruins the defenses against data extraction and significantly reduces security against a remote attacker persisting access. It also reduces robustness.
> I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
Based on the error message you give below, it wasn't any of those things because the error message isn't from the OS and is from before the OS boots.
> I think the error message that I got was the "No valid operating system found" one.
This is an error message from the firmware indicating that there's no OS installed on the current slot. If that happened after an update, it would have automatically rolled back. What you're describing was either caused by a firmware bug or a hardware failure. It indicates data loss on the SSD. If you had the device unlocked and modified the OS, it indicates that went wrong. It's highly unlikely that this had anything to do with an OS bug or misconfiguration.
> The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
You're describing a Pixel firmware bug or hardware failure such as SSD data loss. It could have occurred with the stock OS too. It's not really feasible that it was an OS bug. The error is from the firmware, not the OS, and if the firmware was working properly with no hardware failure involved it would roll back automatically if it had happened after an update. If it wasn't after an update, then it indicates data loss for the existing OS images.
I'd be interested in more specifics here. I've been in a few bootloops with GrapheneOS early on but I've always been able to get out of them by keeping cool and not prematurely trying to reflash and wipe. Eventually the phone always booted (I think that it's due to the A/B partition system where eventually the phone will try to boot the other "working" partition again. But sometimes this would take a while).
It hasn't happened in a year though and I've been happily upgrading lately. I'm not saying you couldn't have run into a unique bug but I'd find it surprising if your phone was really left completely bricked except for reflashing/wiping it.
It hasn't happened in a year though and I've been happily upgrading lately. I'm not saying you couldn't have run into a unique bug but I'd find it surprising if your phone was really left completely bricked except for reflashing/wiping it.
It was some time ago, so I unfortunately can't remember all the details. It occured during a normal system update that ran without problems at first, but when I rebooted the phone to finish the update it couldn't boot anymore (I can't remember the error messages). I don't know what exactly went wrong or was corrupted during the update. I definetly rebooted the phone multiple times and tried to fix the issue, but after some time I realized it was futile.
Maybe there still was a way to salvage it, but I really can't tell in hindsight.
Maybe there still was a way to salvage it, but I really can't tell in hindsight.
This has happened to me when the battery ran out during the reboot/upgrade. One time I had to let it charge and reboot for a good 30 minutes and eventually it booted again.
I totally understand giving up there though as it sucks to not be able to use the phone for a while and is very inconvenient. Let alone if this happens at an inconvenient time/during a work day, etc.
I totally understand giving up there though as it sucks to not be able to use the phone for a while and is very inconvenient. Let alone if this happens at an inconvenient time/during a work day, etc.
I hope the so-called blobs have been replaced with unprivileged opensource versions.
Otherwise privacy and security would be meaning basically nothing.
Otherwise privacy and security would be meaning basically nothing.
Open source doesn't provide any magical privacy or security. iPhones have solid privacy and security despite being mostly closed source software. iPhones are the next best options for privacy and security in most ways. They have great privacy from apps and aren't awful at privacy from Apple particular if people use Advanced Data Program for iCloud, and they have solid security overall along with some useful settings for it. GrapheneOS of course provides better privacy from the OS services. We provide a full list of default connections made by the OS at https://grapheneos.org/faq#default-connections and none are made by the hardware without the OS prompting it. GrapheneOS also defends better against sophisticated real world attacks, and there's real world evidence for that from leaked capabilities of Cellebrite, Magnet Forensics (Graykey) and MSAB (XRY) along with some basic info about remote exploit sellers.
All of the kernel drivers are open source, which would be the case for Snapdragon too.
Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things.
There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help.
If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.
All of the kernel drivers are open source, which would be the case for Snapdragon too.
Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things.
There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help.
If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.
What about the blobs mentioned before? Those are closed source binaries running as root with direct access to the hardware, like the baseband modem. It can talk to the internet without any auditing being possible.
> If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access.
Is it normal that phone OEMs have access to most of the source code of the kernel drivers and user space libraries provided by the SoC vendor.
I worked in the home router business and there it was normal that a OEM gets most of the kernel drivers and user space code in source code, but it was often restricted what they are allowed to publish in source code. Many vendors even published much less than they had to according to GPL and allowed by the SoC vendor.
I have heard that in the smart TV industry OEMs sometimes are only allowed to write an app and have no kernel source code access for their product.
Is it normal that phone OEMs have access to most of the source code of the kernel drivers and user space libraries provided by the SoC vendor.
I worked in the home router business and there it was normal that a OEM gets most of the kernel drivers and user space code in source code, but it was often restricted what they are allowed to publish in source code. Many vendors even published much less than they had to according to GPL and allowed by the SoC vendor.
I have heard that in the smart TV industry OEMs sometimes are only allowed to write an app and have no kernel source code access for their product.
Kernel drivers for all of the main Android hardware platforms are fully open source. It's the userspace libraries/services which tend to have a lot of code that's not open source. At least for Snapdragon, that's shared with OEMs so can be modified and built by them. Snapdragon also shares major parts of the firmware sources with OEMs too. Some parts of the firmware are open source.
Is there a GrapheneOS image for use with Android Emulator? I want to test an app on it but got no physical Pixel device.
Many apps won't work in the Android emulator. Banking apps, etc. will detect it and ban it. Far more apps will ban the emulator than will ban GrapheneOS. We aren't aware of an app which would work in the Android emulator with a standard emulator image containing Google Play but wouldn't work with GrapheneOS. Nearly all Android apps work on GrapheneOS. It's nearly entirely just the subset which ban using any non-stock OS with the Play Integrity API which can't be used. We convinced a few banking apps to start allowing GrapheneOS via hardware attestation but the pace of banking apps integrating the Play Integrity API is unfortunately quite a bit faster than the pace we're convincing apps to support it after they do that.
You can build it for the emulator. It's straightforward to do, but it requires a lot of disk space and it will take around 40-60 minutes on a high end desktop CPU like a Ryzen 9950X. We don't publish official releases for the emulator at the moment because it's not intended for production use and isn't really a good experience to use. We could start doing it, but it'd add some extra work and we'd be concerned about people misinterpreting what it's meant to provide. Emulator builds don't have the regular security model intact or OS updates, etc.
You can build it for the emulator. It's straightforward to do, but it requires a lot of disk space and it will take around 40-60 minutes on a high end desktop CPU like a Ryzen 9950X. We don't publish official releases for the emulator at the moment because it's not intended for production use and isn't really a good experience to use. We could start doing it, but it'd add some extra work and we'd be concerned about people misinterpreting what it's meant to provide. Emulator builds don't have the regular security model intact or OS updates, etc.
Thanks for the reply, yeah, my interest was to test compatibility when we add support for Play Integrity to our app.
Please read https://grapheneos.org/articles/attestation-compatibility-gu.... It's possible to support GrapheneOS by using the Android hardware attestation API either as an alternative to the Play Integrity API or instead of it. By using the hardware attestation API, you can make a list of allowed key fingerprints for the SelfSigned boot state for non-Google-certified operating systems. We list all our current keys for non-end-of-life devices on that page. Recently, Swissquote used this approach to add support for GrapheneOS to their Yuh app and may be adding it to their main Swissquote app soon.
You can test hardware attestation on any modern Android device but you'd need GrapheneOS on a real device to fully check that you have the SelfSigned fingerprint allowlist working properly. It wouldn't be hard to do it without testing it though, and our users can test if app developers ask our community on https://discuss.grapheneos.org/.
You can test hardware attestation on any modern Android device but you'd need GrapheneOS on a real device to fully check that you have the SelfSigned fingerprint allowlist working properly. It wouldn't be hard to do it without testing it though, and our users can test if app developers ask our community on https://discuss.grapheneos.org/.
What problem do you think Play Integrity solve other than keeping the user's under Google's walled garden? Play Integrity is a fake marketing term for DRM fromGoogle . It does not guarantee security of the device in any way. My 6~ year old and unpatched Android 10 passes Play Integrity and can run banking apps. That explains everything about Play Integrity. I don't use apps from developers who think they know better than their users.
>What problem do you think Play Integrity solve other than keeping the user's under Google's walled garden?
It ensures requests to your backend are vaguely from actual devices, rather than a bunch of emulators. There's many reasons why developers might want this. It significantly raises the bar for credential stuffing attacks, for instance.
It ensures requests to your backend are vaguely from actual devices, rather than a bunch of emulators. There's many reasons why developers might want this. It significantly raises the bar for credential stuffing attacks, for instance.
Yes, developers are of course going to opt for APIs that allow them to be as lazy as possible, forego proper backend security, and reduce costs. But is allowing developers to be lazy worth the cost of destroying user freedom? If so, maybe we should work on bringing back the Web Environment Integrity API. That would really help out web developers and would make web apps a lot more secure. Nobody uses Linux on the desktop anyways besides weird nerds so it wouldn't have any real impact.
Can't wait until we finally kill hacker culture for good. Everyone and everything will be fully secured. It's going to be beautiful. The nerds can cry about it all day long, but they're powerless to stop it.
Can't wait until we finally kill hacker culture for good. Everyone and everything will be fully secured. It's going to be beautiful. The nerds can cry about it all day long, but they're powerless to stop it.
Please don't add play integrity to your app. There are many of us using custom ROMs, and it can relatively easily be worked around, but very much is often a giant screw you to technical users...
What is the current conventional UX with GrapheneOS?
Especially regarding:
- Usability of taxi apps like: Uber, Grab, Bolt
- Camera quality versus stock ROM
Especially regarding:
- Usability of taxi apps like: Uber, Grab, Bolt
- Camera quality versus stock ROM
The vast majority of Android apps including those can be used on GrapheneOS.
Camera quality is the same within the same app on either.
Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it.
GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time.
Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
Camera quality is the same within the same app on either.
Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it.
GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time.
Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
Uber and Bolt apps works like normal. I don't know what is Grab.
The default camera lacks post-processing tricks, but you can install Google Camera if you like (shouldn't be a privacy concern here with limited permissions).
Interesting. I used to have problems using such apps on LineageOS due to their dependence on this Google Push Messaging service (don't remember what it's called) and also dependence on Google Maps services.
(Grab is like Uber/Bolt but used in different regions of the world.)
Camera quality of LineageOS was really bad.
A voyage was the catalyst for switching to iPhone as this seemed back then the best option to LineageOS and I couldn't risk not being able to use such logistically relevant apps.
Especially in Asia you have to be ready to install and use whatever app is required and not being able to might be seriously handicapping.
(Grab is like Uber/Bolt but used in different regions of the world.)
Camera quality of LineageOS was really bad.
A voyage was the catalyst for switching to iPhone as this seemed back then the best option to LineageOS and I couldn't risk not being able to use such logistically relevant apps.
Especially in Asia you have to be ready to install and use whatever app is required and not being able to might be seriously handicapping.
On GrapheneOS, you can install Google play services in a sandboxed way (and if you want, in another user profile, work profile or private space) which can allow all these things to work seamlessly. Generally I've had way more problems with other custom roms and things like MicroG. I'd recommend to just try it out if you have an unused pixel phone. Imo it's very unlike any other custom rom in terms of the user experience.
GrapheneOS Camera does have HDR+ and Night mode on Pixels along with HDRnet and EIS for videos. Pixel Camera has more features and more aggressive HDR+.
What's the next big feature being implemented? The last was the network location one.
Feature development is going to be a bit slower for at least a couple months due to several of our core developers being temporarily unavailable.
We're actively working on several major improvements including automatic generation of random passphrases and PINs, further improvements to VPN lockdown mode, per-app toggles for access to clipboard content from other apps to go beyond the existing restriction of only the focused app and keyboard being able to read it, etc.
You can look through https://github.com/GrapheneOS/os-issue-tracker/issues with the Feature type and enhancement label. GitHub unfortunately didn't provide a way to automatically migrate the older enhancement label to Feature type. We could use the API for it but haven't yet so you'll need to use both the old and new methods.
We're actively working on several major improvements including automatic generation of random passphrases and PINs, further improvements to VPN lockdown mode, per-app toggles for access to clipboard content from other apps to go beyond the existing restriction of only the focused app and keyboard being able to read it, etc.
You can look through https://github.com/GrapheneOS/os-issue-tracker/issues with the Feature type and enhancement label. GitHub unfortunately didn't provide a way to automatically migrate the older enhancement label to Feature type. We could use the API for it but haven't yet so you'll need to use both the old and new methods.
How is the camera quality on the GrapheneOS phones?
Camera quality is the same within the same app on either.
Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it.
GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time.
Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it.
GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time.
Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
GrapheneOS' own camera app doesn't have Google's propriety processing, so it's not as good as stock, but with Pixel devices, you can install the original Google Camera/Pixel Camera app and get the original camera quality.
GrapheneOS Camera does have hardware accelerated HDR+ and Night mode along with HDRnet and EIS for videos on Pixels.
Photos in Pixel Camera look different because the HDR+ it uses by default is more aggressive resulting in higher contrast but a less natural look. Both are using HDR+ with hardware acceleration though. Videos are more similar and Night mode photos likely are too.
Photos in Pixel Camera look different because the HDR+ it uses by default is more aggressive resulting in higher contrast but a less natural look. Both are using HDR+ with hardware acceleration though. Videos are more similar and Night mode photos likely are too.
But I think Pixel Camera does some kind of sharpening post-processing, because I get blurry images sometimes with GrapheneOS Camera while almost never with Pixel Camera.
I would like to root, but I like my Google pay.
In many countries, there are tap-to-pay options permitting using GrapheneOS including Curve Pay and also the standard used by many European banks. US lacks an option but will hopefully get Curve Pay soon. Garmin Pay and Android Pay can be used via a Garmin or Android smart watch so that's what some of our US users do. Pixel Watch works fine paired with GrapheneOS with sandboxed Google Play.
Note installing GrapheneOS doesn't involve rooting. Installing it uses an officially supported process and doesn't void the warranty. It preserves the standard security model and massively improves privacy and security on top of that (https://grapheneos.org/features). It's largely the opposite of most other alternative Android-based operating systems are doing with security.
Note installing GrapheneOS doesn't involve rooting. Installing it uses an officially supported process and doesn't void the warranty. It preserves the standard security model and massively improves privacy and security on top of that (https://grapheneos.org/features). It's largely the opposite of most other alternative Android-based operating systems are doing with security.
GrapheneOS != root. You don't have root when running GrapheneOS - it would be a security risk.
Genuinely curious, why do you need root access on your EDC phone? Personally I would stick with a throwaway for experimentation, so I'm curious about your motivation.
To do things like turn off and on airplane mode when certain conditions are met with automate https://play.google.com/store/apps/details?id=com.llamalab.a... for example. There are work arounds but having a rooted phone is the easiest.
I see. I get this out of the box on iOS via Shortcuts & automations, it's a part of the base OS and honestly pretty powerful. I get it that iOS is not for everyone, but at the very least it's a proof and an incentive for Android to implement this as well.
That can be done without root access and likely also without needing network ADB via device management.
I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones. Pixel phones were great, in the past, but now they're mediocre offerings for their price range and the removal of the 3.5mm jack pushed many of the more techy users away — GrapheneOS's target audience.
Not sure if I'd use GrapheneOS even if it was available on other devices though. Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
Not sure if I'd use GrapheneOS even if it was available on other devices though. Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
GrapheneOS, in my opinion, can only exist the way they do because of their exclusive support for Pixel devices. It allows them to provide a uniquely high quality ROM with proper support guarantees.
Compare that to other custom ROMs, where you typically depend on volunteers maintaining the various devices. Sometimes people decide to step down, and suddenly find your device unsupported. This happened to me with LineageOS/CyanogenMod.
My understanding is also that the OEM ROMs of Pixel devices are closer to AOSP than those of other vendors like Samsung. This simplifies the maintenance of the ROMs, and enables the project to develop meaningful features instead.
Compare that to other custom ROMs, where you typically depend on volunteers maintaining the various devices. Sometimes people decide to step down, and suddenly find your device unsupported. This happened to me with LineageOS/CyanogenMod.
My understanding is also that the OEM ROMs of Pixel devices are closer to AOSP than those of other vendors like Samsung. This simplifies the maintenance of the ROMs, and enables the project to develop meaningful features instead.
See https://news.ycombinator.com/item?id=43670303 for a detailed explanation. If we were going to support another device, it would need to meet the security requirements AND provide proper production quality non-stock OS support with a strong commitment to keeping it properly working.
We can't safely use a device where they might patch out support for what we rely on. As an example, OnePlus patched out support for alternate OS verified boot due to serious security vulnerabilities with how they'd implemented it. Operating systems relying on it would no longer be able to update the firmware, leaving them insecure, but yet the verified boot never worked properly anyway so it ended up worse than them not trying in the first place.
Realistically, what we expect is that Pixels are the only devices we're not involved in making which we'll be able to support for the foreseeable future. To support other devices, we need a partnership with a competent OEM like Samsung. We can raise money to pay the usual licensing fees for platforms and then work with them where we have paid support so they aren't going to break things for us, drop update support unexpectedly, etc.
We can't safely use a device where they might patch out support for what we rely on. As an example, OnePlus patched out support for alternate OS verified boot due to serious security vulnerabilities with how they'd implemented it. Operating systems relying on it would no longer be able to update the firmware, leaving them insecure, but yet the verified boot never worked properly anyway so it ended up worse than them not trying in the first place.
Realistically, what we expect is that Pixels are the only devices we're not involved in making which we'll be able to support for the foreseeable future. To support other devices, we need a partnership with a competent OEM like Samsung. We can raise money to pay the usual licensing fees for platforms and then work with them where we have paid support so they aren't going to break things for us, drop update support unexpectedly, etc.
Thank you for working on GOS. It is one of the few, if not only, OS that makes mobile devices usable for me.
> To support other devices, we need a partnership with a competent OEM like Samsung.
How realistic would it be to have an official Graphene phone? Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications? That would be the ultimate mobile device for tech and privacy nerds, for which I'm sure many would be willing to pay a premium over mass manufactured devices.
As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
> To support other devices, we need a partnership with a competent OEM like Samsung.
How realistic would it be to have an official Graphene phone? Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications? That would be the ultimate mobile device for tech and privacy nerds, for which I'm sure many would be willing to pay a premium over mass manufactured devices.
As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
Samsung is the main company we'd really want to work with. They already provide devices meeting nearly all our requirements, they just don't provide us a way to support them yet. If they started doing that, we could support some of their devices. Better yet, if they actively worked with us, we could help them make major security improvements and there could be first class GrapheneOS support. We can raise money for it rather than having to convince them that it makes business sense to fill a product niche they aren't currently providing.
> As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
Apple and Google provide a high level of security for their mobile devices. Other OEMs aren't on the same level. Samsung is the only one that's even remotely close. We'd love to work with Samsung but wanting to do it doesn't mean they will work with us. We could potentially pay them to build a device for us if we raised enough money in advance. We choose devices based on their security and other properties along with the actual record of the company making it. Corporations are amoral profit seeking entities in general. That's not something specific to Google.
> Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications?
Framework doesn't currently build devices close to meeting our requirements but is not anti-security or misleading people like Purism. We wouldn't have any issue working with them, we just don't really expect them to start building what we need any time soon.
Purism has extremely anti-security practices and makes extraordinarily insecure devices incredibly far from meeting our requirements. They purposely choose low security components and don't provide important updates. They even block providing the updates from the OS. We'd much rather support a low-end Motorola phone with only 2-3 years of support than a Purism device because they're so much less secure than mainstream hardware. Purism has 0 days of update support for their products in the sense that we require.
We don't consider Purism to be a privacy friendly company due to the atrocious security of their products and services. The software they use on top is also far less private and secure than the Android Open Source Project. It's largely the complete opposite of GrapheneOS. They also do a lot of false marketing that's directly harmful to us such as their false claims about cellular radios. In reality, their device has a much less secure cellular radio with far more attack surface exposed from the OS than an iPhone. It's less isolated, not more isolated, and yet they've convinced many people otherwise with their marketing and done harm to the whole space with the misconception people now have. The same applies in other areas.
If we partnered with Samsung, people would know they're going to get a good product and that the company making the hardware would still be around providing support years later. If we instead partnered with a company known for not shipping people what they ordered and not providing what was claimed in the promotional material, that would be very hard for people to trust. Our community would be shocked and incredibly disappointed if we did that.
> As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
Apple and Google provide a high level of security for their mobile devices. Other OEMs aren't on the same level. Samsung is the only one that's even remotely close. We'd love to work with Samsung but wanting to do it doesn't mean they will work with us. We could potentially pay them to build a device for us if we raised enough money in advance. We choose devices based on their security and other properties along with the actual record of the company making it. Corporations are amoral profit seeking entities in general. That's not something specific to Google.
> Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications?
Framework doesn't currently build devices close to meeting our requirements but is not anti-security or misleading people like Purism. We wouldn't have any issue working with them, we just don't really expect them to start building what we need any time soon.
Purism has extremely anti-security practices and makes extraordinarily insecure devices incredibly far from meeting our requirements. They purposely choose low security components and don't provide important updates. They even block providing the updates from the OS. We'd much rather support a low-end Motorola phone with only 2-3 years of support than a Purism device because they're so much less secure than mainstream hardware. Purism has 0 days of update support for their products in the sense that we require.
We don't consider Purism to be a privacy friendly company due to the atrocious security of their products and services. The software they use on top is also far less private and secure than the Android Open Source Project. It's largely the complete opposite of GrapheneOS. They also do a lot of false marketing that's directly harmful to us such as their false claims about cellular radios. In reality, their device has a much less secure cellular radio with far more attack surface exposed from the OS than an iPhone. It's less isolated, not more isolated, and yet they've convinced many people otherwise with their marketing and done harm to the whole space with the misconception people now have. The same applies in other areas.
If we partnered with Samsung, people would know they're going to get a good product and that the company making the hardware would still be around providing support years later. If we instead partnered with a company known for not shipping people what they ordered and not providing what was claimed in the promotional material, that would be very hard for people to trust. Our community would be shocked and incredibly disappointed if we did that.
> I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones.
Pixels are the only available smartphones meeting our hardware security requirements while permitting us to use the hardware-based security features. Our requirements are very reasonable and listed at https://grapheneos.org/faq#future-devices. Recent Samsung flagships using an Exynos or MediaTek SoC have essentially all the security features on this list on paper. However, Samsung doesn't let us support their devices. Samsung cripples the device if you use another OS, mainly by disallowing using security features. Some of it is permanently disabled even if you go back to the stock OS and lock it again. There's an eFuse they refer to as the warranty bit which they burn when you unlock, crippling the device forever.
The audience using GrapheneOS has become much less technical over time as usability and app compatibility has greatly improved. Installation via the web installer is something many very non-technical people are regularly doing successfully, largely without help. 24/7 real time help with installation is available via our chat rooms. Our overall audience is less technical than you think. The chat rooms attract a more technical subset of the community and isn't really representative.
Pixels have digital USB-C audio output and DisplayPort alternate mode support. They have the start of a proper desktop mode and hardware virtualization support for running applications from other operating systems. In GrapheneOS, that can already be used for GUI applications with speaker, microphone and opt-in GPU acceleration support. Analog 3.5mm audio output isn't something people focused on bleeding edge technology want. Audiophiles never wanted to use low quality DAC in the phone but rather a high quality one connected via USB-C with digital audio output.
> Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
GrapheneOS has a built-in encrypted backup system which uses the device-to-device mode. That's the mode Google Play services uses on Google Mobile Services devices when you transfer to a new device. It does back up every app, they can't opt-out of it. They can explicitly exclude data from device-to-device backups which is non-portable or shouldn't be used across devices such as a device-specific login token. The previous systems for opting out of backups or excluding files only exclude them from cloud backups now.
Some apps like Signal encrypt their data themselves as an additional layer so no backup system other than the one built into their app is going to back that up and restore it in a useful way. Transferring data encrypted with a hardware keystore key which then can't be read/used by the app wouldn't be helpful. Transferring device-specific login tokens, etc. isn't wanted. The way the standard backup infrastructure is designed in Android is the right approach since Android 12. It does work well. The current backup service we're using is not a great implementation of it but has gotten better. We intend to completely fork it and massively overhaul it at some point. It was originally written by a GrapheneOS user for GrapheneOS but it got largely taken over by others and we don't agree with their approach or choices for it, so we'll be forking it.
Pixels are the only available smartphones meeting our hardware security requirements while permitting us to use the hardware-based security features. Our requirements are very reasonable and listed at https://grapheneos.org/faq#future-devices. Recent Samsung flagships using an Exynos or MediaTek SoC have essentially all the security features on this list on paper. However, Samsung doesn't let us support their devices. Samsung cripples the device if you use another OS, mainly by disallowing using security features. Some of it is permanently disabled even if you go back to the stock OS and lock it again. There's an eFuse they refer to as the warranty bit which they burn when you unlock, crippling the device forever.
The audience using GrapheneOS has become much less technical over time as usability and app compatibility has greatly improved. Installation via the web installer is something many very non-technical people are regularly doing successfully, largely without help. 24/7 real time help with installation is available via our chat rooms. Our overall audience is less technical than you think. The chat rooms attract a more technical subset of the community and isn't really representative.
Pixels have digital USB-C audio output and DisplayPort alternate mode support. They have the start of a proper desktop mode and hardware virtualization support for running applications from other operating systems. In GrapheneOS, that can already be used for GUI applications with speaker, microphone and opt-in GPU acceleration support. Analog 3.5mm audio output isn't something people focused on bleeding edge technology want. Audiophiles never wanted to use low quality DAC in the phone but rather a high quality one connected via USB-C with digital audio output.
> Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
GrapheneOS has a built-in encrypted backup system which uses the device-to-device mode. That's the mode Google Play services uses on Google Mobile Services devices when you transfer to a new device. It does back up every app, they can't opt-out of it. They can explicitly exclude data from device-to-device backups which is non-portable or shouldn't be used across devices such as a device-specific login token. The previous systems for opting out of backups or excluding files only exclude them from cloud backups now.
Some apps like Signal encrypt their data themselves as an additional layer so no backup system other than the one built into their app is going to back that up and restore it in a useful way. Transferring data encrypted with a hardware keystore key which then can't be read/used by the app wouldn't be helpful. Transferring device-specific login tokens, etc. isn't wanted. The way the standard backup infrastructure is designed in Android is the right approach since Android 12. It does work well. The current backup service we're using is not a great implementation of it but has gotten better. We intend to completely fork it and massively overhaul it at some point. It was originally written by a GrapheneOS user for GrapheneOS but it got largely taken over by others and we don't agree with their approach or choices for it, so we'll be forking it.
Samsung is banned in my household. Separately from what you say, every Samsung anything I ever owned was a piece of shit, starting with a certain DVD player back in 2003 whose firmware crapped out exactly one day after the one year warranty.
> [backup]...which uses the device-to-device mode
That's a very recent feature, isn't it?
> They can explicitly exclude data from device-to-device backups
Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
That's a very recent feature, isn't it?
> They can explicitly exclude data from device-to-device backups
Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
> That's a very recent feature, isn't it?
Android 12 theoretically added it but it didn't fully work yet and apps needed to start targeting Android 12+. Then, the backup app needed to add it which took a long time, so it's fairly recent as in within the past 2 years.
> Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
Many apps use the older system to disable backups or exclude files which only applies to cloud backups now. Most apps don't exclude files from device-to-device backups improperly. Excluding device-specific login tokens, caches, etc. is how it's intended to be used. It annoys people they need to login to apps again after a transfer but that's generally how those apps want their security model to work so there's an entry for each login session and logging out of it only logs it out on 1 device.
Apps can exclude files and define their own backup agent for handling converting to and from a portable format. Chrome does this to backup Android-specific settings, etc. not handled by Chrome's Sync feature. This means non-Chrome Chromium-based browsers largely lacking sync have poor backup support. We plan to address this in Vanadium but haven't decided how we want to approach it yet.
It does work well. People mostly have a good experience with device-to-device transfer with Google Mobile Services devices now. Certain apps like Signal or TOTP apps using the hardware keystore inherently can't be backed up this way. Signal doesn't use it in a sensible way for security and really just seems to have introduced hardware keystore based encryption to prevent using root-based backup systems not taking into account which data should be backed up or not backed up. They don't trust the OS backup infrastructure particularly since OEMs can include sketchy backup services so they don't want that to work either.
Android 12 theoretically added it but it didn't fully work yet and apps needed to start targeting Android 12+. Then, the backup app needed to add it which took a long time, so it's fairly recent as in within the past 2 years.
> Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
Many apps use the older system to disable backups or exclude files which only applies to cloud backups now. Most apps don't exclude files from device-to-device backups improperly. Excluding device-specific login tokens, caches, etc. is how it's intended to be used. It annoys people they need to login to apps again after a transfer but that's generally how those apps want their security model to work so there's an entry for each login session and logging out of it only logs it out on 1 device.
Apps can exclude files and define their own backup agent for handling converting to and from a portable format. Chrome does this to backup Android-specific settings, etc. not handled by Chrome's Sync feature. This means non-Chrome Chromium-based browsers largely lacking sync have poor backup support. We plan to address this in Vanadium but haven't decided how we want to approach it yet.
It does work well. People mostly have a good experience with device-to-device transfer with Google Mobile Services devices now. Certain apps like Signal or TOTP apps using the hardware keystore inherently can't be backed up this way. Signal doesn't use it in a sensible way for security and really just seems to have introduced hardware keystore based encryption to prevent using root-based backup systems not taking into account which data should be backed up or not backed up. They don't trust the OS backup infrastructure particularly since OEMs can include sketchy backup services so they don't want that to work either.
I would say the exact opposite. The latest Pixel phones are "pretty much iPhones" in terms of hardware (and looks too). It seems smartphones have arrived at an agreed upon form factor and design in general.
What I noticed though is that Google often tries to upsell based on software features alone. For example, there is really no point in buying a Pixel 9 Pro instead of a base Pixel 9 as the hardware is practically the same except certain things. But Google markets the Pro model with more software based AI features. When installing GOS this really doesn't make a difference so one can always opt for the more inexpensive models.
What I noticed though is that Google often tries to upsell based on software features alone. For example, there is really no point in buying a Pixel 9 Pro instead of a base Pixel 9 as the hardware is practically the same except certain things. But Google markets the Pro model with more software based AI features. When installing GOS this really doesn't make a difference so one can always opt for the more inexpensive models.
Only providing the Pro mode in Pixel Camera on the Pro devices is one of the only ways they're artificially segmenting them via software. The AI model differences are largely based on real differences in available memory and that doesn't have much impact on available OS features. That matters to LLM enthusiasts but probably isn't a selling point for most people at this point.
The base devices are better value but the Pro devices do mainly differentiate based on hardware. Better display, addition of the 5x telephoto camera, better front camera and more memory are the main selling points. Pixel 9a is similarly a downgrade for the screen, cameras, memory, wireless charging speed and cellular radio (back to a variant of the 7th/8th gen Pixel radio). Pixel 9a has very good value but the cellular radio downgrade is a big one which people may care about more than they realize due to how it impacts battery life when using 5G.
The base devices are better value but the Pro devices do mainly differentiate based on hardware. Better display, addition of the 5x telephoto camera, better front camera and more memory are the main selling points. Pixel 9a is similarly a downgrade for the screen, cameras, memory, wireless charging speed and cellular radio (back to a variant of the 7th/8th gen Pixel radio). Pixel 9a has very good value but the cellular radio downgrade is a big one which people may care about more than they realize due to how it impacts battery life when using 5G.
> I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones. Pixel phones were great, in the past, but now they're mediocre
Interesting that someone would say this. I’ve had several Nexus and Pixel phones in the past (last one was a Pixel 2) and they were all pretty bad in terms of hardware and the support from google was non existent. I only bought for them for the software… which wasn’t great either. They have always been mediocre phones, to put it mildly.
Interesting that someone would say this. I’ve had several Nexus and Pixel phones in the past (last one was a Pixel 2) and they were all pretty bad in terms of hardware and the support from google was non existent. I only bought for them for the software… which wasn’t great either. They have always been mediocre phones, to put it mildly.
[deleted]
Huh? Pixels haven't had 3.5 jacks since Pixel 2 in 2017. wdym?
GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
See https://grapheneos.org/faq#future-devices for the official list of security requirements. We've gone out of the way to keep them very reasonable to permit non-Pixel devices such as only requiring 5 years of updates rather than 7. We also don't require pKVM for virtualization to permit SoC vendors using their own proprietary hypervisors. It's a very reasonable list of requirements. Samsung has devices like their current generation flagship tablets meeting nearly all the security requirements. The blocker is Samsung not permitting another OS to properly support their devices including crippling security for them. The blocker isn't that there aren't devices providing the security features we need but that those devices don't allow us to support them. We aren't interested in low security devices like the Fairphone without even the basic security features included and with significant delays even for the security patch backports from the beginning.
If Samsung had allowed a non-stock OS to properly support devices like Samsung Galaxy Tab S10+ and Samsung Galaxy Tab S10 Ultra, we'd have been very interested. They did not allow it. They permanently cripple their devices if you unlock them. People should criticize Samsung for this rather than criticizing us for something we don't control. Companies like Fairphone are not realistically capable of building what we need due to lack of resources so there's little point in people bothering them about it.
If Samsung had allowed a non-stock OS to properly support devices like Samsung Galaxy Tab S10+ and Samsung Galaxy Tab S10 Ultra, we'd have been very interested. They did not allow it. They permanently cripple their devices if you unlock them. People should criticize Samsung for this rather than criticizing us for something we don't control. Companies like Fairphone are not realistically capable of building what we need due to lack of resources so there's little point in people bothering them about it.
The 3a, 4a, and 4a 5G had a headphone jack.
2017? Maybe I'm getting old... Still, the point stands — the lack of a 3.5mm jack drives techy users away, and the Pixels just aren't very good for their price range today.
> GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require.
I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
> GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require.
I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
> Sure, because they picked a set of features exclusive to Pixels.
No, we don't do that. The security requirements are not exclusive to Pixels. Samsung flagships with an Exynos or MediaTek SoC have nearly every feature listed at https://grapheneos.org/faq#future-devices. They don't quite have proper updates and quality of implementation is an issue. If Samsung allowed us to properly support their devices, we would likely be supported a few Samsung devices. There are no other devices with a reasonable level of security combined with support for using another OS available for us to support. We've also made sure to keep the required support time at 5 years instead of 7 to allow for non-Pixel devices. Snapdragon still not supporting hardware memory tagging at this point is embarrassing for Qualcomm and it should be expected that it's supported at this point, especially since even MediaTek has it now. The OEM making that and other security features available is also needed.
> Nothing is stopping them from being more permissive about the security features they require.
It would not have our core feature set and comparable protections. It would not protect users from real world adversaries like Cellebrite and NSO in the way that it does right now. Our security requirements exist for a reason and major parts of GrapheneOS are built around hardware-based security features. If the device doesn't have hardware memory tagging, then how can we provide one of our main flagship features?
> I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
It's strange that you keep mentioning this in the past tense. We support Pixels because they're currently the only devices providing our security requirements while permitting us to use them. If Samsung started permitting us to support their devices, we could support certain Samsung devices. There aren't currently any other devices meeting our requirements, but there isn't a reason to think that there won't be in the future. Our list of security requirements is a very reasonable list of industry standard features. Android OEMs largely aren't trying to provide reasonably secure devices and are not trying to compete with Pixels and iPhones on security. Samsung is an exception, but quality of implementation isn't as high and they're ruining the end result with the massive non-security changes they make that's massively expanding attack surface and making updates much harder.
No, we don't do that. The security requirements are not exclusive to Pixels. Samsung flagships with an Exynos or MediaTek SoC have nearly every feature listed at https://grapheneos.org/faq#future-devices. They don't quite have proper updates and quality of implementation is an issue. If Samsung allowed us to properly support their devices, we would likely be supported a few Samsung devices. There are no other devices with a reasonable level of security combined with support for using another OS available for us to support. We've also made sure to keep the required support time at 5 years instead of 7 to allow for non-Pixel devices. Snapdragon still not supporting hardware memory tagging at this point is embarrassing for Qualcomm and it should be expected that it's supported at this point, especially since even MediaTek has it now. The OEM making that and other security features available is also needed.
> Nothing is stopping them from being more permissive about the security features they require.
It would not have our core feature set and comparable protections. It would not protect users from real world adversaries like Cellebrite and NSO in the way that it does right now. Our security requirements exist for a reason and major parts of GrapheneOS are built around hardware-based security features. If the device doesn't have hardware memory tagging, then how can we provide one of our main flagship features?
> I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
It's strange that you keep mentioning this in the past tense. We support Pixels because they're currently the only devices providing our security requirements while permitting us to use them. If Samsung started permitting us to support their devices, we could support certain Samsung devices. There aren't currently any other devices meeting our requirements, but there isn't a reason to think that there won't be in the future. Our list of security requirements is a very reasonable list of industry standard features. Android OEMs largely aren't trying to provide reasonably secure devices and are not trying to compete with Pixels and iPhones on security. Samsung is an exception, but quality of implementation isn't as high and they're ruining the end result with the massive non-security changes they make that's massively expanding attack surface and making updates much harder.
> Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require.
You're not the target audience for this OS. Strong security guarantees require vertical integration.
You're not the target audience for this OS. Strong security guarantees require vertical integration.
> Nothing is stopping them from being more permissive
Except for the fact that they don't want to be permissive to keep on being secure.
Except for the fact that they don't want to be permissive to keep on being secure.
>bootloader relocking
My OnePlus3 (2017-ish?) can do that.
It's not even a feature, but standard android bootloader will do this much. Vendors deliberately remove such features, if not disable phone unlocking outright[0].
0. https://en.wikipedia.org/wiki/Bootloader_unlocking
My OnePlus3 (2017-ish?) can do that.
It's not even a feature, but standard android bootloader will do this much. Vendors deliberately remove such features, if not disable phone unlocking outright[0].
0. https://en.wikipedia.org/wiki/Bootloader_unlocking
Qualcomm offers the feature as an option to every OEM using Snapdragon. Our understanding is that it costs extra money to license, like many of their features including security features. Snapdragon is immensely expensive for a modern flagship SoC with long term support and the full feature set including security features.
OnePlus supported it on several devices but then removed it in updates fixing serious security vulnerabilities. Their non-stock verified boot support was insecure and instead of fixing it they removed it. It's likely there wasn't a clear or possible way to fix it due having a poor implementation which never worked properly. Fairphone 4 had a completely insecure implementation of verified boot trusting publicly available AOSP test keys. Having support for it really doesn't mean it works or will even keep appearing to work in future updates.
It's also just one feature. Our overall hardware security requirements are listed at https://grapheneos.org/faq#future-devices. People focus too much on relocking the device but we require a lot more than that. There are non-Pixel devices with essentially all the features we require such as the Samsung Galaxy S10+ and S10 Ultra but they don't allow using another OS without losing the security features. The updates are also still not what we expect, but if Samsung actually make it possible to support their devices we could accept some compromises. On the other hand, supporting far less secure devices missing things we consider hard requirements like memory tagging needed to provide our core feature set doesn't interest us.
OnePlus supported it on several devices but then removed it in updates fixing serious security vulnerabilities. Their non-stock verified boot support was insecure and instead of fixing it they removed it. It's likely there wasn't a clear or possible way to fix it due having a poor implementation which never worked properly. Fairphone 4 had a completely insecure implementation of verified boot trusting publicly available AOSP test keys. Having support for it really doesn't mean it works or will even keep appearing to work in future updates.
It's also just one feature. Our overall hardware security requirements are listed at https://grapheneos.org/faq#future-devices. People focus too much on relocking the device but we require a lot more than that. There are non-Pixel devices with essentially all the features we require such as the Samsung Galaxy S10+ and S10 Ultra but they don't allow using another OS without losing the security features. The updates are also still not what we expect, but if Samsung actually make it possible to support their devices we could accept some compromises. On the other hand, supporting far less secure devices missing things we consider hard requirements like memory tagging needed to provide our core feature set doesn't interest us.
The oneplus3 cannot be relocked as it wrongly trusts test-keys. It also has public EDL firehose files available allowing anyone to flash it arbitrarily even when locked or further dump ram or userdata.
I previously documented this here: https://web.archive.org/web/20250120181249/https://divestos....
I previously documented this here: https://web.archive.org/web/20250120181249/https://divestos....
[deleted]
> removal of the 3.5mm jack
Jesus Christ, this again. Just buy good wireless headphones already, gramps.
Jesus Christ, this again. Just buy good wireless headphones already, gramps.
I'm with GP on this one. I am also on a phone without 3.5 mm jack and have wireless headphones because of that. It sucks. With wired (3.5) headphones thing just worked. With wireless, I have to think about headphones' battery level. I can charge from an independent source, but that is a problem when I'm moving (but yes, powerbank would work). I can also use wired headphones through USB-C, but this is a problem in a different setting - the phone better be full or I won't be able to charge it at the same time because the port is used.
I'm sure there are valid technical reasons for removing the 3.5 jack, and I have adapted my headphones to the new situation, but man do I hate it.
I'm sure there are valid technical reasons for removing the 3.5 jack, and I have adapted my headphones to the new situation, but man do I hate it.
I would pay you (almost) anything to find me a pair that fits. It has taken me a long time to finally find a pair that I can use not only walking but also running.
Then what to do when the battery dies? They only a last a couple of years. I can replace my phone pretty easily, but how can I find another pair of earplugs? That's a process I don't want to go through again. The human-device interfaces should just work.
The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
Then what to do when the battery dies? They only a last a couple of years. I can replace my phone pretty easily, but how can I find another pair of earplugs? That's a process I don't want to go through again. The human-device interfaces should just work.
The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
What about a Bluetooth to 3.5mm dongle? They can be quite small, and then you can place your phone independent of the headphone/dongle.
USB-C headphones and DACs do exist too.
> The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
Get USB-C headphones rather than a DAC so that the DAC is in the headphones. There are high quality ones including earbuds.
> The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
Get USB-C headphones rather than a DAC so that the DAC is in the headphones. There are high quality ones including earbuds.
I would gladly pay you generous reward if you can find a pair that fits me.
I literally mean this.
I literally mean this.
USB-C headphones and DACs do exist too.
what is the screen reader story with Graphene? Is talkback supported or it is a victim of the security model?
In general, we do not reduce app compatibility by removing any useful features. Our privacy improvements are implemented in a compatible way, like Contact Scopes pretending to be the Contacts permission having been granted but users choose which contacts can be seen and which data for those is visible. The only issues with app compatibility by default are due to app bugs including apps having bugs uncovered by exploit protection features. We have toggles to work around that including a simple per-app exploit protection compatibility mode changing the values of the finer grained ones. There are also a tiny subset of apps banning using a non-Google-certified OS, which are mainly a small subset of banking apps. We do have opt-in features which reduce compatibility with non-buggy apps, but they're all opt-in, such as the Dynamic Code Loading and native debugging restrictions.
GrapheneOS includes a fork of the open source TalkBack. You need a text-to-speech implementation such as Google's Speech Recognition & Synthesis, RHVoice or eSpeak NG too. None of those is suitable for inclusion in GrapheneOS due to licensing and other reasons. There are some promising new apps based on more modern approaches which we're keeping an eye on. We may make our own text-to-speech and speech-to-text similarly. We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. The same thing is probably needed for TTS and the other direction.
You can install Google's Android Accessibility Suite for the full proprietary feature set including extended TalkBack features. It works fine on GrapheneOS. It needs sandboxed Google Play for the full feature set.
GrapheneOS includes a fork of the open source TalkBack. You need a text-to-speech implementation such as Google's Speech Recognition & Synthesis, RHVoice or eSpeak NG too. None of those is suitable for inclusion in GrapheneOS due to licensing and other reasons. There are some promising new apps based on more modern approaches which we're keeping an eye on. We may make our own text-to-speech and speech-to-text similarly. We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. The same thing is probably needed for TTS and the other direction.
You can install Google's Android Accessibility Suite for the full proprietary feature set including extended TalkBack features. It works fine on GrapheneOS. It needs sandboxed Google Play for the full feature set.
> We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support.
Why build your own instead of working with BeaconDB? Or if you predate that project, vice versa: will this be an open dataset that other projects can use and contribute back to?
I tried looking up more info about it but DDG only comes up with forum threads about workarounds
Why build your own instead of working with BeaconDB? Or if you predate that project, vice versa: will this be an open dataset that other projects can use and contribute back to?
I tried looking up more info about it but DDG only comes up with forum threads about workarounds
thanks, this was one of my main unknowns about the alternative oses.
I wonder how they handle cellular and wifi part, lot of proprietary shit in that.
Off topic but related to Android replacement on phones, let see if anyone can help me: I have an old Xiaomi Mi 9SE in a drawer, and I would like it to give it to my daughter as a Spotify player and that's it. No phone, no camera, no browser. Just Spotify.
What would be the best way to start? PostmarketOS doesn't support it, GrapheneOS is security-focused, LineageOS is basically a full-fledged Android, I don't know if I would be able to limit it as I would.
You might be able to use App pinning to stop them leaving the Spotify app...
On LineageOS with a bit of work you can also remove built-in apps like browser, camera, etc.