Android Developer Verification Is Live: What Founders Must Do

On September 30, 2026, Android developer verification went into effect. For users in Brazil, Indonesia, Singapore and Thailand, an app installed on a certified Android device from a participating store now has to be registered by a verified developer. Google's developer documentation says the program covers Android 7 and up, and that a global rollout for certified devices follows in 2027.

The participating stores named in Google's guide are Google Play, HONOR, OPPO, Galaxy Store, Palm Store, V-Appstore and GetApps. If your app reaches users through any of those in the four launch countries, the rule applies to you.

Two details matter more than the headline. First, the requirement is about the developer, not only the app. Google wants to know who is behind a package name, and it checks that against legal identity documents before it will register the app. Second, Google's guide says the requirements apply if your app runs on a certified device, regardless of where the download came from. That is a broader statement than "Play Store apps only," and it is the sentence founders skip when they read the news in a hurry.

None of this means your app disappears overnight. It means there is now a registry of developers and apps, and an app missing from it can fail to install on the phones that matter. Treat it like a business license for your Android distribution. Boring, mandatory, and expensive to ignore.

Most founders reading this are in one of four situations, and the work differs a lot between them.

• Your app is on Google Play and you own the Play Console account. You have the least to do. Google's policy page says 99 percent of apps on Play were registered automatically. Your job is to confirm yours is one of them.
• Your Play account belongs to an agency, a freelancer or a former cofounder. You have a quiet risk. The identity that gets verified is the account holder's, and that person may not be you.
• You distribute APKs yourself. That includes beta links, enterprise installs, a download button on your website and builds sent to field staff. You have the most work, because nothing registers these apps for you.
• You sell to businesses in Brazil, Indonesia, Singapore or Thailand. Even if your own users are elsewhere, your customers' devices fall under the rule. A pilot with a regional distributor can stall on this.

If you only ship on iOS, nothing changes for you today. If you are cross-platform, the Android half of the product just picked up a compliance task that the iOS half does not have. That is worth knowing when you compare the two budgets, and our breakdown of iOS versus Android development cost is the place to start adjusting those numbers.

One more group deserves a mention. If you bought or inherited an Android app and the original developer is gone, you may not know which account published it. Find out now. Recovering a Play Console account after the fact is slow, and the new rule gives it a deadline it did not have before.

Developers must verify their identity before registering apps. According to Google's guide, the process asks for personal information: legal name, address, email and phone number. For a company, expect to connect the account to the business and the person authorized to act for it.

A practical way to think about it is in three layers:

1. The person or company. Legal name and address as they appear on official documents. A trade name on your website is not enough.
2. The contact channels. A monitored email and a phone number that can receive verification codes. Do not use a personal number belonging to a contractor who might leave.
3. The apps. Each package name gets registered against the verified identity. Package names you published years ago and forgot about count too.

That third layer surprises people. Founders often have an old prototype, a white-label variant or a pilot build for one customer still sitting under the account. Each one is a package name. Decide which ones you still need, and retire the rest on purpose instead of letting them fail registration later.

Third-party guides describe a one-time fee for a full distribution account and a free limited account capped at 20 devices. Those figures come from secondary sources, so confirm current fees and limits on Google's own pages before you budget for them. The limited account is aimed at students and hobbyists, and it is not a fit for a company that ships to customers.

If your app lives on Google Play, do this first, today, before reading anything else.

1. Sign in to the Play Console with the account that owns the listing. If you cannot sign in, you have found your first problem.
2. Open the Home page. Google says that is where unregistered apps show up, so look for any warning about an app that still needs registration.
3. Check the account details. Legal name, address, email and phone should all be current and tied to the business, not to whoever created the account in 2021.
4. List every app under the account. Match each one against what you actually sell.
5. Confirm who else has access, and what role each person has. Remove people who left.

The reason to be strict about step 1 is the penalty. Google's policy page warns that unregistered apps risk global removal from Google Play. Global is the important word. A registration problem that starts as a regional install failure in Jakarta or Sao Paulo can end as your whole listing coming down.

For most founders this check takes ten minutes and finds nothing. For some, it finds an account owner who is not the company, which is the more serious situation. Our guide to app maintenance costs covers why this kind of administrative upkeep belongs in your yearly budget instead of being treated as a surprise.

This is where the program bites hardest, and where the public explanations disagree with each other.

Some third-party explainers say that in the launch countries any app not registered by a verified developer will not install. Google's own guide frames it more permissively. It says sideloading is still possible, describes an advanced flow for installing unregistered apps with extra safeguards, and says the ADB workflow stays the same. Both can be true at once. The default experience for an ordinary user on a certified phone gets stricter, and a determined user can still get past it.

Plan for the ordinary user. Your field technician, your warehouse worker and your customer's employee will not use an advanced flow, and they should not need to. If your product depends on APK installs, you have three sensible options:

