Salta al contenuto principale


it might actually be over
9to5google.com/2025/08/25/andr…

reshared this

in reply to kade²

Surely they add an option to bypass and install unsigned ones easily right
in reply to kade²

this says only devices with play protect are affected, graphene os, lineage and calyx do not have play protect
in reply to Avi

So you're out of luck if you have a Samsung or similarly locked/unmoddable ones though :/
in reply to kade²

also good luck actually running alt androids at this point as the play protect noose tightens. do you want to use an app belonging to a bank? do you want to use a services app published by a government? do you want to purchase a single ebook? even if your device supports these OSes, you're forced into living essentially off the grid

Oblomov reshared this.

in reply to mcc

Status quo is that the vast majority of Android apps work on GrapheneOS. Banking apps are a special case where ~10% or so disallow it.

We've been convincing major banks to permit GrapheneOS alongside what the Play Integrity API permits. Several banks began permitting GrapheneOS in the past month including Swissquote. We're actively working towards a universal solution to this in the EU through the EU requiring banking apps to permit competing operating systems.

Oblomov reshared this.

in reply to GrapheneOS

The gradually growing adoption of the Play Integrity API by banking apps is a problem but nearly entirely limited to banking and financial apps. Regulation is the only universal solution, but the status quo isn't that bad and we're making decent progress convincing apps to allow GrapheneOS without regulations.

There are some government apps doing it but we're making a lot of progress. It goes against other policies by the same governments. They move slowly though.

reshared this

in reply to GrapheneOS

Convincing these apps to allow anything is much harder than our focus which is convincing them to permit GrapheneOS in addition to a Google Mobile Services stock OS. We're not trying to convince them to roll back the checks entirely in most cases. We're only trying to convince them to use Android's standard hardware attestation API and permit GrapheneOS with it. Once they're convinced of that, it's easy for them to permit non-GMS hardware and other operating systems.

Oblomov reshared this.

in reply to GrapheneOS

The main barrier we face is getting in contact with the developers or people who can make decisions. Getting past their walls of customer support and handling of external communication is often difficult. In many cases, our users have accomplished it without our involvement through reviews, customer support requests, etc. A growing number of these apps explicitly support GrapheneOS and even test it. It shouldn't be necessary but they insist on doing these checks.

Oblomov reshared this.

in reply to GrapheneOS

If the reason apps work on grapheneOS is because apps detect grapheneOS as an alternative to Play Protect, then for the above-stated reasons I don't think this helps with either user freedom or my own personal use case.
in reply to mcc

Yeah exactly. GrapheneOS playing along as another alternative to be supported makes it at least as hard if not harder to use anything else, including your owm build from source of GrapheneOS. Attestation working as designed. 🤬
in reply to Cassandrich

We're strongly advocating for the EU defining their own set of security standards and allowing any hardware or OS to apply for inclusion with a low barrier to entry. Ideally, Google Mobile Services devices would not inherently be included since most have atrocious security. With high enough standards, app developers won't want to use it because they'll lose a huge portion of their userbase. This is what we see as the solution leading to it barely being used.

Oblomov reshared this.

in reply to GrapheneOS

Okay but what if the "security" standards are what we are objecting to. what if i am fundamentally opposed to a piece of software i run being able to determine whether i have altered it and/or its environment. what if i am typing this on a desk scattered with half-finished fpga projects and want, on the 20-year scale but i want, to build my own devices from scratch.
in reply to mcc

As always I see GrapheneOS as a deeply impressive project that is hitting its goals very well but its goals aren't mine
in reply to mcc

We would never ban people from using software on those devices but what banks decide to do is not up to us. It's not realistic to convince them to permit running their apps on anything and they have dramatically more influence over governments/regulators than we do. It's simply not realistic for us to convince governments/regulators to forbid banks from doing it. Governments are even using the Play Integrity API themselves or enforcing that banks, etc. use it for dubious reasons.
in reply to GrapheneOS

It's realistic for us to accomplish is convincing governments/regulators they should be in control of the standards rather than Google and there should be a level playing field where anything can get approved including alternate operating systems. A lot of banking apps are doing this because industry standards or even government regulations require them to check device integrity. There are often no details on how to do it, but it's easiest to just outsource it to Google.
in reply to mcc

