Android is adding an identity check beyond the Play Store

What begins on the phone in June

The June system service prepares phones to check developer registration later. It does not mean every unverified app stopped working immediately. Enforcement begins on affected certified Android devices in the four named countries on September 30, while seven stores participate in the initial phase.¹

Google says most Play developers have already completed identity verification and that more than 99 percent of Play apps are registered. The larger change concerns software distributed through other stores, direct downloads and small projects that never needed a Play Console account.¹

The system checks whether an app's package name is registered to a verified developer. It does not review every line of code, prove that an app is honest or guarantee that an update will remain safe. Identity can raise the cost of repeated abuse, but it cannot replace permission review, malware scanning and cautious installation.^1,2

Why Google calls it a scam defense

Google presents the system as a response to scams that pressure people to install software outside an established store. Under that rationale, verified identity gives the platform a more durable party to remove or investigate when one package disappears and another appears.¹

Google says it chose the first four countries because they have faced high levels of fraud and coercion scams. The advanced installation flow is intended to preserve a route for power users while making a pressured installation harder. Its effectiveness will depend on the warnings and whether users can distinguish a legitimate independent app from a scammer's instructions.^1,2

A verified developer can still publish a bad app or lose control of an account. Users should treat verification as one signal. The app's requested permissions, update history, public source code and reason for avoiding an established store remain relevant.^2,3

The cost lands differently on small developers

A company with a Play account may notice little beyond registration and new APIs. A student sharing a tool with classmates, an open-source maintainer distributing builds, or a local organization using an internal app can face new identity and package-management work.^1,2,3

Google plans limited-distribution accounts for students, hobbyists and learners. Those accounts can share apps with up to 20 devices without a government-issued ID or fee. The cap makes them useful for experiments, not for a community project with hundreds of users.¹

Google is also adding APIs for bulk registration and delegated management by other stores. That reduces administrative work for established distributors. It does not settle the broader question raised by independent Android projects: whether a platform controlled by Google should mediate identity for software installed outside Google's own store.^1,2,3

What sideloading users should do

If you rely on an app downloaded from a developer's website, check whether the developer has published a verification plan. Do not wait until the September deadline if the app controls authentication, health records, home devices or work access. Keep an exported backup where the app supports one.¹

Use the store or website that the developer links from its official domain. Compare the signing fingerprint when a project publishes one. Avoid APK mirrors that repackage files, and never install an app because a caller or chat message says an account will be closed unless you do so.^1,2

The advanced unverified path should remain a deliberate exception. A warning is not proof that an app is malicious, but bypassing it removes one layer designed for high-pressure fraud. Stop and verify the publisher through a separate channel before continuing.¹

Openness now has a registered name attached

The change does not eliminate alternative stores, Advanced Flow or ADB. Alternative stores participate in the first launch rather than being prohibited. The meaningful change is that ordinary installation of unregistered apps on affected certified devices receives additional friction.^1,2

That can reduce abuse while concentrating power over who counts as a developer. The rollout will test how burdensome registration is for small projects, how usable the advanced path remains and whether stores can manage registration without becoming dependent on a confusing Google process.^1,3

Organizations that manage family, school or company phones should document the source of each privately distributed app now. A package that arrives through an old email attachment or shared drive may have no maintainer left to register it. Replacing that app before enforcement is safer than teaching users to bypass a warning they may later encounter during a genuine scam.^1,2

For most users, the safest response is neither blind trust nor immediate rejection. Check the exact source, understand why an app is outside a store, and keep the ability to recover data if a useful independent app does not survive the transition.^1,2,3

• On an affected certified Android device in Brazil, Indonesia, Singapore or Thailand, check direct-download apps for a developer verification notice before September 30.
• Export important data from apps that may lose distribution access.
• Install from the developer's official domain rather than an APK mirror.
• Treat identity verification as one safety signal, not a code audit.