A customer installs your app, signs in and meets a message that says their phone is not supported. The device still works. The customer is real. Somewhere between installation and the server, a security rule has made a decision that support now has to explain.
That is a useful starting point for the Android debate. Fraud prevention matters. So does the ability to install software and use a device you own. Understanding the actual mechanisms makes it possible to discuss both without turning every technical decision into a shouting match.
This article reflects documentation checked on 8 October 2026. Rollout details can change. It distinguishes documented behaviour, the positions of interested parties and our engineering analysis; it does not claim that Zephyrus has measured the real-world effectiveness of these controls.
Three layers that should not be confused
AOSP is the publicly available Android source project. Google Play and Google Mobile Services belong to a wider ecosystem with their own participation and licensing arrangements. Being able to build an Android variant does not guarantee that every service or application will accept that variant. AOSP overview.
Developer verification connects a developer identity to registered applications. Play Integrity provides signals about a particular app and its environment. The application provider then decides what a user may do. A verified developer, a recognised app package and an accepted device are different questions.
Think of a venue: identifying the organiser, checking a ticket and deciding who can enter a restricted room are separate controls. Passing one does not automatically settle the others. The analogy is ours; it describes the distinction, not the Android protocol.
What changed in September 2026
The current published timetable starts on 30 September 2026 for participating stores in Brazil, Indonesia, Singapore and Thailand, on certified devices running Android 7 or later. Wider expansion is planned for 2027. That is a regional, channel-specific rollout, not a worldwide ban on direct installation. Current timetable.
The participating-store list includes Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. The current FAQ explicitly says that other stores and direct sideloading are outside this initial enforcement phase. Older announcements and some broad wording elsewhere in the documentation can obscure this distinction. Participating stores; Rollout FAQ.
Google also documents an advanced installation flow for unverified apps, unchanged ADB installation, and limited distribution accounts. The latter allow sharing with up to 20 authorised devices without government-ID verification or a registration fee. They still require account information; “no government ID” does not mean anonymous distribution. Limited distribution requirements.
Open-source distribution remains a separate practical concern: a distributor may rebuild and sign an app with a different key. Google now documents registration of that signing arrangement and an advanced-flow option for unregistered apps. A project should check its actual distribution path rather than assume that registration on one store covers every binary. Open-source registration guide.
What Play Integrity can tell an application
Play Integrity can return information about app recognition, Play licensing and device integrity, with optional signals for further risks. The labels have defined criteria. A missing label is not a biography of the person holding the phone. Google recommends combining these signals with other controls and understanding the audience before enforcing restrictions. Play Integrity guidance.
The distinction matters on modified or older devices. Basic integrity is not the same as the stronger device checks. On Android 13 and later, strong integrity also considers recent security updates. A customer may therefore fall outside a stricter policy because of the device’s update situation, without having attempted fraud. That is an interpretation of the documented criteria, not a claim that such a device is necessarily safe. Definitions of the verdicts.
Accessibility deserves particular care. Google documents an exclusion from certain app-access-risk signals for verified accessibility services. That is narrower than saying every accessibility tool is automatically excluded. A blanket message telling users to remove all assistive software would be both misleading and a poor support policy. App access risk and accessibility.
The security case and the governance cost
Google presents identity verification as a way to make repeat abuse harder: removing a malicious app should not be followed by the same operator returning under a fresh anonymous identity. This is the provider’s rationale. An identity check is not a code audit, and the documentation alone does not establish how much fraud the programme prevents. Google’s explanation.
F-Droid argued in September 2025 that central registration would put independent distribution and developer privacy at risk. That is a primary statement from an affected project, written about an earlier proposal. It is useful evidence of its concerns, not proof that F-Droid has stopped working under the current rollout. F-Droid’s dated position.
Our assessment is that both operational questions deserve scrutiny. A control may make abuse more expensive while also adding paperwork, support costs and dependence on a central decision-maker. Asking who can appeal, what happens during an outage and which legitimate users are excluded is part of evaluating security, not a refusal to take it seriously.
A decision checklist before blocking users
1. Name the action you are protecting. Reading a help page, redeeming a promotion and approving a sensitive account change do not have the same risk. Write a policy for the action before choosing a device threshold.
2. Observe before enforcing. Review which signals your existing users return, with proportionate data collection and retention. Separate missing information, temporary errors and explicitly adverse results. Otherwise, an unavailable service can masquerade as a fraud wave.
3. Compare graduated responses. Depending on the threat, options might include a retry, an additional check, a restricted operation or a refusal. These are design choices to assess, not a universal instruction to allow access when a check fails.
4. Make the message actionable. “We could not verify this request; try again” and “This app version is not supported” describe different situations. Give support a reference that helps investigate without exposing tokens or unnecessary personal data.
5. Test the inconvenient cases. Include an ordinary supported device, an old security patch, a legitimate alternate distribution channel, accessibility tools and an API outage. Record the expected result before running the test. This is a proposed test plan, not a report of tests we have performed.
6. Review the trade-off. Track confirmed abuse, legitimate-user complaints and recovery outcomes separately. A rising block count can mean better detection, a broken integration or an overly broad rule. It is not a success metric on its own.
A small example, without a universal rule
Imagine a fictional retail app. Browsing the catalogue is low risk; repeatedly claiming a new-customer discount is not. The team could investigate stronger checks around the discount operation while keeping public product information accessible. A payment or account-recovery flow would need its own assessment. One “allow or deny everything” switch would hide these differences.
The useful question is therefore not simply whether Play Integrity is good or bad. It is whether a specific signal supports a specific decision, whether the customer can recover from a mistake and whether the policy remains proportionate as the ecosystem changes. A security gate still needs someone to answer the intercom.
Planning an Android app? Include distribution channels, device support and failure handling in the scope from the beginning. Explore Zephyrus mobile app development.