Then there is software you can not run unmodified as the developers (or organization they work for) do not want their software to run on devices they can not attest to that they are not tampered with.

What i view Google is doing is making it easier for people to make that decision as developers. This is cutting you out of many more apps then you would want and Google is very much doing that for monoplism alligned reasons.

in reply to drawnto 🟨⬜🟪⬛

Many of the apps adopting the Google Play Integrity API have not made an explicit decision to disallow modifying their app or the OS. They haven't made an explicit decision to disallow anything other than a Google Mobile Services device with the stock OS. Many have simply implemented it because it's there and encouraged by Google as a best practice. This happens very often with the toggle for enforcing it for installing apps from the Play Store.
in reply to GrapheneOS

Thanks for the correction/addition. Do not want or do not care or do not care to educate themselves or ...
All again alligned with monopolistic interest of google.

Running a custom build of Graphene OS should prevent developers from verifying themselves according to @dalias

in reply to GrapheneOS

Integrating it into a service requires significantly more work so that happens less. Flipping on the Play Store toggle to require it for installing the app is incredibly common, and then users need to install the apps another way such as Aurora Store which is very likely to end up being blocked since Aurora Store very clearly breaks the Google account terms of service by sharing accounts.
in reply to GrapheneOS

It shouldn't be allowed for Google to be in charge of which devices an app can run on. They've defined it solely based around their business model for licensing Google Mobile Services. It should be easy enough to convince regulators and governments this is a huge problem they should solve. Convincing them to stop encouraging or even enforcing using attestation is a whole other thing but convincing them it shouldn't be GMS-only is at least a first step.
in reply to GrapheneOS

I think that all makes a lot of sense. But I'm not happy living in the world where *the EU* is in charge of which devices an app can run on either; I wouldn't trust *any* government with the ability to decide where/how you're allowed to run/write software. Even if it's notionally better than Google (or even the USG) deciding, I don't want to live in a world where there is a Government Of Computers. *That's why I stopped using Apple devices in the first place.*
Questa voce è stata modificata (2 settimane fa)
in reply to mcc

The EU is already creating a lot of the problems for us. They have a digital wallet standard and an age verification standard which both initially explicitly required using the Play Integrity API. They were altered to not specify how device integrity is checked but in practice it will be the Play Integrity API. This is just how things are. We choose to use our resources and influence to get them to permit GrapheneOS and other alternate hardware / software instead of doing nothing about it.
in reply to GrapheneOS

GrapheneOS is supposed to have perfect Android app compatibility including via our substantial efforts on our sandboxed Google Play compatibility layer. Play Integrity API is a disaster for us even with only a tiny portion of apps using it. Many people who were drivers for Uber and Lyft had to suddenly stop using GrapheneOS when they banned it. Uber seems to then have permitted it again but it's a huge problem regardless. We're not at all happy with the situation, but it's the situation.
in reply to GrapheneOS

Basically "it can be used to implement an online age verification mechanism" is, in my book, a reason *by itself* to oppose a technology existing. This is not a capability it should be possible for a government to attain.
in reply to mcc

It doesn't really help with age verification, they just think it does, so we're trying to convince them to permit more than GMS devices as part of it whether that means no attestation or using a less monopolistic system for it.

Android's hardware attestation API permits arbitrary attestation roots and permitting arbitrary non-stock OSes if you choose to so it can be used beyond permitting GMS devices but it's biased towards only permitting stock OS GMS devices which we of course dislike.

in reply to GrapheneOS

If I have to apply for inclusion of "my personal build", that does not work. It doesn't scale or have the security properties they want it to have.

If I have to use one of N choices that were big enough to include, that does not meet my requirements and is not free software.

in reply to Cassandrich

Most banking apps are unlikely to become free software any time soon and they're increasingly moving towards restricting what can be used. Currently, around 10% of banking apps forbid using anything other than a Google Mobile Services device with the stock OS, but it's gradually expanding. We've only convinced a SINGLE banking app to outright stop doing it. We've convinced a dozen to permit GrapheneOS via the hardware attestation API as an alternative to it.
in reply to GrapheneOS

