The Play Store stopped responding to Aurora Store, and the report is open in the project's repository: Play Store blocks AuroraStore, hurting GrapheneOS users. Aurora is the unofficial client that a lot of people running Android without Google services —GrapheneOS users among them— use to download apps from the official catalog. That same day, the AnkiDroid team reported that Google no longer lets them keep their Open Collective donation link on their listing: AnkiDroid: Google Play no longer allowing Open Collective donation link. Both cases are report threads, not announcements: the material doesn't explain the mechanism behind the block or whether it's permanent.

Why it matters

The conversation about mobile security almost always drifts to the device: the hardened kernel, the sandbox, verified boot, permissions. All of that matters, but it's the part that's already reasonably solved. The link nobody models is the channel the software arrives through, and that link isn't yours.

A phone running GrapheneOS is, technically, harder to compromise than a stock Android. But its access to the app catalog goes through a middleman that depends on the other end tolerating it. When that tolerance ends, the device doesn't become insecure because of a code flaw: it becomes insecure because the user has to get their apps somewhere else. And somewhere else, in practice, means APK mirrors with no chain of custody, no signature verification, and no automatic updates.

That's the point: a distribution block doesn't stop installation, it degrades it. The AnkiDroid case completes the picture from the other end. A donation link has nothing to do with anyone's threat model, and store policy reaches it anyway. The criteria governing what software reaches your phone belong to the platform, not to you.

What changes in practice

If you maintain an Android app, the Aurora block probably doesn't affect you directly. What it shows is that the chain your users receive you through has a stretch you don't control and that can be cut without warning.

┌───────────┐    ┌──────────────┐    ┌───────────┐
│ GrapheneOS│───►│ Aurora Store │─X─►│ Play Store│
│  (no GMS) │    │ (unofficial) │    │ (catalog) │
└───────────┘    └──────┬───────┘    └───────────┘
                        │ blocked
                        ▼
                 ┌──────────────┐
                 │ APK mirrors  │
                 │ no guarantee │
                 └──────────────┘

What I would change in the workflow:

  • Publish the signed APK on your own domain, with the hash published next to it and the certificate fingerprints documented. So anyone can run apksigner verify --print-certs and compare against what you say, not against what the store says.
  • Keep version parity across channels. An alternative channel running three releases behind is a channel distributing already-patched vulnerabilities.
  • Don't tie essential functionality to proprietary services that don't exist on a de-Googled device. If your app won't start without Play Services, the user is already out of your reach before any block.
  • Treat distribution as an architectural dependency, with its own contingency plan, and not as end-of-sprint paperwork.

When NOT to use it

It would be dishonest to close here with the easy moral that we should all get out of the store. That's not what I recommend.

Don't rest your security posture on an unofficial proxy. A client that consumes someone else's catalog works as long as the catalog's owner doesn't stop it, and this episode is exactly that. As a critical piece for getting security patches delivered, it's fragile by design. A patch that doesn't arrive on time does more damage than an inconvenient but stable channel.

Don't de-Google a fleet you won't be able to sustain. If you administer corporate devices with MDM, or your users depend on apps that require platform attestation, the alternative path ends with people installing APKs from wherever to work around the block of the day. That's worse than where you started.

Don't open your own channel without a process. Distributing your APK demands key custody, a rotation plan, a vulnerability disclosure channel, and updates that actually arrive. Without that, your own channel is a new attack surface with fewer controls than the store you're avoiding.

And don't attribute intent to this yet. With one work item and one issue, we don't know whether the block was a policy decision, a technical change, or a side effect. It's fair to draw conclusions about the structural risk; it's not fair to draw them about the motive.

What I'd do today

I'd do the boring inventory: list the channels my software reaches the user's device through and mark which ones depend on a third party that can cut them off tomorrow. For each one, define what happens the day it gets cut. And if you're a GrapheneOS user, the worst possible reaction is replacing Aurora with the first mirror that shows up in a search: wait, verify signatures, and prioritize the apps that publish verifiable binaries on their own.