Publishing on Google Play: the parts nobody explains
Accounts, testers, money, policies and bans. A working guide for people who actually ship.
People say Google Play is the easy store. Pay $25, upload an APK, done.
That stopped being true a few years ago.
Today a new personal account cannot publish to production until twelve real people have tested the app for fourteen days in a row. Every developer is identity-verified. The fee model changed in 2026. And Google’s enforcement has one rule that surprises almost everyone: when an account is terminated, Google can close every account it thinks is connected to it.
I have been through this more than once. This guide covers the whole path, from choosing an account to what happens when Google takes your app down.
This is part two. Part one covered the App Store. If you ship on both, read both. The two stores look similar and behave very differently.
Part 1: Choose the right account first
Both account types cost a one-time $25 and have the same features. Both can sell apps and in-app products. The difference is verification, testing rules, and who the store shows as the developer.
Personal account
For students, hobbyists and solo developers. You verify with a government ID.
The catch: personal accounts created after 13 November 2023 must run a closed test with at least 12 testers, opted in continuously for 14 days, before they can apply for production access. More on this in Part 3, because it is the step that decides your launch date.
Organization account
For a business or any organization. The D-U-N-S number is mandatory. That is a nine-digit business ID from Dun & Bradstreet, and Google uses it to verify your company.
Expect to provide official business documents, your website, contact details that must stay working, and an identity check for the person registering.
The big benefit: organization accounts skip the 12-tester rule.
The trap that fails a lot of verifications: your company name and address must match exactly across three places, your D-U-N-S record, your business documents, and your Google payments profile. One abbreviation difference is enough to fail.
Another trap: your account type and your payments profile type must match. A business running on a personal account and a personal payments profile is the classic mismatch.
Tip: if you run a real business, register as an organization from day one. Moving apps between accounts later is slow and painful.
Private apps, the Android version of “in-house”
Apple has an Enterprise program. Google does not have an equivalent, and does not need one.
Instead, you publish from your normal Play Console as a private app and target specific organizations. Their staff install it through managed Google Play, usually with their device management tool. There is no extra fee.
This is the right route for internal tools, company apps and client-specific builds.
Limited distribution accounts, new in 2026
Google now requires every app installed on certified Android devices to come from a verified developer, even apps installed outside Play. To keep that fair for students and small projects, Google launched a free limited distribution account in August 2026. It lets you share an app with up to 20 devices, with no government ID and no fee.
Enforcement of this verification rule starts on 30 September 2026 in Brazil, Indonesia, Singapore and Thailand, and rolls out globally from 2027. If you distribute APKs outside Play in those countries, this affects you now.
Testing without publishing
- Internal app sharing: upload a build and share a link with testers in minutes, with no review.
- Internal testing track: up to 100 testers, publishes fast
Part 2: What you need before you start
- A Google Account with two-step verification on.
- Your ID, and for organizations, the D-U-N-S number, documents and website.
- A payments profile that matches your account type.
- A working developer email and phone number. They are verified with a one-time code, and they must keep working for as long as the account exists.
That last one matters more than it sounds. If Google cannot reach you, you miss policy emails, and missed policy emails turn small problems into removals.
Part 3: The release path, step by step
1. Create your upload key and turn on Play App Signing
You sign your app with an upload key. With Play App Signing, Google holds the actual app signing key and you keep the upload key.
This is the setup you want. If you lose your upload key, you can ask Google to reset it. If you managed the app signing key yourself and lost it, you could never update that app again.
Back up the keystore file and both passwords in two separate places, and keep the key properties file out of Git.
2. Build an Android App Bundle
New apps must upload an AAB, not an APK.
Two technical requirements catch people right now:
- Target API level. Since 31 August 2026, new apps and updates must target Android 16 (API 36). Google raises this every year, usually with an August deadline.
- 16 KB memory page size. Since 1 November 2025, new apps and updates targeting Android 15 or higher must support 16 KB page sizes. If your app uses native code, including through packages, update your framework and plugins first. Old native libraries are what break this.
Raise the version code on every upload.
3. Create the app in Play Console
You choose a name, a default language, app or game, and free or paid.
Free or paid is permanent. A free app can never become a paid app. If you think you might charge later, charge through in-app purchases instead of the download price.
Then the Dashboard shows a setup list. Every task must be finished before you can publish.
4. Run the closed test, if you are a new personal account
The rule is simple to read and easy to get wrong:
- At least 12 testers
- Opted in continuously for 14 days
- On the closed testing track, not internal testing
If testers drop out, your count drops with them. Recruit a few more than twelve.
After that, you apply for production access. Google asks what your testers found and what you changed. Keep notes during those two weeks, because a vague answer here can get the application rejected.
Do not fake this. Tester farms, bought installs and scripted testers exist, and Google treats them as an attempt to deceive the review process. That is a much bigger problem than a two-week delay.
5. Fill in the store listing
- App name: 30 characters
- Short description: 80 characters, shown first
- Full description: 4,000 characters
- App icon: 512×512 PNG, up to 1 MB
- Feature graphic: 1024×500, no transparency
- Phone screenshots: at least 2
Keep promotional words out of your graphics and title. No “Top”, “#1”, “Best”, “Free” or “Sale”. And your screenshots must show the real app.
6. Release to production
Create a release, upload the bundle, write release notes (500 characters per language), clear every error and warning, then choose a rollout percentage.
Always start with a staged rollout. Release to 10 or 20 percent first. If a crash shows up, you can halt the rollout before everyone gets it.
Review for new apps can take up to 7 days, sometimes longer. Plan your launch date backwards from that.
Part 4: App content, the section people rush
This is where most first-time launches get stuck. Google checks these answers against what your app actually does.
Privacy policy. A public, working URL. Link it inside the app too.
App access. If any part of the app needs a login, give Google working test credentials. Reviewers who cannot log in reject the app.
Ads. Declare whether the app shows ads. Many SDKs count, even if you did not think of them as ads.
Content rating. Answer the questionnaire honestly. A wrong rating is a policy violation, not a typo.
Target audience. If children are in your audience, the Families policy applies, with stricter rules on ads and data.
Data safety form. List every type of data your app and its SDKs collect and share. This is the one people fail most. Analytics, crash reporting, ad networks and login providers all collect data. “I did not write that code” is not an excuse. You are responsible for every SDK in your app.
Account deletion. If users can create an account in your app, they must be able to delete it from inside the app, and you must also provide a web link where they can request deletion without reinstalling. That link goes in the Data safety form.
Permissions get reviewed by hand
Some permissions trigger a declaration form and a manual review. Background location, SMS, call log, and all-files access are the common ones.
If media access is not core to your app, use the system photo picker instead of asking for broad photo and video access.
Remove what you do not use. Packages add permissions to your manifest without asking you. Open the merged manifest and check it before every release.
Part 5: Money, e-commerce and fees
Before you can sell anything
Link a payments profile with your tax and bank details. Then create your in-app products and subscriptions in Play Console.
The digital versus physical line
Same principle as Apple:
- Digital goods used inside the app: coins, premium features, subscriptions, courses in the app go through Google Play’s billing system, or an approved alternative in regions that allow it.
- Physical goods and real-world services: clothing, food delivery, taxi rides, hotel bookings can use any payment provider. Google takes nothing.
An e-commerce app using Stripe or a local payment gateway is normally fine, because the goods are physical.
What Google charges in 2026
This changed a lot this year, and it now depends on where your users are.
Get Kasunpradeep Ds’s stories in your inbox
Join Medium for free to get updates from this writer.
In the US, UK and EEA, since 30 June 2026, Google splits its fee into two parts:
- A service fee, charged on every transaction no matter how the user pays. It is 10% on auto-renewing subscriptions and on your first $1 million in annual earnings, and higher on other one-time purchases.
- A billing fee of 5%, charged only if you use Google Play Billing.
So a subscription through Google Play Billing still costs 15% in total, the same as before. If you use your own payment provider where that is allowed, you skip the 5% but take on payments, tax, refunds and fraud yourself.
Everywhere else, the older model still applies for now: 15% on subscriptions and on your first $1 million, 30% above that. Google has scheduled the new model for Japan and Korea at the end of 2026, and for the rest of the world in 2027.
For small developers: unless your revenue is serious, Google Play Billing is simpler, and the saving from switching is often smaller than the work.
Part 6: Games, loot boxes and gambling
Games
Loot boxes. If players can buy randomized items, you must show the odds of each item before they buy.
Content rating. Simulated gambling affects your rating even when no real money is involved.
Contests and prizes. Official rules, odds, entry deadlines and prize dates must be disclosed. Once users pay to enter for a chance at something valuable, you are close to gambling rules.
Kids. If children may play, the Families policy applies to your ads, your SDKs and your data collection.
Real money gambling
Google Play generally does not allow real-money gambling apps. The exception is for licensed operators who apply to Google and get approved. The main requirements:
- Complete Google’s gambling application and be approved before you publish.
- Hold a valid licence for each country, and where needed each state, where the app is distributed.
- Block users in locations your licence does not cover.
- Prevent under-age users from using the app.
- Make the app free to download, and do not use Google Play Billing for gambling transactions.
- Show responsible gambling information in the app and on the listing.
Google only accepts gambling apps in a specific list of countries, and that list changes. Check the current Play Console Help page before you plan anything.
In practice, this category means an organization account, a licence, and legal support. Publishing a gambling app without the approved application is one of the fastest ways to lose an account.
Part 7: Other categories that get extra attention
- Loans and financial services — strict disclosure rules, and personal loan apps face extra requirements in many countries.
- Health — no misleading medical claims.
- VPN — must follow specific rules on data and purpose.
- Apps for children — the Families policy, approved ad SDKs only.
- User-generated content — you need moderation, reporting and blocking.
- Impersonation and copycats — using another brand’s name, icon or look is a fast removal, and it can count against your account.
- Spam and minimal apps — near-duplicate apps and very thin apps get removed.
Part 8: When things go wrong
This is the section that matters most. Google’s enforcement is more automated than Apple’s, and it reaches further.
The levels
1. Rejection. An update or new app is refused. Rejections do not affect your account standing. Fix everything, then resubmit.
2. Removal. A live app is taken down. It does not count as a strike on its own, but repeated removals can lead to suspension.
3. Suspension. The app is removed for good. Its users, ratings and statistics are lost and cannot be restored by republishing. A suspension counts as a strike against your account.
4. Termination. Your whole account closes. Every app comes down. You do not get the $25 back.
The rule that surprises everyone: related accounts
When Google terminates an account, it can also terminate every account it considers related.
Google does not publish exactly what “related” means. In practice, developers report links such as shared payment methods, shared contact details, the same devices or networks, and shared people.
Two consequences:
- Do not open a new account while one is terminated. Google says clearly that new accounts will be terminated too, without a refund. This single mistake turns a fixable situation into a permanent one.
- Be careful who you share an account with. If you publish a client’s app on your account, or let someone publish on yours for money, their violations become yours. The same goes for buying a “ready-made” developer account. Do not do it.
How to appeal a termination
- Read the email sent to your registered developer address and find the exact reason.
- Appeal through the official channel in Play Console.
- For accounts terminated on or after 28 January 2026, you have 180 days to appeal. After that, the case is closed.
- Answer the specific reason with facts and documents. Explain what the app does and why the decision is wrong, or what you have already fixed.
- Stay calm and precise. An angry appeal does not help.
How to handle a rejection or removal
- Read the email and the Policy status page in Play Console.
- Find the exact policy and the screen or text that triggered it.
- Fix it across the whole app, not just the flagged screen. Google expects you to check the rest of your app too.
- Listing problem? Update the listing and resubmit. App problem? Fix it, raise the version code, upload.
- If you disagree, appeal from Policy status.
Protect yourself before anything happens
- Keep your email and phone working, and read every Play Console message.
- Keep your upload key and Play Console access in more than one safe place, reachable by your team.
- Never use tester farms or buy installs, reviews or accounts.
- Audit your SDKs before each release. Your Data safety answers depend on them.
- Keep your own copy of your user data. If the account goes, access to it goes too.
A short checklist before you submit
- Right account type, payments profile matches
- Upload key backed up, Play App Signing on
- AAB built, target API 36, 16 KB page size supported
- Version code raised
- Closed test done, if you are a new personal account
- Listing text, icon, feature graphic, screenshots
- Privacy policy live, app access credentials added
- Content rating and target audience answered honestly
- Data safety matches every SDK, account deletion link added
- Unused permissions removed, declarations filed
- Payments profile and products set up, if you sell anything
- Staged rollout planned
Google Play is not the easy store anymore. It is the store where the rules are written down clearly, enforced by systems, and applied to everything connected to you.
That is actually good news. It means most problems are predictable. Read the policy that applies to you, answer every form honestly, never try to game the testers or the review, and keep your account clean.
If you have been hit by a policy email recently, share the policy name in the comments. Someone here has almost certainly fixed the same thing.
Sources and further reading
Official pages to check before you act, because these rules change often:
- Choose a developer account type — Play Console Help (support.google.com/googleplay/android-developer)
- Required information to create a Play Console developer account — Play Console Help
- Verify your developer identity information — Play Console Help
- App testing requirements for new personal developer accounts — Play Console Help
- Enforcement process — Play Console Help
- Real-Money Gambling, Games, and Contests — Play Console Help
- Google Play Developer Program Policies — play.google.com/about/developer-content-policy/
- Android developer verification — developer.android.com/developer-verification
- Service fees and the billing choice program — Play Console Help
Last checked: September 2026. Fees, regional billing rules and verification deadlines are changing quickly this year, so confirm anything money-related or date-related on Google’s own pages before you rely on it.