Convincing banking apps to stop checking device integrity is just not realistic. Most consider themselves obligated to do it by various standards and government regulations. Outsourcing the checks to Google is easiest and minimizes their liability since it's regarded as the industry standard. Some banking apps are willing to permit GrapheneOS but others aren't since they don't have to and it's easiest to just let Google decide everything for them instead.
in reply to GrapheneOS

We did convince a single banking app to stop using attestation so at least be happy about that because it wasn't easy for us to achieve it. Our userbase is significant but very reluctant to use social media in general so they have less influence than they should. Convincing people to take time out of their day to pester these companies with reviews, customer support requests, etc. is not easy. User pressure is how we got these apps to permit GrapheneOS.
in reply to GrapheneOS

At least one of them began permitting alternate operating systems in general. Most are only specifically permitting GrapheneOS and we may have to revisit it in the future since the way it has been permitted requires them to add the key fingerprints for each device since we don't reuse keys across them for security reasons. The whole thing is quite frustrating. The centralized solution being forced to permit GrapheneOS would make our lives a lot easier...
in reply to GrapheneOS

That's why a solution is going to have to involve breaking the attestation system (like popping someone's signing keys or exploiting hardware bugs).
in reply to Cassandrich

Reliably tricking the software attestation doesn't work out well. It's far easier for them to adjust it to keep banning widespread bypasses than it is to keep it working reliably. Apps sometimes working and sometimes not working does not result in a viable alternative for people who depend on those apps. The apps need to work reliably or people need to stop using the apps. The vast majority of apps using it aren't enforcing hardware attestation with it.
in reply to GrapheneOS

Originally, the hardware attestation which the Play Integrity API uses when available for the device integrity level or requires for the strong integrity level relied on either batch or unique keys provisioned to the TEE across devices. It has moved away from that to remotely provisioned per-app keys based on an initial unique key. The provisioned keys get rotated regularly. They have a system for revoking keys and use the software attestation to detect misuse.
in reply to GrapheneOS

The software portion of the Play Integrity API includes a whole bunch of stuff that's not actually enforced such as GPU fingerprinting to detect mismatches between what the device claims to be and what it actually is. This is used to detect spoofing in the wild and leaked keys, which they can then crack down on and revoke without revealing how they detected it. The software attestation is a huge problem by itself and the main issue we have is with that.
in reply to GrapheneOS

I mean like if you had a signing key that could produce unlimited new trusted hardware keys, so you could just emulate the hardware in software and lie that you're verified stock Google.
in reply to Cassandrich

Software attestation is what's actually enforced by 99.9% of apps using the Play Integrity API and is a huge problem by itself. It can be tricked through spoofing what it checks but they do not directly enforce MOST of what it actually checks. This means they can easily detect spoofing and then choose when and how to block it. It prevents having reliable support for apps working on it. Some OSes do spoofing and then users are screwed over when it breaks.
in reply to GrapheneOS

It's also actually harder to do short term spoofing with sandboxed Google Play due to how it can't perform a whole lot of the checks it wants to do and we'd have to spoof a lot more than with privileged Google Play. It sounds like it would be easier with a regular sandboxed app but that's only in theory, since in practice most of what it checks would already match correctly and we'd have far less we'd need to change than sandboxed Google Play does.
in reply to GrapheneOS

In the long term, it being a sandboxed app is better for spoofing. In the short term, it's far harder to get the basics working for it to start passing the device integrity level while pretending to be another device. They're gradually phasing out support for software-only attestation so you currently need to pretend to be an older device without support for you to pass. This can interfere with other stuff, and they're going to gradually phase it out fully.
in reply to GrapheneOS

People do get their hands on leaked keys to fake the root of trust hardware attestations. However, they have increasing visibility into where those keys were assigned and increasing ability to revoke them with no consequences to themselves. They can also revoke a broader set of keys. Their system of distributing keys via remote provisioning with regular rotation greatly improves the ability to revoke at a broader scale with lower impact.
in reply to GrapheneOS

