Android Now Asks Who Built Your App. On September 30, "Our Agency Handles That" Stops Being an Answer.

What Actually Changes on September 30?

For most of Android's history, the platform made a simple promise to anyone outside Google Play: build an APK, sign it, hand it to users, and it will install. That promise gets a condition on Tuesday. According to Google's June 18, 2026 update on Android developer verification, the protections take effect on September 30, 2026 for users in Brazil, Indonesia, Singapore and Thailand, and apps installed on certified Android devices there must be registered to a verified developer. The same post lists seven participating stores: Google Play, Honor App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore and Xiaomi GetApps.

The policy itself is not new. Google first announced it on August 25, 2025, in a post titled A new layer of security for certified Android devices, which justified the change with an internal analysis that found over 50 times more malware from internet-sideloaded sources than from apps on Google Play. The same post described verification as an ID check at the airport: Google confirms who the developer is, but does not review the app's content. That distinction matters later, because it means verification is about identity and ownership, not code quality.

Registration is not a checkbox. Per the Android Developer Console help page on verification, a full distribution account carries a $25 fee, requires government ID verification, and for organisations requires a D-U-N-S number from Dun & Bradstreet. The developer then registers each package name and proves ownership with the app's signing key. A separate limited distribution account exists for students, hobbyists and closed groups, with no fee and no government ID, but it can only distribute to up to 20 devices, which rules it out for any commercial product.

What happens to an unregistered app after the deadline is also specific. The Hacker News' report on the deadline describes it as blocked from normal installation in the four launch markets, still installable over Android Debug Bridge or through a new advanced flow for power users. For a business, neither exception is a distribution strategy. Customers, field staff and partners do not install apps with ADB, and nobody should build a support process around asking them to wait a day and toggle developer options.

"We Don't Sell in Brazil" Is Not a Safe Answer

Most of Stepto's clients are in the EU, the UK and the US, so the first reaction to a deadline in four Latin American and Southeast Asian markets is reasonable: not our problem yet. Three facts in Google's own announcement argue against waiting.

The first is Google Play itself. In the June update, Google says 99% of apps on Play have been registered automatically, and asks developers to check the Play Console home page and register any remaining apps by September 30, 2026 to avoid global removal from Google Play. Global means global. If your app is in the 1%, for example because it was published years ago under an account nobody actively maintains, the risk is not a regional install warning. It is the listing disappearing everywhere.

The second is scale. The Hacker News' coverage puts the affected base at more than 95 percent of Android devices outside China, because the requirement applies to certified devices, which is almost every phone with Google services. The third is the timeline: Google states that it will expand the protections globally for all apps on certified Android devices in 2027. September 30 is the pilot. The rules that apply in Jakarta next week are the rules that will apply in Munich, Madrid and Chicago next year.

There is also a near-term exposure many companies miss. B2B and logistics platforms, fintechs with regional operations, and SaaS vendors with field apps often have users in exactly the launch markets: a warehouse in São Paulo, a sales team in Singapore, a distributor in Bangkok. If any of those users install your app from a download link or a partner store rather than Play, they hit the new rule on day one.

Whose Name Is on Your App? The Question Outsourcing Contracts Never Asked

Here is the part that turns a platform policy into a vendor management problem. Verification binds an app to a verified identity. For an app built in-house, that identity is obviously the company. For an app built by an agency, a freelancer or a long-gone contractor, it is often not obvious at all.

Agencies commonly publish client apps from their own developer accounts, because it is faster at launch and nobody wants to wait for a D-U-N-S number when a demo is due. Freelancers sometimes do the same with personal accounts. Before verification, that was an untidy arrangement with a manageable risk: transferring an app between Play accounts was a known process. Now, the account identity is the thing Android checks before an install. If the verified developer on record for your package is your agency, your app's legitimacy on a customer's phone is tied to a company you pay, not the one you are.

This is the same ownership problem Stepto has written about in who owns the code in an outsourced development contract, with a sharper edge. A contract can assign copyright in the source code to you and still leave the developer account, the package registration and the signing key with the vendor. Copyright tells you who may use the code. Registration now tells Android who may ship it.

The practical test takes an afternoon. For every Android app your company distributes, write down which developer account the package is registered under, whose legal identity verified that account, and who has the credentials. If any answer is a vendor, a former employee, or "not sure", that is the first item to fix, before September 30 for apps with users in the launch markets and before 2027 for everything else. A good partner will welcome the exercise. At Stepto, client apps are published under accounts the client owns, with our engineers added as users with scoped permissions, because the alternative makes our clients dependent on us for reasons that have nothing to do with the quality of our work.

The Signing Key Is Now Proof of Ownership

If the developer account is the name on the app, the signing key is the deed. Google's developer verification FAQ is blunt about it: it strongly recommends a secure key management solution, and states that if you lose your signing key you won't be able to register your packages. The same FAQ says that where a package name is already in use and your key is not eligible to claim it outright, you should consider a different package name, and that a manual request requires additional review and the package name may also be used by other developers.

Read those two answers together and the risk is clear. An app whose signing keystore lives on a former contractor's laptop, in an agency's CI system you cannot access, or in a password manager that left with an employee, may not be registrable by you at all. Changing the package name is technically possible and commercially painful: to Android it is a different app, so existing installs will not upgrade to it and users have to be moved over manually.

Apps on Play that use Play App Signing are in a better position. The FAQ confirms that in that case Google has the information needed to identify ownership and the apps are part of the automatic registration process. It also notes that the Android Developer Console lets you add and verify multiple signing keys for one package, which helps teams that sign different distribution channels differently. Neither of those removes the need to know where your upload key is and who can use it.

