I really appreciate having a non-Google Android OS, free of Play services and other lock-in, and use Graphene on my own Pixel. The focus on security and hardening is also appreciated, but I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience. As-is it feels like a barebones AOSP with all the security improvements existing as a sort of hypothetical improvement in the background.
Why is this the most top voted comment? Do a lot of people really feel this way? Honestly, I feel it's ridiculous to expect this from Graphene OS. It's a privacy focused OS. If you want shiny features there is iOS.
If anything, it would be detrimental to their mission. Asking them to improve android in every way is the lawyers equivalent of ddos'ing an adversary with paperwork
It's a good idea, if not for Graphene. Graphene could be the Debian of mobile OSs, they keep doing what they do best, stay aligned with their goals, and others could use it as a base and add dancing hamsters to the bootloader.
They are already stretched a bit in terms of doing what they are comfortable and best at which is implementing privacy and security enhancements in AOSP and maintaining them across AOSP changes and upgrades (or getting them upstreamed if palatable to Google/AOSP).
They have made major usability improvements like eSIM support and network-based location. They have also been forced to work on things due to unrelenting popular demand like Android Auto support, sandboxed-google-play and the compatibility layer and Google Messages & RCS support.. to the cost of working on other security/privacy enhancements. At the end of the day, this is more a question of resources available.
I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world.
> I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world
I agree completely. I don't expect one small team to carry the weight of building an ideal OS. I'm just disappointed that while there's loads of work being done spinning up interesting desktop OSes with new paradigms for UX and system management, the same can't be said of the mobile space. Everything there is basically some slight variation on iOS.
> I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience.
i agree with the sentiment, but not for the features part. just getting the core functionality working across devices (securely of course) is already a lot of tedious work. just look at the dearth of supported devices that do not run a specific soc or from a famous brand.
for vast majority of features, one can personalize themselves by getting apps. most don't need rooting or any technical know-how. it will be unproductive to spend time ricing the os for users when they got their own personal preferences regardless. which is why it is fine to focus on getting the core things right first.
What does Android need "in terms of usability, features, and overall experience"? I personally don't feel that anything is missing. I'd love a denser battery maybe.
I'd like to see some experimentation with core system UI, like the notification/quick settings thing. I'm not convinced the weird double-pull-down hybrid thing Android uses is a good design. I'd love to see some experimentation on a multitasking system that isn't clunky and inconsistent. Some of the tweaks Samsung puts in their Android spin could be nice. I'm not expecting a security-focused team to work on this stuff, but it's too bad that nobody is. I feel like we've settled on a pretty lousy core mobile operating system paradigm, and just generally wish people were experimenting and iterating on a variety of ideas.
I see what you mean, but GrapheneOS has completely different goals. Simply put, Graphene strives to be a secure, degoogled Android. Other than that, it has the same goal as the Pixel phones: to be as close to mainline Android as possible.
It would be a complete waste of time for devs to focus on making the AOSP apps pretty. I don't really get the hate, AOSP apps are completely fine and it's not like you have to look at it all the time
Each of the AOSP apps still present in GrapheneOS going to be replaced or overhauled. They're only there as basic bundled functionality. There's no point in improving some of those apps because there are either better open source apps to use as a starting point or we can make our own instead. It would be nice to have modern Compose apps instead of a slightly improved legacy code with modern features bolted onto it.
AOSP apps look and work terrible in my opinion. The music player hasn't changed since what, Android 2?
There's a reason ROMs like LineageOS develop their own alternatives. Most ROMs seem to use those open source alternatives rather than the apps Google abandoned with AOSP.
I was talking about the AOSP apps GOS ships, which is handful and doesn't include a music player. Apart from maybe the gallery app, I don't see any other as completely unusable. They already maintain Camera, PDF viewer, Vanadium, App store and Auditor
I'm not sure what you mean. They do have a secret key used for hardware attestation, but to my knowledge it's not supported anywhere and your own build would pass attestation just as well. For apps outside the core you wouldn't even have to do that much - just fork them and install your own.
While this is awesome, I'm kinda skeptical on the premise on two points.
Almost nobody cares about privacy, and this is going to be super expensive. I might be fine with paying extra, but the economy might not work out, like it didn't for Blackphone. Fairphone is barely alive as well. Seeing as phones are just source of ad money Google can drop the prices on their phones as well.
Some European countries and banks already require crap like Play Integrity for essential apps. So far it's possible to hold out, but for how much longer?
We're working with a major Android OEM on the future generations of their existing devices meeting the official GrapheneOS requirements so we can officially support their devices. People will be able to buy the regular devices and install GrapheneOS at no extra cost. We're talking about selling devices with GrapheneOS preinstalled but that's not a requirement for the partnership to be a success and other companies could still do it as they do now with Pixels.
Play Integrity API doesn't impact GrapheneOS as much as other alternatives not focused on privacy and security in a similar way. A subset of the apps using the Play Integrity API are explicitly permitting GrapheneOS via hardware attestation including multiple banks like Swissquote. We're working on convincing more banks to permit it. Our hope is for regulators to invalidate the current approach and require defining clear security standards which need to be fairly enforced. The status quo of some banks banning using a much more secure OS that's even much more heavily using hardware-based security features while permitting a Google Mobile Services OS with no patches for 6 years is a massive antitrust issue. It impacts every alternative hardware platform and OS since Android app compatibility is important for competing. The obstacles to getting approved should also not be unreasonably high. It's better if apps don't do this but we can accept they are going to do it if it's a fair system permitting competition, unlike the Play Integrity API.
GrapheneOS user here. Every single banking and financial app I use works. Both European ones and non-European. Some require changing per-app settings, but nothing crazy. There's a good chance that your banking app will work.
Maybe the real focus should be treating Android as a single purpose environment rather than your real/life depending one.
Maybe the better approach would be focusing on getting postmarketOS to work, and use an emulation or recompilation layer that is running Android in a box (pun intended). Anbox and others were still too painful to use for daily usage, but maybe you can get rid of everything except the things that Play Integrity checks against? Maybe we can make waydroid work?
Waydroid is not a private or secure way to run Android apps. It uses an old fork of LineageOS and throws away most of the privacy and security model with how it's implemented. It does that to run Android apps on top of a much less private and secure base OS. Compatibility is far worse and it in no way avoids the Play Integrity API checks. Most banking apps do permit GrapheneOS and some of the apps banning using a non-stock OS or non-GMS devices with the Play Integrity API have explicitly permitted GrapheneOS via hardware attestation including Swissquote. Banks have no reason to ban GrapheneOS since it has all of the standard privacy and security model combined with major privacy and security improvements. They're often willing to permit it once they understand what it is and how they can verify it with a standard Android API. Convincing every app using Play Integrity to do this case-by-case is painful and unrealistic, but regulation can require permitting secure alternatives meeting defined security requirements.
why not the other way around? aosp already has a much better security posture, already runs almost everything virtualised, and will soon run 'desktop linux' apps in a vm
in fact statements from graphene suggest they hope to eventually move away from linux on the host
it won't be a special graphene phone, they are working with the OEM to make their next flagship meet graphene's security requirements; it'll just be another phone they support that isn't a pixel
You don't have to carry two phones. The idea is that the second phone stays home powered off and is used as an access token for the bank's website. There is no reason to carry it around. Pay cash in stores or use a credit card when cash is inconvenient.
I think this is a pretty outdated view of banking. I open a banking app at least a few times a day. In the EU just about every online transaction has to be approved in the app, we also use various payment apps for quick person to person transfers, use the app to generate disposable virtual cards for online purchases, etc.
I could cut myself off from the modern financial world and just use online banking like it's 2010 but that's a pretty big ask.
The US is way, way behind in banking P2P technology / fintech adoption. In many parts of Asia, even uneducated street vendors now accept digital payments via mobile phones (that's how easy it is). See - https://www.forbes.com/sites/pennylee/2024/04/17/the-us-lags... and
I would rather not have the kind of "financial innovation" that requires non-free apps running on non-free operating systems on locked down hardware. These apps, by design, track how people spend their money.
Barclays in the UK offer (or used to) a hardware device with a keypad allowing the user to do a challenge-response using the bank card's chip and PIN. Not sure if they still do, though.
What if one doesn't own an android/iphone device? Banking is a fundamental need, so most countries regulate them to cater to a wide range of users. In this case it's possible that the bank could be compelled to provide you a 2FA device if you don't have one.
I don't think there is such regulation. Many banks simply do not have any other means of authentication any more. They can't give out 2FA devices because their systems just don't support them.
That's because they're stupid or doing something suspicious, probably both.
There's legitimately zero reason to allow 2FA only on your own propreitary app. You can't even make a financial argument - allowing other TOTP methods is cheaper because now you don't need an app!
> Article 7 Requirements of the elements categorised as possession
> 1. Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.
> 2. The use by the payer of those elements shall be subject to measures designed to prevent replication of the elements.
No, because phones that lock keys in hardware effectively prevent that, and that works only with hardware that prevents its owners from having full control an doing what they want with their hardware.
"Unextractable keys" works with hardware that you don't "truly own".
What if you truly want the security properties provided by a device which can keep keys in a way where you fully control their use but its extremely hard for anyone to extract them?
it costs basically nothing to change banks. you sign up to a new one and they transfer your account and direct debits. you just tell your employer where to send your next salary payment.
I had my previous cheapo Chinese phone for 7 years. Only bought new one this year because the battery was gone and the display had some scratches. The photos are a little nicer I guess?
/e/ has extraordinarily poor privacy and security. It's largely the opposite of GrapheneOS. It's hardly focused on privacy and security. See the information available at https://discuss.grapheneos.org/d/24134-devices-lacking-stand... including the information that's linked from third party privacy and security researchers.
/e/ always uses multiple Google services and builds in privileged support for Google apps and services so the branding as a degoogled OS doesn't really make sense. GrapheneOS doesn't brand itself that way but doesn't make connections to Google servers by default and doesn't provide privileged access to Google apps and services.
It has very poor privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand.... It lags extremely far behind on kernel, driver and firmware patches even when they're available. It lags far behind on AOSP and browser patches too. As an example, /e/ on the Pixel 7 is still on Android 13 with multiple years of missing High and Critical severity kernel, firmware and driver patches since they didn't backport it to Android 13 while the Pixel 7 is on Android 16.
No, it doesn't block tracking or privacy invasive behavior by apps and it has much weaker privacy protections from apps than GrapheneOS.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
Apps mainly avoid it because their most privacy invasive features are tied to their functionality and their own servers. They can share with third party server side and mainly do that. Client side stuff is mainly far less important analytics, telemetry, crash reporting, etc. If the app or SDK wants to evade filtering client side, they just need to do their own DNS resolution via DoH using a hard-wired IP whether it's 1.1.1.1 or their own server. Facebook has IP fallbacks in several of their apps.
Because the technicalities of accomplishing something like that are quite complicated from what I understand. If an app has the necessary permissions and network access, almost anything you try to stop it from transmitting data about the platform and data about its usage is futile.
You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.
GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.
The approach used by /e/ doesn't actually work and enables fingerprinting VPN users. It only stops the least invasive tracking for client side analytics, etc. where there are single purpose domains which can be blocked. Multi-purpose domains used for both privacy invasive things and functionality don't get blocked. The app's own servers used for the most privacy invasive behaviors in practice of course don't get blocked. They can share whatever they want with arbitrary third parties through those. However, it won't get blocked client side by /e/ if it's needed for any functionality so third party services which are privacy invasive won't be blocked unless the app doesn't need them, doesn't do it server side and doesn't do basic evasion of filtering deployed in many apps by resolving DNS queries themselves or having IP fallbacks like Facebook.
Location Scopes is a planned replacement for the standard Android Mock Location feature which is rebranded in /e/ as their own feature. /e/ does not have features similar to Contact Scopes or Storage Scopes. It doesn't provide the current generation standard Android privacy protections or patches since it's always very far behind on updates. Most privacy patches aren't backported to older releases, but they lag far behind on backports and don't fully apply them despite claiming to provide a much newer patch level than they do.
Global Mock Location is a standard Android feature not specific to /e/. GrapheneOS also supports it, and is building a better replacement for it similar to our Contact Scopes and Storage Scopes features providing otherwise missing functionality in Android that's partly available in iOS. /e/ doesn't have either of those things or other privacy features such as the Sensors toggle.
/e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.
This is excellent news. I've always wanted to try GrapheneOS, but I dislike Google and dislike Pixels even more (Tensor sucks + there's the whole VoLTE/5G issue), so I never got a chance to try it out.
Hopefully they select an OEM which supports pKVM - that's the one Pixel feature I'd really like to see being implemented on other Android devices.
GrapheneOS recently added official support for forcing the availability of VoLTE, VoNR, 5G and/or VoWiFi with any carrier providing proper implementations. It was previously possible via ADB but no longer is since the December 2025 security patches which are included in our current security preview releases with the November 2025, December 2025 and January 2026 patches (https://discuss.grapheneos.org/d/27068-grapheneos-security-p...).
The devices with our OEM partner will be Snapdragon flagships with Gunyah rather than pKVM. It should still be able to support the same things. It even has official Windows guest support upstream.
The timing of this is also really important, as the EU is currently planning on rolling out mandatory app-based age verification, and currently it looks like the solution will be locked to Apple and Google phones "for security reasons". I have contacted my own government, and their answer is that they currently do not plan to support alternatives only used by a minority of citizens (absurd statement coming from a government agency). Having a major OEM actually offer a native non-Google Android phone will be really important to be able to put pressure on governments to stop locking their citizens into American big tech platforms because of will be a lot easier to argue that it is anti-competitive (which it always has been, but governments apparently don't consider postmarket operating systems as even part of the competition).
I use a Samsung Fold because I read a lot of books/manga, and I also love its multitasking features over stock Android/Pixel. Finally I also prefer it's form-factor (roughly 3:4 unfolded screen, and a narrow front screen) over other similar devices.
But it's obviously not for everyone so I can't really recommend it to everyone. And to be honest I can't in good faith recommend any Android phone these days, I hate what Google and other OEMs have done to the ecosystem.
I'm quite bullish on Linux phones though, like the FuriPhone FLX1, the Volla Phone Quintus, and the Jolla C2 - obviously again they're not for everyone, so for normies I would recommend an iPhone, and for techies I'd suggest giving the Linux phones a try (or maybe get a OnePlus/Nothing phone and load LineageOS+Magisk if you don't mind playing the cat-and-mouse game with Play Integrity).
I have no special insights, but Sony's phones seem like a good fit. They are really easy to unlock [1], but there are virtually no mods but Lineage. Maybe because they are very stock Android and bloat-free?
They range from 300 to 1000 EUR. I personally am fond of the "lower end" and slender Xperia 5 and 10 lines and the customary 21:9 screen ratio.
Don’t Sony’s have the issue of crappier photos after unlocking because of some DRM key shenanigans? This is what I remember about my old Xperia X1C and I so left for Pixel and then eventually iOS so things would just work and last longer than a year or 2.
It's more of an issue for carriers who don't sell Pixel devices, particularly in countries where the Pixel isn't sold officially (eg: New Zealand). So generally VoLTE, VoWiFi and sometimes even 5G too might not work. You can use a hack to get around that, but now Google has blocked that hack: https://news.ycombinator.com/item?id=45553764
Edit: Looks like there's an updated workaround now, but this is what I mean - it's really unacceptable that an essential feature like VoLTE - which is required to make phone calls - may not work depending on your carrier/region.
Actually I'm not sure it's reasonable to complain about a feature that you're informed won't work, on a phone that you're using in a region it's not meant to be in, doesn't work.
Yes, Pixels should probably be sold in all markets. But if you're explicitly circumventing that you shouldn't be surprised.
I disagree, because making phone calls is the most basic and core functionality of a phone, it's not just some random feature that you can simply dismiss, especially with many counties worldwide shutting down 3G networks - VoLTE is a necessity if want to make phone calls.
Google is the only major OEM (that I'm aware of) that has these deliberate draconian roadblocks to prevent VoLTE - an essential feature - from working. On OnePlus and Xiaomi devices for instance, you can always go into the engineering menu via the dialler and enable VoLTE on unsupported networks. Xiaomi even has an official code to disable carrier checks. Samsung takes it a step further and partnered with the GSMA[1] to enable VoLTE globally by default on all their Android 15+ phones. So I think it's fair to criticise Google for going in the opposite direction as other Android OEMs.
A phone bought in one region should be supposed to continue working when you travel to other regions - which people (in most parts of the world) do all the time.
And, indeed, my phones all do that. However, they don't all work with local sim cards, so something fishy is still going on, sometimes.
It's perfectly possible for VoLTE not to work in regions where no carrier provisioning information is available while foreign SIM cards work fine.
In theory a phone can just be provisioned by the network to use VoLTE, but in practice the spec allows for all kinds of incompatible configurations. Carriers and phone manufacturers won't just apply an untested configuration, and for good reason. Software upgrades have broken telecommunications from iPhones to Androids, sometimes edge cases such as calling 111/112/911/999 turn out not to work.
Falling back to 3G or even 2G on unknown networks in unsupported markets will get you voice calls, at least for the coming years.
I don't want a new phone. I am more interested in keeping older phones alive, because they are usually more than capable for my usage (banking app, web browser, maps), and the only problem is lack of updates. Thus I am more interested in LineageOS.
E-waste is bigger problem for me than few security improvements.
The patches provided by LOS aren't anywhere close enough to keep the phone secure/private. LineageOS breaks android security model in all but selected few devices, mainly Pixels I think. Your phone is very likely more secure by sticking to the original OS your phone shipped with.
My old phone is vulnerable to a kernel RCE by anyone in the vicinity for simply having Bluetooth enabled. I doubt my phone is more secure sticking with the original OS.
I am interested in why the LineageOS patches are causing security issues, though. Do you know where I can read more about this?
The most recent 3 generations of Pixels have 7 years of support rather than the 3 provided by the Pixel 4a. Pixel 4a no longer has driver or firmware updates or official support for current Android releases, so GrapheneOS doesn't officially support it anymore. We did provide extended support releases and legacy extended support releases past end-of-life until earlier this year (2025012701 was the last one), but lack of community support led to those being paused and few people still use the legacy devices based on update server stats of update check counts.
It's why 5-7 years of support are one of the requirements our OEM partner has to provide to meet our official list of requirements published at https://grapheneos.org/faq#future-devices. We'd like to require 7 years of support to match Pixels but didn't want to raise the bar too high. We can settle for 5 and have OEMs work towards 7 for later devices after starting with a 5 year commitment.
I feel you. Phones move so fast, they require a lot of compromises from the user. I am currently using a Pixel 7a, 8mm longer and 3mm wider than the 4a, and I'm reasonably happy with it. Although to be honest, I also have my pet peeve with it - the build is not as nice as my previous Samsung Galaxy S9, and I miss that. You could also consider 8a, same size as 7a, and support will last even longer, so if you get accustomed to that, there will be no need to change for a while.
The most recent 3 generations of Pixels have 7 years of support from launch. One of the hardware requirements for GrapheneOS is 5-7 years of firmware and driver security patches. We continued allowing 5 years to avoid locking ourselves into Pixels since it's the hardest requirement from https://grapheneos.org/faq#future-devices for major OEMs to fulfill. Most of the rest are done for them by Qualcomm with a flagship Snapdragon SoC.
Every time i try to switch to a libre android i encounter the same blocker of not being able to do a full backup and restore with all app data and full control without hacky, weird third party apps that don't work, just as i can do on any linux in the world. I don't understand how the android ecosystem and everyone working on this is just ignoring the data.
Same here. For me the biggest bummer with GrapheneOS is that the promised new back up system is still not even on the horizon and was promised a gazillion years ago.
I use a self-hosted Nextcloud and sync all contacts, photos and calendar with it. Having full native support for all Android apps would be pretty cool though.
The "a" models haven't been 300€ for a good while now. Launch price for 9a was 549€. So I would set that as the floor price for any speculation about this.
Finally!
Pixel hardware is a joke, the pixel 10 pro has the performance of a three year old phone, with battery life worse than the iPhone Air (according to shortcircut/ltt tests).
Even the cameras are starting to fall behind.
I had a pixel, and it just stopped working out of nowhere.
I just can't justify spending 800$+ on a phone with mid-range hardware at best
Yes their software is the best, but with such hardware it just can't compensate anymore.
I don't think I will be able to wait til GrapheneOS announces their new supported phones, probably will pick up a OnePlus with battery life that doesn't suck.
It's hopeful news. GrapheneOS have had access to security patches as part of their agreement with an OEM partner already, so I assume these discussions/plans have been with the same partner. They are also hopeful of getting full access to AOSP releases which would greatly alleviate the pain Google have put custom OS developers through recently.
I am still very surprised that any OEM is willing to commit to monthly security updates and OS upgrades for a minimum of possibly five years. I think it would be a good thing for GrapheneOS to have more than one partnership in future for the Android ecosystem as a whole.
I wonder what percentage of Pixel sales ended up running Graphene. It feels like running Graphene is the only real benefit to a Pixel. I wonder if Google is getting out of phones after Pixel 10 or 11.
Yeah, I recently upgraded to the 9a from the 4a for $250 USD and am still really enjoying Pixels. I might just be out of the loop on what's available, but I can't imagine many other phones at this price are competitive.
The A line is still a competitive midrange (at least when on sale) and if you enjoy the pixel experience there's nothing wrong with it at all.
However the regular pixel or the pro haven't been competitive in several years. This year is particularly bad because it's very close to iPhone price for less storage, less performance, worse battery life, and less easily accessible help (tech support/warranty/repair).
The usual comeback is the the pixel is fast enough so it doesn't matter. And it's kinda true. But it doesn't change the fact that it's poor value, midrange hardware for premium price.
I think with the suggestion made at the end about that google would be getting out of phones (for some reason - perhaps graphene causing google long term phone margins to no longer be worth it? What are you actually suggesting?) it's hard to really know what you're going for here.
I applaud them - finding an OEM to build a phone for an Android fork is extremely difficult, because Google conditions access to the Play store on a manufacturer not building any phones with Android forks [1]. A move so ridiculously anti-competitive and hostile that it's outrageous they haven't been sued for it yet by at least the EU. It's not only that their products spy on you - they are actively doing all they can to kill any other products. If you care about privacy, they are your enemy, it's as simple as that.
[1] While it might not be an official requirement, being granted a Google apps license will go a whole lot easier if you join the Open Handset Alliance. The OHA is a group of companies committed to Android—Google's Android—and members are contractually prohibited from building non-Google approved devices. That's right, joining the OHA requires a company to sign its life away and promise to not build a device that runs a competing Android fork. Acer was bit by this requirement when it tried to build devices that ran Alibaba's Aliyun OS in China. Aliyun is an Android fork, and when Google got wind of it, Acer was told to shut the project down or lose its access to Google apps. - https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
This is at least partially banned by the injunction from Epic vs Google:
7. For a period of three years ending on November 1, 2027, Google may not condition a payment, revenue share, or access to any Google product or service, on an agreement with an original equipment manufacturer (OEM) or carrier to preinstall the Google Play Store on any specific location on an Android device.
8. For a period of three years ending on November 1, 2027, Google may not condition a payment, revenue share, or access to any Google product or service, on an agreement with an OEM or carrier not to preinstall an Android app distribution platform or store other than the Google Play Store.
The article doesn't say that the manufacturer would ship anything with GrapheneOS. I read it as users will still get to install it themselves, which now finally will be possible with a non-Pixel device.
I would suspect that the sort of person (like myself) that would rather run GrapheneOS over LineageOS would rather install themselves than buy preinstalled. Much easier to verify no one slipped you an altered image.
Verified boot and hardware attestation enable verifying a GrapheneOS install is genuine. It can't prevent all hardware tampering but it provides very strong protection against tampering with any firmware or software.
So the Android MADA and the AFA was wholesale struck as illegal a couple years ago, both in the US and elsewhere. So this requirement cannot legally exist. Whether Google will give someone a license who also ships a fork though is certainly in question, I suspect most OEMs aren't willing to risk their business seeing if the mafia wants to follow the law. Google has such a reputation for being abusive at this point an actual agreement or rule is no longer necessary.
When I was looking, the older models were around $500. Looks like they came down in price. I also looked at used, but my company stipend/discount would only apply to new.
They have to start somewhere. Unfortunately part of the issue is that most OEMs do not even support their budget models as well as their flagships, so they would fall short of basic reasonable GrapheneOS requirements like 5+ years of timely security updates.
Of course it does. The whole point of a FOSS platform is the remove this kind of corporate control. It's your device, and you run whatever code you want on it.
By not publishing Pixel device trees Google shot themselves in the foot removing the only reason for me buying their devices, while at the same time gaining nothing. Great move :)
A lot of people will say "well, the market of people who want that is so small that its not even a blip on Google's radar", but let's cut that one off at the pass: No one buys pixel devices anymore. Their sales are abysmal, Tensor mobile silicon has been a failure, and the one thing they kinda had going for them was general good vibes with the broader tech community. But, they're Google, so they ruined that too.
I suspect there will be a Pixel 11, maybe a Pixel 12, but that'll be it.
Anyone know if partnering with a major OEM for official support makes it more likely that they will be able to consistently support things like banking apps (and maybe even payment apps) in the future?
I suspect the answer is "no" but I want to believe...
The situation you're alluding to is not a case of "GrapheneOS doesn't support banking apps" but rather "Some app publishers employ Google Play Protect and other measures in order to explicitly block GrapheneOS". GrapheneOS can not do anything about that. Choose your banking and payment apps accordingly.
FWIW I have run several banking apps on GrapheneOS without any issues whatsoever, never had any blocks or compatibility issues. Might just be luck of the draw but just to say you probably do have options.
Yes, I understand many banking apps do work and from reports I have read online it even seems like a couple of the banking apps I use are among the good ones. What gives me pause is how fragile the situation is. Banking apps get "upgraded" all the time to include new security "features". Already I have had my main banking app refuse to work because I had accessibility features enabled for a different app, and subsequently refuse to work again because I had developer mode enabled. If my banking app works on GrapheneOS I am convinced it is because the bank has not gotten round to blocking it yet and it's only a matter of time, unfortunately.
If you want your bank to take the liability for any monetary losses from your account getting hacked (for example, through spyware using accessibility on Android), then you have to be OK with their requirements.
If you don't like their requirements, you need to take the liability yourself. You could use PayPal or a stablecoin to store your money.
Or root with Magisk and hide the developer mode from the offending app. Unfortunately it's always a cat and mouse game, so for some apps it's probably easiest to have a cheap, outdated (and by some metrics thus unsafe) device in a drawer at home.
Your money is far more at risk with scams and phishing than it is with whatever boogeyman spyware you may try to think of that does not exist in real life.
Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.
Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).
These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.
> GrapheneOS can not do anything about that.
I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.
Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.
GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
They can fund the development and support work for attesting GrapheneOS along with funding support for compatibility with the os. The more users that GrapheneOS has the less money they'll need to pay to fund such a project.
I sincerely doubt it, but a large OEM with first-party support makes it (IMO) more likely for banking apps to support GApps-less handsets(instead of the inverse, Graphene supporting banking apps) - a dramatically better outcome, as that allows Waydroid more breathing room as a viable solution for Linux-first handsets too.
This would of course be contigent on GrapheneOS growing their market- and mind-share in the general public, while also taking several years to impact the least move-fast-and-break-things industry (consumer banking).
If those apps use "Play Integrity" (bad choice) then the probability is close to zero because it's Google that controls it. Other OEMs that currently pass it do it only because the device was certified by Google.
But being certified by Google of course precludes not preinstalling or sandboxing their GMS apps.
The answer is it depends. Banking and similar Apps trying to "protect" the user from themselves aka treat the user like a retarded child do this through several mechanisms:
> Google Play Integrity
Essentially a Google API that App Developers integrate that checks if the device runs an Operating System signed by Google as "Play Certified". This can go as far as being backed by a hardware trusted platform module. I doubt Google will certify GrapheneOS given their modifications towards sandboxing the play services. This can be faked to a degree but GrapheneOS choses not to do it and to fake the TPM part you need leaked keys. For more details on how to fake it look at this thread: https://xdaforums.com/t/guide-how-to-pass-strong-integrity-o...
> Fingerprinting the Device OS
This can very from app to app and just tries to fingerprint the device in many ways to see if it's running a custom rom of some kind. This does things like check to see if the bootloader is unlocked or if root is installed. I think this is something an official grapheneos phone might fix since the phone vendor could allow grapheneos to sign their releases as native equivalent
> Banning GrapheneOS by Name
Some Apps Developers literally ban GrapheneOS by name.
> Failures due to Google Play Sandboxing
Since GrapheneOS sandboxes Google Play Services there might be compatibility issues that prevent the app from working right. This would likely be unaffected by a GrapheneOS Phone.
> Failures due to Advanced Security Features
Some Apps just don't "like" the advanced security features like the hardened malloc and other protections and just fail. This can be disabled most of the time
This is good news, but I hope that the device is not a "Graphene-phone". I.e. that it's not strictly built for GOS, but that it's a good generic and open device that happens to support GOS. For example, I would like such hardware to also be able to run mainline Linux, and to be able to run GOS on other devices besides the single approved one, potentially from different manufacturers.
Graphene doesn't have the volume to get a custom flagship grade device made for them. So even if they get a device that ships with Graphene preinstalled? It's going to be a variant of another Android phone.
Which is, generally, not that good for Linux mainlining. Qualcomm SoCs are "meh" when it comes to mainline Linux support - some parts are there, but a lot of them aren't. It has been getting better for the last bit though?
I have a feeling they're working with OnePlus. They've lost their "enthusiast" vibe over the years, and officially supporting GrapheneOS could help them to reclaim it while still keeping prices high (or even justifying raising them).
I was being curious and asked ChatGPT. OnePlus came as a likely candidate there as well. Still 2027 is a long time, hopefully my phone keeps working till then xD.
I didn't want to go search for posts and speculation regarding what company maybe available so I asked it the question, and let it search the internet for me, compile the results and give me a speculative answer.
Also speculating on this issue is quite low priority for me that I didn't want to spend actual brain cycles.
Lastly I do try to find new ways to try and test ChatGPT to see how and when it works.
I wanna preface this by saying I'm really not trying to come at you here. This is just a really great microcosm of AI usage and the differences in use-cases, so though it might seem like I'm overthinking this, I'm intrigued and want to challenge you a bit if you're open to it.
I arrived at the OnePlus thing not by reading any speculation threads or anything. I was just thinking about it, just 'cuz. Thinking for the love of the game, for enjoyment. I wasn't searching for an answer -- obviously there _isn't_ one, it's all just speculation. So, already, the idea of searching the internet for other people's speculation seems pointless and antithetical the point, which is to think about it for myself.
I _certainly_ didn't think about it from the perspective of "spending actual brain cycles." As far as I know, "brain cycles" is a pretty reductive way of looking at the brain, and is fundamentally wrong in the same way that Trump was when he said that "exercise uses up the body's finite energy:" it's overly protective in a way that results in the exact opposite of what you think you're achieving. To put it more simply: "use it or lose it." I'm not worried about "spending brain cycles" (to the extent that "brain cycles" is an accurate model at all), because thinkin' 'bout stuff is precisely how I get _more_ "brain cycles," not _less_.
Which is all to say: do you seriously engage with all your potential thought avenues from this perspective? Weighing which ones are "low priority," etc? For work/programming/etc, I can understand that to a degree, but for something that can only be classified as "recreational thinking," I just do not get this _at all_.
You said in another comment in this thread that while ChatGPT does something, it frees you up to do something else. What did it free you up for?
DAVx5 works well, but it is indeed rather surprising that Graphene does not come with a calendar or an email client. I guess the idea is that you can download F-Droid and choose your own, but even F-Droid is not provided by default.
On bundling apps in general: https://grapheneos.org/faq#bundled-apps. For the calendar app particularly I think they assessed that the AOSP Calendar app was beyond saving (left to rot by AOSP/Google). I cannot remember if they still have plans to develop a calendar app.
I believe you're right that the idea is for people to download the apps they want (from wherever they choose). GrapheneOS has a complicated history with F-Droid though. Unfortunately, unless their approach was different in a lot of significant ways, it is unlikely GrapheneOS will include F-Droid in their Apps app repository.
However, Motorola/Lenovo seems the most logical partner, they were previously in the Android One program (which was sort of the successor to the Nexus line).
That would be interesting. I have long wished that Sony phones would allow re-locking the bootloader to an OS signed with my own keys.
Some of their Xperia Compact models have been excellent, but they haven't been making them like that in recent years. Dare I hope for a return of their truly compact flagship phones and GrapheneOS support?
As far as I'm aware, their flagship Xperia phones do support bootloader re-locking [1]. The problem is they haven't fulfilled GrapheneOS's other requirements: https://grapheneos.org/faq#future-devices
I use Sailfish on an Xperia 10 mod. III. Unfortunately the only Xperia models which support the full Sailfish w/Android compatibility are the way too long ones. I intensely dislike long phones. I miss my old Jolla phone (they're the maker of Sailfish), it was perfect but developed a technical problem after many years. The Xperia is clumsy when compared to the Jolla phone. Glass surfaces back and front (who thought that was a good idea? Glass is slippery, and glass breaks), sometimes slips from my hand, or wherever I put it if it's not 100% flat. Glass..well, you get the idea what happens then..
Snapdragon flagships have solid security and it's the devices made with those which ruin it. Snapdragon has both advantages and disadvantages compared to Tensor.
Pixel 6 through Pixel 9a are essentially Exynos SoC devices using standard Cortex and Mali cores. Certain components are custom including a Trusty OS TEE and secure core, a separate hardened secure element chip, image processing, TPU for neural network acceleration, etc. Tensor was mostly standard Exynos. Pixel 10 moved away from Exynos other than the cellular radio chip, but it's not clear if that is good or bad for security. It gives them more independence, choices and control to an extent but they largely licensed the IP for the components and it's not necessarily more secure. Perhaps PowerVR GPUs have better security than Mali, but that's unclear. It does appear they got GPU virtualization support through it, but Qualcomm cares a lot about virtualization too especially since they support laptops with Windows, etc.
GrapheneOS have mentioned in the past that the Qualcomm baseband processors compare well to competition in terms of security and isolation support on their respective SoCs. There may be other aspects they need to catch up to Pixels on regarding security though (like the secure element, open-source TEE etc.).
I hope it's not one of the biggest names. I hope they've decided to work with a more ethical brand to elevate their quality. How about a Graphene OS phone with a removable battery?
It's one of the major OEMs. They have a bunch of devices, so we can eventually support more than one and can have new supported models each year. Small OEMs are not currently capable of meeting our security feature and update requirements listed at https://grapheneos.org/faq#future-devices.
Fairphone 4 and Pixel 6 both launched October 2021. Fairphone 4 has an end-of-life Linux 4.19 kernel which stopped getting LTS updates vs. launching with Linux 5.10 and moving to Linux 6.1. Fairphone 4 is still on Android 13 which is end-of-life soon. Fairphone 4 lacks proper privacy/security patches since it's just getting partial backports to Android 13 which they ship 1-2 months after the official date. OEMs are allowed to ship them up to 3 months before the official date and have at least 1 month early access, so that's a longer delay than it seems. Is the way these devices marketed ethical when considering the lack of privacy, security, long term support and sustainability? Do the claims about fair treatment of workers and fair sourcing of resources have more substance? Is it better or worse than the ethics of an iPhone, which has very efficient per-unit production and far better long term support?
The iPhone also is completely closed source, has parts pairing and, most importantly if you wish to not create e-waste -- no removable battery. Even if you offer 8-10 years of security updates/android updates, I am not going to use a phone that shuts down the moment it meets a cold gust of wind...
This is the 'ethics' I was referring to.
But also remind me, since you mentioned the iPhone (even though it's completely unrelated) and fair treatment of workers... Wasn't there a series of suicides of workers producing Apple products? To a point where factories had to install netting to catch people falling? https://assets.bwbx.io/images/users/iqjWHBFdfxIU/idXSwvPwl2G...
Yeah, was kinda hoping they's work with Fairphone to fix their shit security situation... Anyway, hopefully another ethical brand fingers crossed! Thanks for the link!
Commercial partnership between open source projects and real companies can be tricky if not deadly.
I still remember CyanogenMod powering the first OnePlus One as Cyngn Co.
Lineage OS raised from the ashes of CyanogenMod.
On top of this, any ad blocking and "privacy first" project just shutters in pieces when the hardware manufacturer gives you a bunch of binary-only closed-source modules to be stuck into the kernel.
Stop using apps and run Firefox or any other open source browser. That type of privacy can be (almost) achieved that way.
But if your os runs non-auditable binaries directly into the kernel, then it's clear we are talking about dreams, not reality.
GrapheneOS isn't a product or a business. It's partnership between a non-profit organization (GrapheneOS Foundation) obligated to pursue the defined mission and a for-profit Android OEM making hardware. It's not a for-profit venture from the GrapheneOS side.
There are no closed source components in kernel space for Pixels and won't be for other devices we support either. Hardware and firmware is closed source in practice for all modern computers. Open source doesn't mean something is inherently more private or secure. In the case of hardware, you also can't verify it matches the sources in a similar way as software.
Firefox has poor security, but especially on Android where it doesn't implement sandboxing yet let alone site isolation. It has much worse exploit protections and other security protections than Chromium-based browsers.
Using web apps over native apps makes sense for reducing their access but has privacy downsides too such as trusting the servers rather than having signed releases able to provide more meaningful end-to-end encryption. Not everything can be done with web apps, especially in Firefox where there's no WebUSB, etc. as alternatives to installing native apps providing much less access to other things beyond what's required. For example, Firefox can't be used to install GrapheneOS on a device via the easy to use web installer due to lack of WebUSB despite Mozilla coming up with the early version of it as part of FirefoxOS.
I really appreciate having a non-Google Android OS, free of Play services and other lock-in, and use Graphene on my own Pixel. The focus on security and hardening is also appreciated, but I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience. As-is it feels like a barebones AOSP with all the security improvements existing as a sort of hypothetical improvement in the background.
Why is this the most top voted comment? Do a lot of people really feel this way? Honestly, I feel it's ridiculous to expect this from Graphene OS. It's a privacy focused OS. If you want shiny features there is iOS.
If anything, it would be detrimental to their mission. Asking them to improve android in every way is the lawyers equivalent of ddos'ing an adversary with paperwork
It's a good idea, if not for Graphene. Graphene could be the Debian of mobile OSs, they keep doing what they do best, stay aligned with their goals, and others could use it as a base and add dancing hamsters to the bootloader.
I mean there could be a middle ground between no shiny features at all and iOS.
There are 15 degoogled custom ROMs listed in the wiki at https://customromhardware.miraheze.org so saying this is a binary choice is just wrong.
They are already stretched a bit in terms of doing what they are comfortable and best at which is implementing privacy and security enhancements in AOSP and maintaining them across AOSP changes and upgrades (or getting them upstreamed if palatable to Google/AOSP).
They have made major usability improvements like eSIM support and network-based location. They have also been forced to work on things due to unrelenting popular demand like Android Auto support, sandboxed-google-play and the compatibility layer and Google Messages & RCS support.. to the cost of working on other security/privacy enhancements. At the end of the day, this is more a question of resources available.
I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world.
> I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world
I agree completely. I don't expect one small team to carry the weight of building an ideal OS. I'm just disappointed that while there's loads of work being done spinning up interesting desktop OSes with new paradigms for UX and system management, the same can't be said of the mobile space. Everything there is basically some slight variation on iOS.
> I wish the project were more ambitious in terms of actually improving on Android in terms of usability, features, and overall experience.
i agree with the sentiment, but not for the features part. just getting the core functionality working across devices (securely of course) is already a lot of tedious work. just look at the dearth of supported devices that do not run a specific soc or from a famous brand.
for vast majority of features, one can personalize themselves by getting apps. most don't need rooting or any technical know-how. it will be unproductive to spend time ricing the os for users when they got their own personal preferences regardless. which is why it is fine to focus on getting the core things right first.
What does Android need "in terms of usability, features, and overall experience"? I personally don't feel that anything is missing. I'd love a denser battery maybe.
I'd like to see some experimentation with core system UI, like the notification/quick settings thing. I'm not convinced the weird double-pull-down hybrid thing Android uses is a good design. I'd love to see some experimentation on a multitasking system that isn't clunky and inconsistent. Some of the tweaks Samsung puts in their Android spin could be nice. I'm not expecting a security-focused team to work on this stuff, but it's too bad that nobody is. I feel like we've settled on a pretty lousy core mobile operating system paradigm, and just generally wish people were experimenting and iterating on a variety of ideas.
A lot of people get Pixel and other "vanilla Android" phones to avoid spins like Samsung's.
I see what you mean, but GrapheneOS has completely different goals. Simply put, Graphene strives to be a secure, degoogled Android. Other than that, it has the same goal as the Pixel phones: to be as close to mainline Android as possible.
It would be a complete waste of time for devs to focus on making the AOSP apps pretty. I don't really get the hate, AOSP apps are completely fine and it's not like you have to look at it all the time
Each of the AOSP apps still present in GrapheneOS going to be replaced or overhauled. They're only there as basic bundled functionality. There's no point in improving some of those apps because there are either better open source apps to use as a starting point or we can make our own instead. It would be nice to have modern Compose apps instead of a slightly improved legacy code with modern features bolted onto it.
AOSP apps look and work terrible in my opinion. The music player hasn't changed since what, Android 2?
There's a reason ROMs like LineageOS develop their own alternatives. Most ROMs seem to use those open source alternatives rather than the apps Google abandoned with AOSP.
I was talking about the AOSP apps GOS ships, which is handful and doesn't include a music player. Apart from maybe the gallery app, I don't see any other as completely unusable. They already maintain Camera, PDF viewer, Vanadium, App store and Auditor
Anyone who doesn't like how they look has an absolute right to fix it and no right at all to complain. ;-)
They have every right to complain. They don't have any right to expect their complaints to be acted upon.
You can't fix GrapheneOS. It's not LineageOS.
I'm not sure what you mean. They do have a secret key used for hardware attestation, but to my knowledge it's not supported anywhere and your own build would pass attestation just as well. For apps outside the core you wouldn't even have to do that much - just fork them and install your own.
https://github.com/GrapheneOS/Camera
While this is awesome, I'm kinda skeptical on the premise on two points.
Almost nobody cares about privacy, and this is going to be super expensive. I might be fine with paying extra, but the economy might not work out, like it didn't for Blackphone. Fairphone is barely alive as well. Seeing as phones are just source of ad money Google can drop the prices on their phones as well.
Some European countries and banks already require crap like Play Integrity for essential apps. So far it's possible to hold out, but for how much longer?
We're working with a major Android OEM on the future generations of their existing devices meeting the official GrapheneOS requirements so we can officially support their devices. People will be able to buy the regular devices and install GrapheneOS at no extra cost. We're talking about selling devices with GrapheneOS preinstalled but that's not a requirement for the partnership to be a success and other companies could still do it as they do now with Pixels.
Play Integrity API doesn't impact GrapheneOS as much as other alternatives not focused on privacy and security in a similar way. A subset of the apps using the Play Integrity API are explicitly permitting GrapheneOS via hardware attestation including multiple banks like Swissquote. We're working on convincing more banks to permit it. Our hope is for regulators to invalidate the current approach and require defining clear security standards which need to be fairly enforced. The status quo of some banks banning using a much more secure OS that's even much more heavily using hardware-based security features while permitting a Google Mobile Services OS with no patches for 6 years is a massive antitrust issue. It impacts every alternative hardware platform and OS since Android app compatibility is important for competing. The obstacles to getting approved should also not be unreasonably high. It's better if apps don't do this but we can accept they are going to do it if it's a fair system permitting competition, unlike the Play Integrity API.
GrapheneOS user here. Every single banking and financial app I use works. Both European ones and non-European. Some require changing per-app settings, but nothing crazy. There's a good chance that your banking app will work.
https://github.com/PrivSec-dev/banking-apps-compat-report
https://privsec.dev/posts/android/banking-applications-compa...
Maybe the real focus should be treating Android as a single purpose environment rather than your real/life depending one.
Maybe the better approach would be focusing on getting postmarketOS to work, and use an emulation or recompilation layer that is running Android in a box (pun intended). Anbox and others were still too painful to use for daily usage, but maybe you can get rid of everything except the things that Play Integrity checks against? Maybe we can make waydroid work?
[1] https://waydro.id/
Waydroid is not a private or secure way to run Android apps. It uses an old fork of LineageOS and throws away most of the privacy and security model with how it's implemented. It does that to run Android apps on top of a much less private and secure base OS. Compatibility is far worse and it in no way avoids the Play Integrity API checks. Most banking apps do permit GrapheneOS and some of the apps banning using a non-stock OS or non-GMS devices with the Play Integrity API have explicitly permitted GrapheneOS via hardware attestation including Swissquote. Banks have no reason to ban GrapheneOS since it has all of the standard privacy and security model combined with major privacy and security improvements. They're often willing to permit it once they understand what it is and how they can verify it with a standard Android API. Convincing every app using Play Integrity to do this case-by-case is painful and unrealistic, but regulation can require permitting secure alternatives meeting defined security requirements.
why not the other way around? aosp already has a much better security posture, already runs almost everything virtualised, and will soon run 'desktop linux' apps in a vm
in fact statements from graphene suggest they hope to eventually move away from linux on the host
Doesn't play integrity verify the hardware among other things?
it won't be a special graphene phone, they are working with the OEM to make their next flagship meet graphene's security requirements; it'll just be another phone they support that isn't a pixel
This is the real problem: I need my phone to work with my bank. So whatever we're doing, that's the bar to clear.
Buy the cheapest updatable phone that will work for your bank(probably a used iPhone) and use a free OS for everything else.
No, I don't want to buy, take care of, and carry around 2 devices at all times. I'm not a drug dealer.
You don't have to carry two phones. The idea is that the second phone stays home powered off and is used as an access token for the bank's website. There is no reason to carry it around. Pay cash in stores or use a credit card when cash is inconvenient.
I think this is a pretty outdated view of banking. I open a banking app at least a few times a day. In the EU just about every online transaction has to be approved in the app, we also use various payment apps for quick person to person transfers, use the app to generate disposable virtual cards for online purchases, etc.
I could cut myself off from the modern financial world and just use online banking like it's 2010 but that's a pretty big ask.
Is this a EU-specific thing? In North America I've never installed a banking app, don't even know if my institution even has one.
The US is way, way behind in banking P2P technology / fintech adoption. In many parts of Asia, even uneducated street vendors now accept digital payments via mobile phones (that's how easy it is). See - https://www.forbes.com/sites/pennylee/2024/04/17/the-us-lags... and
I would rather not have the kind of "financial innovation" that requires non-free apps running on non-free operating systems on locked down hardware. These apps, by design, track how people spend their money.
I cannot stress how much I do not care. Nor does anyone else.
I want to be able to run software on my device, not fulfill some nuts low-rent fantasy that they're a rebel against the government.
Not a drug dealer but perhaps a bank dealer
so only drug dealers use two phones?
Pretty much, yes. Drug dealers and people who are getting paid to carry a second device for work by their employer. I am neither.
I use 4 different banks, they all work with GrapheneOS.
I use 3 banks, they all work as well. Plus they're all on a separate user profile, which makes it even more secure.
Is there something important in banking apps that cannot be done with a web browser?
My bank uses the banking app for auth if I try and login via a browser.
Barclays in the UK offer (or used to) a hardware device with a keypad allowing the user to do a challenge-response using the bank card's chip and PIN. Not sure if they still do, though.
Edit: https://en.wikipedia.org/wiki/Chip_Authentication_Program
What if one doesn't own an android/iphone device? Banking is a fundamental need, so most countries regulate them to cater to a wide range of users. In this case it's possible that the bank could be compelled to provide you a 2FA device if you don't have one.
I don't think there is such regulation. Many banks simply do not have any other means of authentication any more. They can't give out 2FA devices because their systems just don't support them.
Good luck with that, in Germany many public transport operators are moving into app based tickets for the monthly/yearly subscriptions.
You can still get a plastic card, however it requires paying extra and some additional forms, the reasoning being it is not environment friendly.
Do they offer a physical 2FA device? Mine does and it's really useful
That's because they're stupid or doing something suspicious, probably both.
There's legitimately zero reason to allow 2FA only on your own propreitary app. You can't even make a financial argument - allowing other TOTP methods is cheaper because now you don't need an app!
Unfortunately the EU regulation makes the truly user controlled 2FA methods essentially non-compliant.
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
> Article 7 Requirements of the elements categorised as possession
> 1. Payment service providers shall adopt measures to mitigate the risk that the elements of strong customer authentication categorised as possession are used by unauthorised parties.
> 2. The use by the payer of those elements shall be subject to measures designed to prevent replication of the elements.
This says something along the lines of "it should be hard to extract the TOTP secret".
However if you can get so far as to get the secret from the TOTP app, you can as well back up the entire phone and restore elsewhere, can't you?
No, because phones that lock keys in hardware effectively prevent that, and that works only with hardware that prevents its owners from having full control an doing what they want with their hardware.
"Unextractable keys" works with hardware that you don't "truly own".
What if you truly want the security properties provided by a device which can keep keys in a way where you fully control their use but its extremely hard for anyone to extract them?
> That's because they're stupid or doing something suspicious, probably both
Small comfort for whoever needs to use that bank. This is the disconnect geeks and Free Software needs to bridge to make any headway.
I mean, I concur, but ultimately I can't fix shitty banks being shitty. No geeks can. Banks have been shitty for a long, long time.
Do you know how we usually stop them from being shitty? Forcefully, with legislation.
it costs basically nothing to change banks. you sign up to a new one and they transfer your account and direct debits. you just tell your employer where to send your next salary payment.
Sometimes it’s more complicated than that. And the other banks aren’t any less “stupid”.
Lloyds has perfectly good online banking through the browser. there, done the work for you.
What more do you want your phone to do at this point?
work in 10 years
I'm with you, but we're not far from that?
I had my previous cheapo Chinese phone for 7 years. Only bought new one this year because the battery was gone and the display had some scratches. The photos are a little nicer I guess?
an in-built stylus + swipe input to help avoid RSI
Swipe input isn't the responsibility of the OS. Just install a keyboard that offers it.
You might like /e/OS. It's less secure/hardened than Graphene, but offers a de-Googled Android with a focus on privacy and usability.
/e/ has extraordinarily poor privacy and security. It's largely the opposite of GrapheneOS. It's hardly focused on privacy and security. See the information available at https://discuss.grapheneos.org/d/24134-devices-lacking-stand... including the information that's linked from third party privacy and security researchers.
/e/ always uses multiple Google services and builds in privileged support for Google apps and services so the branding as a degoogled OS doesn't really make sense. GrapheneOS doesn't brand itself that way but doesn't make connections to Google servers by default and doesn't provide privileged access to Google apps and services.
It uses microG which has its own set of issues, though.
It has very poor privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand.... It lags extremely far behind on kernel, driver and firmware patches even when they're available. It lags far behind on AOSP and browser patches too. As an example, /e/ on the Pixel 7 is still on Android 13 with multiple years of missing High and Critical severity kernel, firmware and driver patches since they didn't backport it to Android 13 while the Pixel 7 is on Android 16.
And it's a 1:1 copy of LineageOS, so there's that.
The base operating system is quite far behind on app compatibility, privacy and "deGoogling" in comparison to GrapheneOS https://eylenburg.github.io/android_comparison.htm.
/e/OS blocks trackers in apps out of the box. AFAIK Graphene doesn't do anything similar.
No, it doesn't block tracking or privacy invasive behavior by apps and it has much weaker privacy protections from apps than GrapheneOS.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
Apps mainly avoid it because their most privacy invasive features are tied to their functionality and their own servers. They can share with third party server side and mainly do that. Client side stuff is mainly far less important analytics, telemetry, crash reporting, etc. If the app or SDK wants to evade filtering client side, they just need to do their own DNS resolution via DoH using a hard-wired IP whether it's 1.1.1.1 or their own server. Facebook has IP fallbacks in several of their apps.
Because the technicalities of accomplishing something like that are quite complicated from what I understand. If an app has the necessary permissions and network access, almost anything you try to stop it from transmitting data about the platform and data about its usage is futile.
You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.
GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.
The approach used by /e/ doesn't actually work and enables fingerprinting VPN users. It only stops the least invasive tracking for client side analytics, etc. where there are single purpose domains which can be blocked. Multi-purpose domains used for both privacy invasive things and functionality don't get blocked. The app's own servers used for the most privacy invasive behaviors in practice of course don't get blocked. They can share whatever they want with arbitrary third parties through those. However, it won't get blocked client side by /e/ if it's needed for any functionality so third party services which are privacy invasive won't be blocked unless the app doesn't need them, doesn't do it server side and doesn't do basic evasion of filtering deployed in many apps by resolving DNS queries themselves or having IP fallbacks like Facebook.
Location Scopes is a planned replacement for the standard Android Mock Location feature which is rebranded in /e/ as their own feature. /e/ does not have features similar to Contact Scopes or Storage Scopes. It doesn't provide the current generation standard Android privacy protections or patches since it's always very far behind on updates. Most privacy patches aren't backported to older releases, but they lag far behind on backports and don't fully apply them despite claiming to provide a much newer patch level than they do.
/e/OS has native support for feeding fake data to apps, too: https://doc.e.foundation/support-topics/advanced_privacy#fak...
Global Mock Location is a standard Android feature not specific to /e/. GrapheneOS also supports it, and is building a better replacement for it similar to our Contact Scopes and Storage Scopes features providing otherwise missing functionality in Android that's partly available in iOS. /e/ doesn't have either of those things or other privacy features such as the Sensors toggle.
/e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.
I can't trust someone that names their product /e/OS.
This is excellent news. I've always wanted to try GrapheneOS, but I dislike Google and dislike Pixels even more (Tensor sucks + there's the whole VoLTE/5G issue), so I never got a chance to try it out.
Hopefully they select an OEM which supports pKVM - that's the one Pixel feature I'd really like to see being implemented on other Android devices.
GrapheneOS recently added official support for forcing the availability of VoLTE, VoNR, 5G and/or VoWiFi with any carrier providing proper implementations. It was previously possible via ADB but no longer is since the December 2025 security patches which are included in our current security preview releases with the November 2025, December 2025 and January 2026 patches (https://discuss.grapheneos.org/d/27068-grapheneos-security-p...).
The devices with our OEM partner will be Snapdragon flagships with Gunyah rather than pKVM. It should still be able to support the same things. It even has official Windows guest support upstream.
All android devices launched with android 15 or newer need to support Android Virtualization Framework. So there will be support for VMs.
The timing of this is also really important, as the EU is currently planning on rolling out mandatory app-based age verification, and currently it looks like the solution will be locked to Apple and Google phones "for security reasons". I have contacted my own government, and their answer is that they currently do not plan to support alternatives only used by a minority of citizens (absurd statement coming from a government agency). Having a major OEM actually offer a native non-Google Android phone will be really important to be able to put pressure on governments to stop locking their citizens into American big tech platforms because of will be a lot easier to argue that it is anti-competitive (which it always has been, but governments apparently don't consider postmarket operating systems as even part of the competition).
Curious, what phone would you recommend/do you use?
I use a Samsung Fold because I read a lot of books/manga, and I also love its multitasking features over stock Android/Pixel. Finally I also prefer it's form-factor (roughly 3:4 unfolded screen, and a narrow front screen) over other similar devices.
But it's obviously not for everyone so I can't really recommend it to everyone. And to be honest I can't in good faith recommend any Android phone these days, I hate what Google and other OEMs have done to the ecosystem.
I'm quite bullish on Linux phones though, like the FuriPhone FLX1, the Volla Phone Quintus, and the Jolla C2 - obviously again they're not for everyone, so for normies I would recommend an iPhone, and for techies I'd suggest giving the Linux phones a try (or maybe get a OnePlus/Nothing phone and load LineageOS+Magisk if you don't mind playing the cat-and-mouse game with Play Integrity).
I have no special insights, but Sony's phones seem like a good fit. They are really easy to unlock [1], but there are virtually no mods but Lineage. Maybe because they are very stock Android and bloat-free?
They range from 300 to 1000 EUR. I personally am fond of the "lower end" and slender Xperia 5 and 10 lines and the customary 21:9 screen ratio.
[1] https://developer.sony.com/open-source/aosp-on-xperia-open-d...
Don’t Sony’s have the issue of crappier photos after unlocking because of some DRM key shenanigans? This is what I remember about my old Xperia X1C and I so left for Pixel and then eventually iOS so things would just work and last longer than a year or 2.
What is the VoLTE/5G issue? On T-Mobile, haven't had any issues with it living in a pretty rural spot. Isn't that like a Verizon problem?
It's more of an issue for carriers who don't sell Pixel devices, particularly in countries where the Pixel isn't sold officially (eg: New Zealand). So generally VoLTE, VoWiFi and sometimes even 5G too might not work. You can use a hack to get around that, but now Google has blocked that hack: https://news.ycombinator.com/item?id=45553764
Edit: Looks like there's an updated workaround now, but this is what I mean - it's really unacceptable that an essential feature like VoLTE - which is required to make phone calls - may not work depending on your carrier/region.
GrapheneOS recently added toggles to work around this https://grapheneos.org/releases#2025100300
Actually I'm not sure it's reasonable to complain about a feature that you're informed won't work, on a phone that you're using in a region it's not meant to be in, doesn't work.
Yes, Pixels should probably be sold in all markets. But if you're explicitly circumventing that you shouldn't be surprised.
I disagree, because making phone calls is the most basic and core functionality of a phone, it's not just some random feature that you can simply dismiss, especially with many counties worldwide shutting down 3G networks - VoLTE is a necessity if want to make phone calls.
Google is the only major OEM (that I'm aware of) that has these deliberate draconian roadblocks to prevent VoLTE - an essential feature - from working. On OnePlus and Xiaomi devices for instance, you can always go into the engineering menu via the dialler and enable VoLTE on unsupported networks. Xiaomi even has an official code to disable carrier checks. Samsung takes it a step further and partnered with the GSMA[1] to enable VoLTE globally by default on all their Android 15+ phones. So I think it's fair to criticise Google for going in the opposite direction as other Android OEMs.
[1] https://www.mobileworldlive.com/gsma/gsma-samsung-team-on-vo...
A phone bought in one region should be supposed to continue working when you travel to other regions - which people (in most parts of the world) do all the time. And, indeed, my phones all do that. However, they don't all work with local sim cards, so something fishy is still going on, sometimes.
VoLTE roaming isn't quite as easy as "log in to the network and connect to the local SIP server". There's a lot of interplay with the home carrier: https://moniem-tech.com/2024/01/01/what-is-volte-roaming/
It's perfectly possible for VoLTE not to work in regions where no carrier provisioning information is available while foreign SIM cards work fine.
In theory a phone can just be provisioned by the network to use VoLTE, but in practice the spec allows for all kinds of incompatible configurations. Carriers and phone manufacturers won't just apply an untested configuration, and for good reason. Software upgrades have broken telecommunications from iPhones to Androids, sometimes edge cases such as calling 111/112/911/999 turn out not to work.
Falling back to 3G or even 2G on unknown networks in unsupported markets will get you voice calls, at least for the coming years.
it's not complaining to tell people not to buy a phone that doesn't work.
I don't want a new phone. I am more interested in keeping older phones alive, because they are usually more than capable for my usage (banking app, web browser, maps), and the only problem is lack of updates. Thus I am more interested in LineageOS.
E-waste is bigger problem for me than few security improvements.
The patches provided by LOS aren't anywhere close enough to keep the phone secure/private. LineageOS breaks android security model in all but selected few devices, mainly Pixels I think. Your phone is very likely more secure by sticking to the original OS your phone shipped with.
My old phone is vulnerable to a kernel RCE by anyone in the vicinity for simply having Bluetooth enabled. I doubt my phone is more secure sticking with the original OS.
I am interested in why the LineageOS patches are causing security issues, though. Do you know where I can read more about this?
https://eylenburg.github.io/android_comparison.htm
https://www.kuketz-blog.de/lineageos-weder-sicher-noch-daten... (use browser's or google's translate)
GOS developers have many numerous comments about this, if you google "LineageOS grapheneos" you should also find plenty of them.
What do you think about selling your old phone, and buying a used Pixel? This would get you a Graphene-approved phone, but generate no e-waste.
My Pixel 4a is perfect phone for me (I hate big phones), but Graphene dropped support quite while ago.
The most recent 3 generations of Pixels have 7 years of support rather than the 3 provided by the Pixel 4a. Pixel 4a no longer has driver or firmware updates or official support for current Android releases, so GrapheneOS doesn't officially support it anymore. We did provide extended support releases and legacy extended support releases past end-of-life until earlier this year (2025012701 was the last one), but lack of community support led to those being paused and few people still use the legacy devices based on update server stats of update check counts.
It's why 5-7 years of support are one of the requirements our OEM partner has to provide to meet our official list of requirements published at https://grapheneos.org/faq#future-devices. We'd like to require 7 years of support to match Pixels but didn't want to raise the bar too high. We can settle for 5 and have OEMs work towards 7 for later devices after starting with a 5 year commitment.
I feel you. Phones move so fast, they require a lot of compromises from the user. I am currently using a Pixel 7a, 8mm longer and 3mm wider than the 4a, and I'm reasonably happy with it. Although to be honest, I also have my pet peeve with it - the build is not as nice as my previous Samsung Galaxy S9, and I miss that. You could also consider 8a, same size as 7a, and support will last even longer, so if you get accustomed to that, there will be no need to change for a while.
The most recent 3 generations of Pixels have 7 years of support from launch. One of the hardware requirements for GrapheneOS is 5-7 years of firmware and driver security patches. We continued allowing 5 years to avoid locking ourselves into Pixels since it's the hardest requirement from https://grapheneos.org/faq#future-devices for major OEMs to fulfill. Most of the rest are done for them by Qualcomm with a flagship Snapdragon SoC.
They made this "announcement" around 80 days ago here on HN :) [1]
1- https://news.ycombinator.com/item?id=44676691#44678172
The tone of this announcement seems a lot more certain than the previous one, at least.
I remember reading that comment. Disappointing article, but good to know it's still in progress.
Every time i try to switch to a libre android i encounter the same blocker of not being able to do a full backup and restore with all app data and full control without hacky, weird third party apps that don't work, just as i can do on any linux in the world. I don't understand how the android ecosystem and everyone working on this is just ignoring the data.
Same here. For me the biggest bummer with GrapheneOS is that the promised new back up system is still not even on the horizon and was promised a gazillion years ago.
I use a self-hosted Nextcloud and sync all contacts, photos and calendar with it. Having full native support for all Android apps would be pretty cool though.
I've used CalyxOS and Iode on my FP4, both roms integrated with Seedvault and making a full backup was seamless. Which roms have you tried, then?
"GrapheneOS didn’t reveal the name of its new partner, but said that those devices will be priced in the same range as Pixels"
which means what?
~300€ like the "A" models?
~1000€ like the pro models? both?
The "a" models haven't been 300€ for a good while now. Launch price for 9a was 549€. So I would set that as the floor price for any speculation about this.
Well you don't have to buy on launch date. I bought both the 6a and th 8a six months after release and they both were 300-ish
9pro was like 1300€ on launch, it's already 900-ish
Sure but that's not relevant when talking about "will be priced like Pixels".
Sadly, I believe that only 1000€+ models are meant here.
Knowing that OnePlus has been the most friendly for alternative OSes, I believe that the newer OnePlus Phones will get GrapheneOS builds.
It's hard to believe that Samsung, Huawei or Xiaomi are going to partner with them.
Finally! Pixel hardware is a joke, the pixel 10 pro has the performance of a three year old phone, with battery life worse than the iPhone Air (according to shortcircut/ltt tests).
Even the cameras are starting to fall behind.
I had a pixel, and it just stopped working out of nowhere. I just can't justify spending 800$+ on a phone with mid-range hardware at best Yes their software is the best, but with such hardware it just can't compensate anymore.
I don't think I will be able to wait til GrapheneOS announces their new supported phones, probably will pick up a OnePlus with battery life that doesn't suck.
It's hopeful news. GrapheneOS have had access to security patches as part of their agreement with an OEM partner already, so I assume these discussions/plans have been with the same partner. They are also hopeful of getting full access to AOSP releases which would greatly alleviate the pain Google have put custom OS developers through recently.
I am still very surprised that any OEM is willing to commit to monthly security updates and OS upgrades for a minimum of possibly five years. I think it would be a good thing for GrapheneOS to have more than one partnership in future for the Android ecosystem as a whole.
I wonder what percentage of Pixel sales ended up running Graphene. It feels like running Graphene is the only real benefit to a Pixel. I wonder if Google is getting out of phones after Pixel 10 or 11.
Could estimate ~1% (+/- 1%) given the Graphene user estimates [1] and the tens of millions of Pixels sold at this point.
[1] https://discuss.grapheneos.org/d/21946-grapheneos-popularity...
Interesting, I wouldn't have guessed they had tens of millions active.
1% of "tens of millions" is hundreds of thousands.
> only real benefit to running a pixel
Not a phrase I expected to read, whew. Tough customers.
I've been very happy with several generations of pixels at this point compared to the alternatives.
Yeah, I recently upgraded to the 9a from the 4a for $250 USD and am still really enjoying Pixels. I might just be out of the loop on what's available, but I can't imagine many other phones at this price are competitive.
6a to 9a here too!
The A line is still a competitive midrange (at least when on sale) and if you enjoy the pixel experience there's nothing wrong with it at all.
However the regular pixel or the pro haven't been competitive in several years. This year is particularly bad because it's very close to iPhone price for less storage, less performance, worse battery life, and less easily accessible help (tech support/warranty/repair).
The usual comeback is the the pixel is fast enough so it doesn't matter. And it's kinda true. But it doesn't change the fact that it's poor value, midrange hardware for premium price.
I've had the Pixel 1, 3, 5 and now 10 Pro. Each of the first three were the best phone I'd ever had up to that point in time. I still miss the 5.
It's probably a negligible percentage. Installing custom ROMs is niche even within the tech crowd.
Typical mind fallacy.
According to one estimate, there are about 250k total GrapheneOS users https://discuss.grapheneos.org/d/12281-how-many-grapheneos-u...
This source claims Google shipped 10 million devices last year https://coolest-gadgets.com/google-pixel-smartphones-statist...
If we generously assume every GrapheneOS user bought a new phone in the last year, 2.5% of those Pixels are running Graphene.
Is it a fallacy if I never made a claim about percentage?
I think with the suggestion made at the end about that google would be getting out of phones (for some reason - perhaps graphene causing google long term phone margins to no longer be worth it? What are you actually suggesting?) it's hard to really know what you're going for here.
I applaud them - finding an OEM to build a phone for an Android fork is extremely difficult, because Google conditions access to the Play store on a manufacturer not building any phones with Android forks [1]. A move so ridiculously anti-competitive and hostile that it's outrageous they haven't been sued for it yet by at least the EU. It's not only that their products spy on you - they are actively doing all they can to kill any other products. If you care about privacy, they are your enemy, it's as simple as that.
[1] While it might not be an official requirement, being granted a Google apps license will go a whole lot easier if you join the Open Handset Alliance. The OHA is a group of companies committed to Android—Google's Android—and members are contractually prohibited from building non-Google approved devices. That's right, joining the OHA requires a company to sign its life away and promise to not build a device that runs a competing Android fork. Acer was bit by this requirement when it tried to build devices that ran Alibaba's Aliyun OS in China. Aliyun is an Android fork, and when Google got wind of it, Acer was told to shut the project down or lose its access to Google apps. - https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
This is at least partially banned by the injunction from Epic vs Google:
https://storage.courtlistener.com/recap/gov.uscourts.cand.37...The article doesn't say that the manufacturer would ship anything with GrapheneOS. I read it as users will still get to install it themselves, which now finally will be possible with a non-Pixel device.
GrapheneOS' Reddit comment shown in the article says "selling devices with GrapheneOS preinstalled would be nice but wouldn't be required".
To me that sounds like devices with GrapheneOS preinstalled is not gonna happen.
It will likely happen after the initial generation with official support. It's hard to do it for the initial generation, but it's possible.
I would suspect that the sort of person (like myself) that would rather run GrapheneOS over LineageOS would rather install themselves than buy preinstalled. Much easier to verify no one slipped you an altered image.
Verified boot and hardware attestation enable verifying a GrapheneOS install is genuine. It can't prevent all hardware tampering but it provides very strong protection against tampering with any firmware or software.
So the Android MADA and the AFA was wholesale struck as illegal a couple years ago, both in the US and elsewhere. So this requirement cannot legally exist. Whether Google will give someone a license who also ships a fork though is certainly in question, I suspect most OEMs aren't willing to risk their business seeing if the mafia wants to follow the law. Google has such a reputation for being abusive at this point an actual agreement or rule is no longer necessary.
This could be really good considering current events in the android space.
"GrapheneOS didn’t reveal the name of its new partner, but said that those devices will be priced in the same range as Pixels"
Boo
Yep. I like my midrange phone I got for ~$300. I'm not paying top-dollar just for GrapheneOS.
Pixel 9a was $350 during last week's Amazon prime day sale. Currently at $399. Likely to go down again for Black Friday, etc..
I'd love a phone around that price that would run Graphene.
Why not just buy an older pixel a model ...? Like a 7a ... It is cheaper and runs GOS.
I personally can't buy phones without physical dual sim.
Dual eSIMs when travelling have failed me too many times.
Everything is moving to esim.
Enshittification at its finest to save a $.
Yet another attempt by carriers and phone manufacturers to take away control from users.
When I was looking, the older models were around $500. Looks like they came down in price. I also looked at used, but my company stipend/discount would only apply to new.
you can get a used 6a for ~$160
You get a used 7a for that price.
I bought the previous year's Pixel model for about $300 to run GrapheneOS, and I'm pretty happy about it.
They have to start somewhere. Unfortunately part of the issue is that most OEMs do not even support their budget models as well as their flagships, so they would fall short of basic reasonable GrapheneOS requirements like 5+ years of timely security updates.
Oh, good. There's going to be a migration path for F-Droid users after Google's latest actions.
[dead]
Amazing news!!! Google is incapable of selling their phones worldwide. Here's to hoping GrapheneOS's new phones will be easier to get hold of.
And does it allow "side loading"? Privacy might not be the only draw!
Of course it does. The whole point of a FOSS platform is the remove this kind of corporate control. It's your device, and you run whatever code you want on it.
By not publishing Pixel device trees Google shot themselves in the foot removing the only reason for me buying their devices, while at the same time gaining nothing. Great move :)
A lot of people will say "well, the market of people who want that is so small that its not even a blip on Google's radar", but let's cut that one off at the pass: No one buys pixel devices anymore. Their sales are abysmal, Tensor mobile silicon has been a failure, and the one thing they kinda had going for them was general good vibes with the broader tech community. But, they're Google, so they ruined that too.
I suspect there will be a Pixel 11, maybe a Pixel 12, but that'll be it.
> No one buys pixel devices anymore
From the numbers I've read, Pixels are doing just fine: https://www.phonearena.com/news/google-top-five-premium-smar... and https://www.androidcentral.com/phones/google-pixel/google-pi... both claim Pixel sales shot up this very year.
Google will lose maybe one percent of sales on GrapheneOS dropping Pixels, but that's not going to make a dent into their sales figures.
Oh I hope it's one that makes flippables. It'd be hard to go back to mega-slabs now.
Anyone know if partnering with a major OEM for official support makes it more likely that they will be able to consistently support things like banking apps (and maybe even payment apps) in the future?
I suspect the answer is "no" but I want to believe...
The situation you're alluding to is not a case of "GrapheneOS doesn't support banking apps" but rather "Some app publishers employ Google Play Protect and other measures in order to explicitly block GrapheneOS". GrapheneOS can not do anything about that. Choose your banking and payment apps accordingly.
FWIW I have run several banking apps on GrapheneOS without any issues whatsoever, never had any blocks or compatibility issues. Might just be luck of the draw but just to say you probably do have options.
Yes, I understand many banking apps do work and from reports I have read online it even seems like a couple of the banking apps I use are among the good ones. What gives me pause is how fragile the situation is. Banking apps get "upgraded" all the time to include new security "features". Already I have had my main banking app refuse to work because I had accessibility features enabled for a different app, and subsequently refuse to work again because I had developer mode enabled. If my banking app works on GrapheneOS I am convinced it is because the bank has not gotten round to blocking it yet and it's only a matter of time, unfortunately.
If you want your bank to take the liability for any monetary losses from your account getting hacked (for example, through spyware using accessibility on Android), then you have to be OK with their requirements.
If you don't like their requirements, you need to take the liability yourself. You could use PayPal or a stablecoin to store your money.
Or root with Magisk and hide the developer mode from the offending app. Unfortunately it's always a cat and mouse game, so for some apps it's probably easiest to have a cheap, outdated (and by some metrics thus unsafe) device in a drawer at home.
Your money is far more at risk with scams and phishing than it is with whatever boogeyman spyware you may try to think of that does not exist in real life.
There has to be a limit here. Blocking accessibility in the name of security is piece of shit behavior. That's uh, a technical term.
Banks have plenty of money. They don't need to be up your ass to keep liability down.
Spyware using accessibility on Android still makes Play Integrity valid.
We're in this funny situation where the hacked and outdated device is considered more "secure" by Google because Google controls it
> GrapheneOS can not do anything about that.
OEM support is a step toward passing integrity, and that's what those apps are looking for.
> Google Play Protect
Play Protect really is the root of all evil, Google certainly seems to be incentivized to write services like Play Protect that effectively act like malware/spyware in order to force users to see more ads by making it as difficult as possible to run effective system wide ad-blockers on mobile devices by crippling the ability of users to run non-Google sanctioned code on their devices at high enough privilege levels. They've deliberately designed Play Protect for maximum user hostility instead of trying to come up with ways to provide security while maintaining user freedom. For example they could have instead implemented much stronger sand-boxing of apps so that apps would have as little knowledge as possible regarding what type of environment they are running in, similar to webapps, yet they chose the exact opposite approach and went out of their to prevent users from restricting app permissions/system visibility deliberately.
Additionally the sideload blocking plan they published seems to be effectively Google deliberately using installation whitelisting in order to prevent users from removing ads from apps with tools like revanced(revanced is an APK patcher and relies on the ability to effectively self sign/install APK's without googles approval if running on bootloader locked devices).
These elaborate user hostile schemes of theirs even uses similar dubious technical justifications as manifest V3's ad-block crippling did for Chrome.
> GrapheneOS can not do anything about that.
I mean, they could help write exploits to help users bypass the Play Protect malware/spyware I suppose, although that probably doesn't align with their goals. I'm really not sure what other practical options there are in regards to fighting these malicious spyware services that Google wants to force on everyone.
Since Google doesn't have effective full control over the Android hardware supply chain like Apple does undermining the Play Protect spyware scheme should be much easier as one probably just needs to come up with some key extraction attacks against certified Android devices with terrible hardware security(lot of cheap Chinese SoC's used in Android phones that have rather poor cryptographic key protections). In theory one can then use extracted attestation keys to emulate a secure boot chain in software on other devices along with sufficient sandboxing to trick Play Protect into thinking it's running on a Google sanctioned bootloader locked device even when running with a custom OS.
>GrapheneOS can not do anything about that.
GrapheneOS does not include any of the Google apps that implement Play Protect. You can install them, but they run in the sandbox like normal apps and so are not highly privileged. They are unable to block installation of apps, install apps or uninstall apps as they are on stock Androids
>GrapheneOS can not do anything about that
They can fund the development and support work for attesting GrapheneOS along with funding support for compatibility with the os. The more users that GrapheneOS has the less money they'll need to pay to fund such a project.
I sincerely doubt it, but a large OEM with first-party support makes it (IMO) more likely for banking apps to support GApps-less handsets(instead of the inverse, Graphene supporting banking apps) - a dramatically better outcome, as that allows Waydroid more breathing room as a viable solution for Linux-first handsets too.
This would of course be contigent on GrapheneOS growing their market- and mind-share in the general public, while also taking several years to impact the least move-fast-and-break-things industry (consumer banking).
But still, a man can dream.
If those apps use "Play Integrity" (bad choice) then the probability is close to zero because it's Google that controls it. Other OEMs that currently pass it do it only because the device was certified by Google.
But being certified by Google of course precludes not preinstalling or sandboxing their GMS apps.
The answer is it depends. Banking and similar Apps trying to "protect" the user from themselves aka treat the user like a retarded child do this through several mechanisms:
> Google Play Integrity
Essentially a Google API that App Developers integrate that checks if the device runs an Operating System signed by Google as "Play Certified". This can go as far as being backed by a hardware trusted platform module. I doubt Google will certify GrapheneOS given their modifications towards sandboxing the play services. This can be faked to a degree but GrapheneOS choses not to do it and to fake the TPM part you need leaked keys. For more details on how to fake it look at this thread: https://xdaforums.com/t/guide-how-to-pass-strong-integrity-o...
> Fingerprinting the Device OS
This can very from app to app and just tries to fingerprint the device in many ways to see if it's running a custom rom of some kind. This does things like check to see if the bootloader is unlocked or if root is installed. I think this is something an official grapheneos phone might fix since the phone vendor could allow grapheneos to sign their releases as native equivalent
> Banning GrapheneOS by Name
Some Apps Developers literally ban GrapheneOS by name.
> Failures due to Google Play Sandboxing
Since GrapheneOS sandboxes Google Play Services there might be compatibility issues that prevent the app from working right. This would likely be unaffected by a GrapheneOS Phone.
> Failures due to Advanced Security Features
Some Apps just don't "like" the advanced security features like the hardened malloc and other protections and just fail. This can be disabled most of the time
If the phone is rooted, most banks will not support it. That includes grapheneOS.
Your phone isn't rooted on GrapheneOS.
GOS isn't rooted.
Apologies meant bootloader unlocked
I hope it's gonna be Sony with x10 vii/viii.
This is good news, but I hope that the device is not a "Graphene-phone". I.e. that it's not strictly built for GOS, but that it's a good generic and open device that happens to support GOS. For example, I would like such hardware to also be able to run mainline Linux, and to be able to run GOS on other devices besides the single approved one, potentially from different manufacturers.
Graphene doesn't have the volume to get a custom flagship grade device made for them. So even if they get a device that ships with Graphene preinstalled? It's going to be a variant of another Android phone.
Which is, generally, not that good for Linux mainlining. Qualcomm SoCs are "meh" when it comes to mainline Linux support - some parts are there, but a lot of them aren't. It has been getting better for the last bit though?
https://news.ycombinator.com/item?id=45586622
I have a feeling they're working with OnePlus. They've lost their "enthusiast" vibe over the years, and officially supporting GrapheneOS could help them to reclaim it while still keeping prices high (or even justifying raising them).
I was being curious and asked ChatGPT. OnePlus came as a likely candidate there as well. Still 2027 is a long time, hopefully my phone keeps working till then xD.
I really don't mean any offense here, but...why did you ask ChatGPT? What value did that give you instead of just, you know, thinking about it?
It is only useful if you are too “lazy” to do something. It is never useful if you are already capable of doing the thing
You need to broaden your horizons, mate. While an LLM does something for me, I am free to do something else.
I didn't want to go search for posts and speculation regarding what company maybe available so I asked it the question, and let it search the internet for me, compile the results and give me a speculative answer.
Also speculating on this issue is quite low priority for me that I didn't want to spend actual brain cycles.
Lastly I do try to find new ways to try and test ChatGPT to see how and when it works.
I wanna preface this by saying I'm really not trying to come at you here. This is just a really great microcosm of AI usage and the differences in use-cases, so though it might seem like I'm overthinking this, I'm intrigued and want to challenge you a bit if you're open to it.
I arrived at the OnePlus thing not by reading any speculation threads or anything. I was just thinking about it, just 'cuz. Thinking for the love of the game, for enjoyment. I wasn't searching for an answer -- obviously there _isn't_ one, it's all just speculation. So, already, the idea of searching the internet for other people's speculation seems pointless and antithetical the point, which is to think about it for myself.
I _certainly_ didn't think about it from the perspective of "spending actual brain cycles." As far as I know, "brain cycles" is a pretty reductive way of looking at the brain, and is fundamentally wrong in the same way that Trump was when he said that "exercise uses up the body's finite energy:" it's overly protective in a way that results in the exact opposite of what you think you're achieving. To put it more simply: "use it or lose it." I'm not worried about "spending brain cycles" (to the extent that "brain cycles" is an accurate model at all), because thinkin' 'bout stuff is precisely how I get _more_ "brain cycles," not _less_.
Which is all to say: do you seriously engage with all your potential thought avenues from this perspective? Weighing which ones are "low priority," etc? For work/programming/etc, I can understand that to a degree, but for something that can only be classified as "recreational thinking," I just do not get this _at all_.
You said in another comment in this thread that while ChatGPT does something, it frees you up to do something else. What did it free you up for?
GrapheneOS + Xiaomi hardware = Pixel killer
graphine needs a built in calendar app that uses caldav
Is DAVx⁵ not sufficient?
DAVx5 works well, but it is indeed rather surprising that Graphene does not come with a calendar or an email client. I guess the idea is that you can download F-Droid and choose your own, but even F-Droid is not provided by default.
On bundling apps in general: https://grapheneos.org/faq#bundled-apps. For the calendar app particularly I think they assessed that the AOSP Calendar app was beyond saving (left to rot by AOSP/Google). I cannot remember if they still have plans to develop a calendar app.
I believe you're right that the idea is for people to download the apps they want (from wherever they choose). GrapheneOS has a complicated history with F-Droid though. Unfortunately, unless their approach was different in a lot of significant ways, it is unlikely GrapheneOS will include F-Droid in their Apps app repository.
Any guesses who the OEM is? I'm thinking Nothing.
They said "major OEM" so I don't think it's them. Unlikely to be Samsung either. Maybe Xiaomi or Lenovo (Motorola)?
No shot on it being Xiaomi (or any other BBK brand like OnePlus), they haven't been super great to the custom rom community in some years now.
I would have guessed HMD, but they just pulled out of the US market: https://www.androidauthority.com/hmd-global-leaves-us-market...
However, Motorola/Lenovo seems the most logical partner, they were previously in the Android One program (which was sort of the successor to the Nexus line).
They said it'd be priced similarly to Pixels, so ~$1000 range. Afaik the only Motorola phone in that range is the Razr, but that'd be a weird choice.
I sure hope they're not excluding the a series when they say that.
Given that OnePlus is the only other vendor that currently has semi-decent custom rom support my guess is them, followed by HMD.
My guess is Sony.
Sony pulled out of NA a few years ago so that would be non-ideal for many folks…
That would be interesting. I have long wished that Sony phones would allow re-locking the bootloader to an OS signed with my own keys.
Some of their Xperia Compact models have been excellent, but they haven't been making them like that in recent years. Dare I hope for a return of their truly compact flagship phones and GrapheneOS support?
As far as I'm aware, their flagship Xperia phones do support bootloader re-locking [1]. The problem is they haven't fulfilled GrapheneOS's other requirements: https://grapheneos.org/faq#future-devices
[1] https://github.com/chenxiaolong/avbroot/issues/299#issue-232...
> As far as I'm aware, their flagship Xperia phones do support bootloader re-locking [1].
The last one I tried (xperia z1 compact) bricked itself when I tried to re-lock the bootloader. Maybe it's safe on newer models?
If they ever make another good compact model, I suppose I should look for re-locking reports on it. Thanks for the link.
Sailfish also supported some Sony devices, https://docs.sailfishos.org/Support/Supported_Devices/
I use Sailfish on an Xperia 10 mod. III. Unfortunately the only Xperia models which support the full Sailfish w/Android compatibility are the way too long ones. I intensely dislike long phones. I miss my old Jolla phone (they're the maker of Sailfish), it was perfect but developed a technical problem after many years. The Xperia is clumsy when compared to the Jolla phone. Glass surfaces back and front (who thought that was a good idea? Glass is slippery, and glass breaks), sometimes slips from my hand, or wherever I put it if it's not 100% flat. Glass..well, you get the idea what happens then..
If they got rid of their fear of the US market, they might actually have gotten somewhere.
The US smartphone market basically consists of two brands: Apple and Samsung. Everyone else is fighting for scraps.
Yes, but making it hard to impossible to fully license the Jolla software in a non community level and support their project is a bit frustrating.
Cool but isn't the appeal of Pixels it's baseband security model/USB
https://security.googleblog.com/2024/10/pixel-proactive-secu...
I don't have all the links to post here but I recall this being a big factor.
Snapdragon flagships have solid security and it's the devices made with those which ruin it. Snapdragon has both advantages and disadvantages compared to Tensor.
Pixel 6 through Pixel 9a are essentially Exynos SoC devices using standard Cortex and Mali cores. Certain components are custom including a Trusty OS TEE and secure core, a separate hardened secure element chip, image processing, TPU for neural network acceleration, etc. Tensor was mostly standard Exynos. Pixel 10 moved away from Exynos other than the cellular radio chip, but it's not clear if that is good or bad for security. It gives them more independence, choices and control to an extent but they largely licensed the IP for the components and it's not necessarily more secure. Perhaps PowerVR GPUs have better security than Mali, but that's unclear. It does appear they got GPU virtualization support through it, but Qualcomm cares a lot about virtualization too especially since they support laptops with Windows, etc.
GrapheneOS have mentioned in the past that the Qualcomm baseband processors compare well to competition in terms of security and isolation support on their respective SoCs. There may be other aspects they need to catch up to Pixels on regarding security though (like the secure element, open-source TEE etc.).
I hope so.
When is the last time a mobile OS worked with an OEM and found long-term success?
I hope it's not one of the biggest names. I hope they've decided to work with a more ethical brand to elevate their quality. How about a Graphene OS phone with a removable battery?
It's one of the major OEMs. They have a bunch of devices, so we can eventually support more than one and can have new supported models each year. Small OEMs are not currently capable of meeting our security feature and update requirements listed at https://grapheneos.org/faq#future-devices.
Fairphone 4 and Pixel 6 both launched October 2021. Fairphone 4 has an end-of-life Linux 4.19 kernel which stopped getting LTS updates vs. launching with Linux 5.10 and moving to Linux 6.1. Fairphone 4 is still on Android 13 which is end-of-life soon. Fairphone 4 lacks proper privacy/security patches since it's just getting partial backports to Android 13 which they ship 1-2 months after the official date. OEMs are allowed to ship them up to 3 months before the official date and have at least 1 month early access, so that's a longer delay than it seems. Is the way these devices marketed ethical when considering the lack of privacy, security, long term support and sustainability? Do the claims about fair treatment of workers and fair sourcing of resources have more substance? Is it better or worse than the ethics of an iPhone, which has very efficient per-unit production and far better long term support?
The iPhone also is completely closed source, has parts pairing and, most importantly if you wish to not create e-waste -- no removable battery. Even if you offer 8-10 years of security updates/android updates, I am not going to use a phone that shuts down the moment it meets a cold gust of wind...
This is the 'ethics' I was referring to.
But also remind me, since you mentioned the iPhone (even though it's completely unrelated) and fair treatment of workers... Wasn't there a series of suicides of workers producing Apple products? To a point where factories had to install netting to catch people falling? https://assets.bwbx.io/images/users/iqjWHBFdfxIU/idXSwvPwl2G...
At any rate, they explicitly said that they are not working with fairphone [1]
[1] https://news.ycombinator.com/item?id=44678459
Yeah, was kinda hoping they's work with Fairphone to fix their shit security situation... Anyway, hopefully another ethical brand fingers crossed! Thanks for the link!
2027 in EU: https://www.pcmag.com/news/eu-smartphones-must-have-user-rep...
[dead]
Commercial partnership between open source projects and real companies can be tricky if not deadly.
I still remember CyanogenMod powering the first OnePlus One as Cyngn Co.
Lineage OS raised from the ashes of CyanogenMod.
On top of this, any ad blocking and "privacy first" project just shutters in pieces when the hardware manufacturer gives you a bunch of binary-only closed-source modules to be stuck into the kernel.
Stop using apps and run Firefox or any other open source browser. That type of privacy can be (almost) achieved that way.
But if your os runs non-auditable binaries directly into the kernel, then it's clear we are talking about dreams, not reality.
GrapheneOS isn't a product or a business. It's partnership between a non-profit organization (GrapheneOS Foundation) obligated to pursue the defined mission and a for-profit Android OEM making hardware. It's not a for-profit venture from the GrapheneOS side.
There are no closed source components in kernel space for Pixels and won't be for other devices we support either. Hardware and firmware is closed source in practice for all modern computers. Open source doesn't mean something is inherently more private or secure. In the case of hardware, you also can't verify it matches the sources in a similar way as software.
Firefox has poor security, but especially on Android where it doesn't implement sandboxing yet let alone site isolation. It has much worse exploit protections and other security protections than Chromium-based browsers.
Using web apps over native apps makes sense for reducing their access but has privacy downsides too such as trusting the servers rather than having signed releases able to provide more meaningful end-to-end encryption. Not everything can be done with web apps, especially in Firefox where there's no WebUSB, etc. as alternatives to installing native apps providing much less access to other things beyond what's required. For example, Firefox can't be used to install GrapheneOS on a device via the easy to use web installer due to lack of WebUSB despite Mozilla coming up with the early version of it as part of FirefoxOS.