The keys expire in around 2 weeks. You need to keep getting new ones provisioned. They don't just have the revocation option for the abused keys but also provisioning keys. They can cut off provisioning based on keys, outdated device models, etc.

The system of root-based attestation is inherently not very secure and there are major holes usable to bypass it. It doesn't mean it can be used at the scale of GrapheneOS successfully without them quickly blocking it.

in reply to GrapheneOS

We'd need to do something like coming up with a way to bypass it, filing a lawsuit and then deploying the bypass alongside getting a court order to stop cracking down on us further so they wouldn't be allowed to block it. It's really hard to see a way of reliably bypassing it beyond the short term. They largely ignore one-off cases of bypassing it and just monitor them then crack down once it's deployed at a larger scale. They don't care about small scale much.
in reply to GrapheneOS

Basically this whole thing is just mind bogglingly draconian, beyond the worst predictions for DRM decades ago, and the whole thing should just be burnt to the ground.

I don't want to start an argument with you but I don't see how anyone csn ethically participate in this.

in reply to Cassandrich

We don't participate in it. We just try to convince app developers to permit GrapheneOS. Us doing that has in some cases convinced apps to permit any alternate OS. For banking apps specifically, only 1 banking app has dropped doing it entirely based on pressure from us and our community. For non-banking apps, we've convinced dozens of apps to stop but most were just marking their Play Store listing as requiring it without it integrated in their services.
in reply to GrapheneOS

For banking apps we generally don't consider it realistic to convince them not to use it since we're aware that they're being told they need to check device integrity and that the industry is settling on the Play Integrity API as the standard approach. Instead, we try to pressure them to permit GrapheneOS via hardware attestation. We aren't happy with this being solved case-by-case with our per-device keys allowlisted but it's the best we can usually get.
in reply to GrapheneOS

We make gradual process of getting non-banking apps to roll it back and banking apps to at least permit GrapheneOS. Our progress is slower than the adoption rate of the Play Integrity API. It's a very bad thing for us that's slowly eroding app compatibility. We're just doing what we can to slow that down or reverse it to the extent possible. If many others were doing the same, then perhaps there could be larger success against it, but there isn't much pushback.
in reply to GrapheneOS

The fact that it's relatively straightforward to spoof the software checks which are what the vast majority of apps use have made most of the Android power user modding community uninterested. They use Magisk with modules for spoofing and it works for them for long periods since it's only being done at a small scale. It eventually breaks, and then gets worked around, but Google deliberately doesn't crack down on small scale usage much to avoid pushback.
in reply to GrapheneOS

Adoption of enforcing hardware attestation by banking apps is ongoing. It seems that's what the EU is going to force apps to use, and that kills the spoofing approach without leaked keys which can be revoked or have provisioning cut off.

We don't think there's a technical solution. It needs a regulatory / political solution and it's hard to understand why governments/regulators are not moving faster to address this. It's beyond just Android-based OSes.

in reply to GrapheneOS

If we make an entirely new OS based on a fancy microkernel with a new userspace, etc. we're still going to need to provide Android app compatibility via virtualization. Play Integrity API has just as much impact on that as it does for an Android-based OS, and it's also far harder to spoof the weaker checks or avoid detection of spoofing. In practice, people will expect either iOS or Android apps in order to use a phone. Therefore, this really matters a lot.
in reply to GrapheneOS

Right now anti-US sentiment makes it a strategic time to seek to ban Play Integrity.
in reply to Cassandrich

Yet despite that, the EU is actively introducing standards which mandate doing root-based hardware attestation where they're delegating that to Apple and Google with no alternatives. This is why we filed issues about it with the EU digital wallet and EU age verification projects. We don't agree with age verification as a thing either but if it's going to exist, it should not have anything to do with enforcing which OS or device you can use. Doesn't make sense.
in reply to GrapheneOS

We're requesting that if they're going to do it then they clearly must allow non-GMS hardware and operating systems. It clearly should not be delegated to Google. From our perspective, the Play Integrity API is very clearly illegal in the EU. Root-based attestation COULD be legal if they had a fair system where anyone could apply but they don't have one and should immediately stop deploying it, mandating it and in fact disallow it unless it worked that way.
in reply to GrapheneOS