Treat this as the moment to do key custody properly. Signing keys belong in a company-controlled secrets store or hardware-backed key management, with access granted to the pipeline rather than to individuals, and with a documented recovery path. Stepto covered the wider version of this problem in secrets sprawl and credential hygiene; Android signing keys are one of the few secrets where loss is not just a security incident but a permanent loss of the ability to prove you own your product.

Apps Outside Play: Enterprise, White-Label and Field Devices

The apps most likely to fall through the cracks are the ones that never went near Play in the first place: an APK linked from a customer portal, a white-labelled build per client, a kiosk or point-of-sale app, a companion app shipped with a hardware device, or an internal tool that the operations team emails to new hires.

Managed enterprise apps have a partial exemption. The verification FAQ says apps distributed through an organisation's store on managed devices won't need to complete verification, since the IT admin has vetted them, but Google still recommends registering them so installs work smoothly if the app is downloaded from another source or onto a non-managed device. In practice, very few companies run every device through mobile device management. Contractors, partners and bring-your-own-device staff are exactly where an unregistered app will fail.

White-label products deserve particular attention. A platform that ships one Android build per customer, each with its own package name, may have dozens of packages to register, some of them signed by keys the customer controls and some by keys the vendor controls. The same goes for device makers whose companion apps were built by an outside firm years ago. Each one needs a named owner, a registered package and a key that someone can actually find.

This is also where cross-platform choices surface. Whether your app is native Kotlin, Flutter or React Native makes no difference to verification, because registration happens at the package and signing level, not the framework level. What does differ is how many build variants your pipeline produces. If you are weighing that trade-off, our comparison of Flutter, React Native and Kotlin Multiplatform covers the longer-term implications.

What Changes in the Build and Release Pipeline

Verification is administrative at launch, but it becomes an engineering concern the moment you ship more than one app or more than one variant. Google is adding tooling for exactly that. In the June update, it describes an Android Developer ID Status API that lets you check whether a package name has already been registered, and an Android Developer Console API that lets you register and manage package names directly within your development environment.

Those two APIs point to a sensible pipeline change. Before a new package name goes out, CI should check that it is registered to the right account, and a release that introduces a new variant, a new white-label customer or a new flavour should register it as part of the release rather than as a manual afterthought. The same check should run against existing packages periodically, because registration drift, such as a key rotated without the new key being added, is the kind of failure that surfaces as a user complaint rather than a build error.

Internal testing needs a small rethink too. Google's FAQ is explicit that apps installed with ADB do not require verification, which covers engineers testing on their own devices. It does not cover a QA team, a product owner or a pilot customer installing a staging build from a download link, because that goes through the normal installer path. The safe assumption is that any build installed by someone who is not plugging a phone into a laptop needs a registered package name, including staging and beta variants with their own application IDs.

None of this is difficult for a team that already runs disciplined mobile CI. It is harder for companies whose Android release process is a senior developer building locally and uploading by hand, which is more common than most CTOs would like. If that describes your setup, the verification deadline is a good forcing function to move signing and release into a pipeline your company owns, whether your team does it or dedicated Android developers do it for you.

The Backlash, and Why It Doesn't Change Your Plan

The policy is controversial, and it is worth understanding why. On February 24, 2026, F-Droid published an open letter opposing Android developer verification, signed by organisations including the Electronic Frontier Foundation, the Free Software Foundation Europe and the Software Freedom Conservancy. The letter argues that mandatory registration, fees and government ID submission turn Android from an open platform into a gatekept one, put future app store competitors at a permanent disadvantage and effectively end the direct installation of software users choose.

Google's response has been the advanced flow. Per 9to5Google's report on its August rollout, users enable an option in developer settings, pass through warnings and a one-time 24-hour waiting period, and can then allow apps from unverified developers for seven days or indefinitely. Google's framing is that the delay breaks the pressure tactics scammers use to coach victims into installing malware.

Whatever your view of the policy, and there are reasonable arguments on both sides, it does not change what a business should do. Enterprises are not the audience for the advanced flow and should never ask customers to use it. Regulators may shape how the global rollout works, particularly in the EU, but planning around a possible reversal is a bet with an asymmetric downside. Registering apps you already own, under an identity you already control, costs little and is useful regardless of how the policy debate ends.

A Four-Day Checklist, and a Plan for 2027

If your company has Android users in Brazil, Indonesia, Singapore or Thailand, or apps on Play that you have not looked at in a while, the next four days are for confirmation rather than engineering. Open the Play Console home page for every developer account you control and check for unregistered apps. List every app distributed outside Play and check whether its package is registered. For each app, confirm the verified identity on record is your company.

If any of those checks fails because the account or key sits with a vendor, start the conversation now, in writing, and ask for three things: the developer account or a transfer of the apps into yours, the signing keystore and its passwords, and confirmation of every package name registered on your behalf. The mechanics of a clean handover are the same ones we describe in our vendor transition plan; verification simply gives them a date.

For everyone else, the deadline to plan for is 2027. Use the next quarter to move every app into company-owned accounts, put signing keys under proper custody, register all variants, and wire the new registration APIs into CI. That is a few weeks of focused work for an experienced mobile team, not a project that needs its own budget line.

This is the kind of work where a nearshore mobile development team earns its keep: senior Android engineers who have done ownership and signing migrations before, working in European hours, handing back a pipeline and a set of keys that belong entirely to you. Stepto builds and maintains Android apps for clients in exactly that model, with accounts, keys and repositories in the client's name from day one.