• Register the app and verify your identity. This is the cheapest answer for most companies. You keep your current distribution method and gain a normal install experience.
• Move distribution to a participating store. If you were sideloading only because Play review felt slow, this is a good time to reconsider. A managed track with internal testing is built for exactly that situation.
• Use managed device distribution for enterprise customers. Mobile device management lets a customer's IT team push approved apps to their own fleet. It is the standard answer for B2B tools, and customers who run MDM already expect it.

Do not build your plan on the advanced flow. It exists as an escape hatch, and escape hatches change. A support team that has to walk users through hidden settings screens in three languages will cost you more than the registration ever did.

If your reason for staying off Play is regional store access or fee avoidance, the comparison looks similar to the Apple side of the world. Our piece on alternative app stores lays out how to weigh reach against compliance work.

Your engineers will ask the practical question first: does this break my daily workflow? Based on Google's guide, mostly no. ADB installs stay the same, so a developer plugging a phone into a laptop and running a debug build keeps working.

The friction shows up one step away from the engineering team:

• QA and stakeholder testers who install builds from a shared link or a file in chat. These are ordinary installs, and they are the ones likely to hit warnings on certified devices in the launch countries.
• Beta programs run outside Play. Move them onto Play's internal and closed testing tracks, which keep the install flow normal and give you crash reports as a bonus.
• Demo devices for sales. A phone you hand to a prospect in Singapore should have a registered, store-installed app on it, not a sideloaded build from last week.
• Release candidates sent to partners. Anything a non-engineer has to tap and install is now a place for a warning to appear.

The cleanest fix is a habit. Every build a non-engineer touches goes through a store track, and only engineers install files by hand. That habit also helps with release hygiene in general, which our mobile app launch checklist covers in more detail.

If an outside team built your Android app, this section is probably the most important one in the article.

The verified identity attaches to a developer account. If your agency published the app under its own Play Console account, then the agency is the verified developer of record, and your app is registered under their name and address. That works until the relationship ends. Then you need to transfer the app, and a transfer now has an identity step in the middle of it.

Ask your current partner five things in writing:

1. Which Play Console account publishes our app, and who owns it?
2. Is our app registered under a verified identity, and whose?
3. Are we listed as an owner or admin on the account, or only as a viewer?
4. What happens to registration if we move the app to our own account?
5. Which package names have you published for us, including old ones?

A good partner answers these in a day. A partner who stalls is telling you something. The cleanest arrangement is that you own the Play Console account, you verify your own company, and the agency works as a team member with the access it needs. We have written about the contract side of this in who owns your app's code, and account ownership belongs on the same checklist as source code and design files.

If you do need to move an app, start early. Transfers involve a verified identity on the receiving side, and Google can take days to review it. A founder who starts the move the week before a launch is going to have a bad week.

Brazil, Indonesia, Singapore and Thailand are the first four markets. Google's documentation says the program expands to certified devices globally in 2027. It has not published a country-by-country calendar that I would put in a board deck, so treat the exact order as unknown and the direction as settled.

That gives you a sensible schedule:

• This week: run the Play Console check, confirm account ownership, and list your package names.
• This month: verify the company identity, register anything outside Play, and move informal testers onto store tracks.
• This quarter: write down who owns the account, who holds recovery access, and where the verification documents are stored. Add a yearly reminder to review them.
• Before launch in any new market: check whether verification applies there, since the answer will change during 2027.

Budget-wise, this is small. For a company with a clean Play account it is a few hours of someone's time and some document gathering. For a company with a messy account history, an old agency relationship or a sideloaded enterprise product, it can be a few days of engineering and a hard conversation about ownership. Either way it costs far less than losing a listing.

The wider point is worth saying plainly. Both major platforms now expect to know who you are, and both are moving distribution rules faster than they did five years ago. Apple's EU terms changed this autumn, Google's verification started this month, and Apple's SDK floor moves again in April. The founders who handle this well are the ones with one person who owns the calendar of platform deadlines. If that is nobody at your company right now, make it somebody.

Print this or paste it into your tracker.

1. Sign in to the Play Console as the real account owner. If you cannot, start account recovery today.
2. Check the Home page for apps that need registration.
3. Confirm legal name, address, email and phone on the account.
4. List every package name published under the account and retire the ones you do not need.
5. Find every place you distribute an APK outside Play and decide: register, move to a store track, or hand it to MDM.
6. Move all non-engineer testers onto Play testing tracks.
7. Ask your agency the five ownership questions above and get the answers in writing.
8. Store verification documents and recovery details somewhere two people can reach.
9. Add the global rollout to your 2027 roadmap as a recurring review.

None of these steps is hard. The risk is that nobody is assigned to them, because the news reads like a problem for large companies and bad actors. It is a problem for any business with an Android app and an unclear account history.

If you want a second pair of eyes on your Android setup, we review Play accounts, release pipelines and distribution plans for founders all the time, and a first pass usually takes under an hour. Book a free strategy call and we will tell you what to fix first.