Yes but that's just because big systems have lots of moving parts that don't talk to or understand one another.

It doesn't mean the problem is intractable.

I hope you don't mind me saying this, but I think you have a tendency to react to seemingly powerful threats in ways that's not just defeatist but counterproductive.

in reply to Cassandrich

We need to keep apps working in the short term in order to convince OEMs to work with us and make hardware we can use, etc. We need to keep things working for our existing users. Every time a major app stops working, we lose users and support even if they love GrapheneOS. There are many people who love GrapheneOS but don't want to carry 2 phones and therefore stopped using it because some specific app banned using any alternative OS. We care about each app.
in reply to GrapheneOS

It can be some awful privacy invasive app from a company doing highly unethical things but we still need that app to work on GrapheneOS because some users consider it essential. Without that app working, they will lose ALL privacy, security and other benefits of GrapheneOS. This is why we're working hard to try to convince each and every app doing it to at least permit GrapheneOS. We're fighting for subsets of our userbase who use and often really need the apps.
in reply to GrapheneOS

Our hope is if we can get enough people with power in the EU to understand what is happening, they'll realize it's a very bad thing and regulate it out of existence. Attestation based on pinning is a great thing. Attestation based on roots of trusts is very easily used for evil and anti-competitive purposes. It won't bother us if that was regulated out of existence but we don't expect it to happen. They're regulating more of it into existence.
in reply to GrapheneOS

EU had a near universal non-Google-Pay tap-to-pay system used by most banks. More and more banks moved to Google Pay which disallows GrapheneOS. That trend has continued. Near 100% of EU banking apps used to work on GrapheneOS, now it's more like 80-90%. It may actually be the worst region in the world for it due to the Play Integrity API adoption growing faster. They talk a big game about being independent from the US but then do the opposite.
in reply to GrapheneOS

The EU needs to bring out a big hammer and ban Play Integrity API as monopolist.
in reply to Cassandrich

The EU is part of the problem. Recently, they planned to integrate Play Integrity into the age verification app but retracted after community protests, saying they will offer standard hardware attestation in addition to Play Integrity.
in reply to Buccia

It's not at all clear what they will permit via hardware attestation though and what system will exist for hardware and operating systems to be permitted by it. We did at least convince them to use a system which can permit more than Google's root of trust and more than stock operating systems, but it's still bad. They insist on checking device and OS integrity for both this and the digital wallet standard. Many people tried to convince them not to and they failed.
in reply to Buccia

They said it will up to member states to decide what app integrity is best for them, if any, but people fear governments won’t care and will just use Play Integrity. In fact, the Italian digital ID app is already enforcing it.
in reply to Buccia

Yes, but we did at least convince them to not specifically mandate the Play Integrity API. It now refers to stuff from OWASP about verifying device and OS integrity. OWASP unfortunately heavily promotes the Play Integrity API, obfuscation, anti-tampering techniques, etc. and has been a major part of the problem in regards to apps disallowing using other devices and operating systems. It's very frustrating that this stuff is presented as if it's a security feature.
in reply to GrapheneOS

Instead of explicitly mandating the Play Integrity API, the EU is now heavily encouraging using it instead. They're requiring doing device / OS integrity checks where the Play Integrity API will be the main way that's done in practice. It's at least an improvement over what it would have been without our intervention where they were explicitly disallowing GrapheneOS and other alternatives in 2 EU standards instead of just unspecific references to device/OS integrity checks.
in reply to GrapheneOS

The banking apps issue could simply be resolved by mandating full-fledged HBCI/FinTS endpoints and open (and more secure) alternatives to proprietary TAN apps. We know it works because there are banks which voluntarily provide full support for all of their products (including stocks) and support ChipTAN even on mobile devices.

Sadly bodies like the EU can no longer be expected to understand and regulate this. On the contrary.

securityonline.info/eus-open-s…

in reply to mcc

This. Required hardware attestation locks out anyone who wants actual control over their hardware.
in reply to Fiona

That's an explicit part of what most of those apps want to do. They want to forbid people running software which allows them to use their app in ways they don't want it being used. Therefore, if you want to use the app, you can either use short term spoofing approaches which become increasingly hard to keep working reliably or you need to convince the apps or the APIs they use to to permit the software. We're trying our best to preserve app compatibility.
in reply to GrapheneOS

We care deeply about app compatibility which is the main factor in usability. It's a huge part of us getting the support and resources we need. A single app not being compatible can be what determines if any particular people want to use GrapheneOS. App compatibility has been a significant part of why we've been able to fund our work and succeed to the extent we have. Play Integrity API has been gradually eroding it around the margins. It's a big deal for us.
in reply to GrapheneOS

Our own usage of attestation via our Auditor app is based around generating per-pairing attestation signing keys which are pinned. That system cannot be used to stop people using the hardware and software they want by itself. It's the root of trust based hardware attestation which enables blocking using software and hardware not approved by the chosen root(s) of trust. The root-based attestation is more than a huge threat to us but rather actively harming us.
in reply to GrapheneOS

Play Integrity API having incredibly low security standards where the device integrity level permits anything licensing Google Mobile Services makes it far worse. This has encouraged far more apps to adopt it than would have adopted a feature not permitting unpatched devices, etc. What they enforce is simply that it's a Google Mobile Services device with the unmodified stock OS. It has close to near security value, it just harms alternative hardware/OSes.
in reply to GrapheneOS

If the Play Integrity API required that the device was no more than 3 months behind on Android security patch level with Google enforcing their partners to not cheat with fake patch levels, then apps would hardly use it. Most devices wouldn't work with it so only a tiny subset of apps would be willing to use it. It would also at least accomplish something useful by applying pressure to start shipping at least the subset of backported security patches.
in reply to GrapheneOS

Even the strong integrity of the Play Integrity API has no hard limit on a device not getting patches. They ended up recently adding a check for devices not being over more than 1 year behind on patch level for the strong integrity level. However, they only enforce it for recent OS versions so it still permits a device with no patches for 6 years. Few apps use the strong integrity level since they aren't willing to lose compatibility with many devices for it.
in reply to GrapheneOS

If there were actually some meaningful security standards which were enforced by it then it would heavily discourage apps from adopting it. They would only adopt it if they were forced to do it by a government, which is then something which can be pushed back against. Google's current approach of enforcing no real security standards but rather just GMS device + stock OS makes apps developers willing to adopt it while it solely enforces Google's monopolies.
in reply to GrapheneOS

I find that corporate DRM systems are fragile like hummingbirds. I have purchased a number of Adobe Digital Editions protected books, and I find that these are not even compatible with *the Android version of Adobe Digital Editions*. If the *single* app that can run my purchased ebooks turns out not to work, it is already too late to switch back from LineageOS or whatever I picked.
in reply to mcc

Although I'm glad you're working with alt OSes, any solution which is specific to GrapheneOS is useless to me because I will never buy a Google phone and (for what I understand to be sound reasons) GrapheneOS is unlikely to run anywhere else in the forseeable future. I am not interested in the security guarantees of a Pixel phone. I am trying to get the right to live as a human without having made those security guarantees. Freedom from Google is the point.
Questa voce è stata modificata (2 settimane fa)
in reply to mcc

We're actively working with a major Android OEM you have fairly likely owned some devices from before towards a small subset of their future devices meeting our requirements and providing official GrapheneOS support. The initial ones will have to be flagship devices because Qualcomm limits the best update support and security features to those. In the future, lower end devices could eventually be supported. We're just not going to massively lower our security standards.
in reply to GrapheneOS

You can see a list of our hardware requirements at grapheneos.org/faq#future-devi…. 8th/9th gen Pixel phones have all of it and 6th/7th gen Pixel phones have everything other than the ARMv9 features.

None of the individual features is Pixel exclusive. Samsung has some devices providing all of our security feature requirements but without permitting us to use all of them. Unfortunately, they're now fully dropping alt OS support instead of improving it as are several other OEMs.

in reply to mcc

We haven't heard about issues with DRM on GrapheneOS but we do expect there might be issues with Widevine for video streaming sites at some point in the future. It hasn't been an issue for us yet but it may become one when they switch from using TrustZone to virtualization if that actually ends up happening. We aren't sure that's actually going to happen since many things planned for Android have been cut due to layoffs and other cost cutting. AOSP stuff was part of it.
in reply to GrapheneOS

I don't blame you for your strategy but we need someone to actually convince these banks that device attestation doesn't do shit when their software is slop.

It's pretty insulting to have orgs telling me how to use my device when they release software that, at best, is sloppily written and at worst, appears to be written by a preschooler.

in reply to Eric Schultz

We've tried and it doesn't get anywhere in the vast majority of cases. They believe they should check device and OS integrity. Play Integrity API is the official API promoted to them for that by Android Studio, the Play Store and the official Android documentation. Even the EU has promoted using it and come close to making it into a requirement for certain kinds of apps with the possibility of other approaches being left open only because we complained.
in reply to mcc

given the capture of #USA government by a Nazi, I am not currently interested in having a #USA app on what's left of my phone, and no I do not buy ebooks.Bank? Absolutely not on my phone.
Thanks for the accounting.
#USA
in reply to Avi

CalyxOS was essentially discontinued and hasn't received updates since June. It didn't receive the 2025-06-05 patch level or later. See their announcement about the departure of the founder of Calyx and also the departure of the founder / lead developer of CalyxOS: calyxos.org/news/2025/08/01/a-…. Their post explains they plan to launch a new OS with new signing keys 4-6 months after August 1 which will require users to reinstall. They don't appear to have the existing signing keys.
in reply to GrapheneOS

Play Protect can be used on GrapheneOS via sandboxed Google Play but it can't do anything more than scan APKs installed in the same profile since it runs as part of a regular sandboxed app. It can't be used to block installing apps, although if we really wanted we could add an opt-in to supporting it similarly to how we have an opt-in to giving Android Auto USB access for wired Android Auto and other toggles for other Android Auto functionality. Not something planned though.
in reply to kade²

Nope, not with the way they're putting it in that article, no

We're witnessing the iOSification of Android

(and it's pretty much a coin flip as to whether the grapheneos devs are going to defend or decry that)

in reply to zaire c.

GrapheneOS doesn't include Google Mobile Services and the requirements for certification aren't relevant to us. We don't follow the Android Compatibility Definition Document rules and only care about passing the subset of the Android Compatibility Test Suite and other Android test suites which make sense for us. We implement lots of disallowed features and work on making sure those don't break apps or if they do break some apps that it's easy to work around it for users.
in reply to GrapheneOS

We're worried about plenty of things but not this. Play Integrity API is a major ongoing concern for us, as are some other things. Android and Google Play being split from Google into a new company might be a positive thing but could also turn out very badly where AOSP gets discontinued. In fact, recent changes negatively impacting AOSP seem at least partly caused by Google losing some lawsuits. Courts and governments do not know or care about open source, the results can be bad.

Quincy reshared this.

in reply to GrapheneOS

Do you have any sort of plan in the event that were to happen, and AOSP just disappears? I imagine you wouldn't want to just say "welp, guess it's all over" and shut down the GrapheneOS projec, but you wouldn't have a lot of options in that situation. Pivot into making GrapheneOS a mobile Linux distro? I'm sure that option isn't very appealing, but if it's that or nothing...
in reply to Voidburger

GrapheneOS is a mobile Linux distribution. Linux doesn't mean systemd, glibc and GNOME which are not things we're interested in using. What will people using those do in the event those projects are discontinued?
in reply to GrapheneOS

So..... y'all support the Nothing phone, right? I've been very pleased with this device and the customizations they've done to Android, but I suspect they'll abide by Google's lead in locking out manually installed apps.

I may need to switch to Graphene if that actually goes through.

in reply to Charlie

No, since their current devices don't meet our requirements. Their future devices may meet our requirements and we could potentially support those but they need much quicker updates for much longer and better hardware-based security features. See grapheneos.org/faq#future-devi… for our requirements.
in reply to kade²

here's the actual blog post since nobody is linking to it android-developers.googleblog.…

i can understand this where certain often-abused permissions are used, but not for *everything*.

what's the bet that this is against DMA lol