Policy

It sits in a grey area. Google's Developer Distribution Agreement ties an account to one verified owner and restricts sharing or transferring account access. Publishing through someone else's account does not get an app removed by itself, but the listing legally lives under their verified identity, and Google can act on the account if its policies are broken.

New personal Google Play developer accounts must run a closed test with at least 12 testers for 14 continuous days before they can apply for production access. It's the main reason people publish through an established, verified account to launch quickly.

A D-U-N-S number is a business identifier Google requires for organisation developer accounts. You don't need one to publish through an existing account, but if you ever set up your own org account, that's part of the process.

The Data safety form is a mandatory declaration in Play Console where you disclose what user data your app collects, why, whether it is shared with third parties and how it is protected. It powers the “Data safety” section shown on your store listing. Inaccurate answers are a policy violation that can get the app removed, so it must match your app's real behaviour and your privacy policy.

Since 2023 Google requires every developer to verify their identity — legal name, address, phone and email, plus a D-U-N-S number for organisations — before they can publish. Personal accounts created after November 2023 must also complete the 12-tester / 14-day closed test. Verification can take a few days; if it is incomplete, publishing is blocked and the account can eventually be closed.

Most suspensions come from policy violations — malware or deceptive behaviour, impersonation, repeated content-policy strikes, payments fraud, or breaking the Developer Distribution Agreement. A termination usually bans the underlying Google identity from Play for good, and every app on that account goes down with it. That shared-fate risk is why careful publishers prefer the live-and-transfer model over one shared account.

The most common rejection reasons are a missing or invalid privacy policy, a Data safety form that doesn’t match the app’s behaviour, broken or crashing functionality, misuse of permissions, misleading metadata or screenshots, and intellectual-property or impersonation issues. Google emails the exact policy that was violated; fix that specific item and resubmit. Repeated rejections for the same issue can escalate into a policy strike against the whole account.

Add a publicly reachable privacy-policy URL that names your app, lists what data it collects and how it is used, then paste that URL into Play Console under Store presence → Store listing and in App content → Privacy policy. The policy must sit on a live, non-editable page (not a Google Doc set to edit) and must match your Data safety answers. Once both agree, resubmit for review.

A policy strike is a formal warning Google issues when an app violates a Play policy, and strikes accumulate against the developer account. Enough strikes — or a single severe violation such as malware or fraud — leads to app removal and eventually account termination, which bans the underlying Google identity from Play permanently. Because every app on a terminated account goes down together, careful publishers isolate risk using the live-and-transfer model.

Yes, and it happens constantly — agencies, studios and publishers ship client apps under their own account every day. The account owner is the party Google holds responsible, so they carry the policy risk and their name appears as the developer on the listing. Do it with a written agreement covering who owns the package name, the signing key and the listing, and how the app gets transferred out if you part ways.

Buying an account is far riskier than publishing through one. A sold account still carries the seller’s verified identity, and because Google now requires ID verification tied to a real person, an account whose owner-of-record is someone else is one verification prompt away from being frozen — taking every app on it down with it. Marketplace accounts also often arrive with a hidden strike history. If you need Play access without your own verification, publishing on an established, verified account and transferring the app out leaves you with a clean account in your own name.

No — an “aged” account is the most dangerous thing to buy, because age is exactly what makes it attractive to resellers who sell the same account more than once. You inherit its invisible history: past strikes, prior rejections, and the original owner’s identity documents on file. Google can request re-verification at any time, and the moment the ID does not match the person operating the account, it is terminated permanently and every listing on it disappears together.

You can avoid paying it yourself, but somebody has paid it — the fee is charged once per developer account, so publishing under an existing account means it is already covered. There is no legitimate waiver or free tier for a personal account, and services promising to bypass the $25 charge are scams. If the fee itself (rather than the wait or the verification) is the blocker, publishing through an established console or an organisation you already work for is the honest way around it.

Freelancers generally use one of three routes: get added to the client’s console as a user with release permissions (best when the client already has an account), publish through a publisher or agency partner and transfer the app to the client at handover, or open their own account and keep client apps on it. The third is the trap — one client’s policy violation can strike an account carrying every other client’s app. Keep client work off a shared personal account.

Yes — use Users and permissions in Play Console to invite them by Google account and grant a scoped role such as Release manager (upload and roll out builds) or Store listing manager (edit the listing only). This is the sanctioned way to let a developer, agency or publisher work on your app, it leaves an audit trail, and access can be revoked instantly. Sharing your actual login is both a policy violation and how accounts get hijacked.

Yes — Google Play does not care which tool built the app, only whether it meets policy. Apps from no-code builders get removed for the same reasons everything else does: they are thin wrappers with little original value, they misdeclare data collection, or they lack a working privacy policy. If your no-code app has real functionality beyond a template, it will pass. Add genuine features, original branding and honest Data safety answers before submitting.

Yes, but a plain WebView wrapper around a website is the single most-rejected app type under Google’s Minimum Functionality / repetitive-content policy. To pass, the app has to do something the browser cannot: push notifications, offline caching, native navigation, device features, or an account-bound experience. Wrap-and-ship is what gets rejected; a WebView shell with real native capability around it is published every day.

The app listing lives under the publishing partner's verified Google Play identity, while the code, brand and assets stay with whoever built them. That split is the whole reason a written agreement matters. A sound arrangement states four things in plain language: who holds the intellectual property, who controls the ad network accounts and therefore sees the revenue reports, how the app can be transferred out using Google's official app-transfer feature, and the notice period on either side. Google's app transfer moves a listing between developer accounts while keeping its installs, ratings and reviews — so a clean exit is genuinely possible when it is agreed in advance.

No — past a point, extra ads reduce total revenue by driving users away. Ad income is impressions multiplied by eCPM, but impressions depend on retention, and aggressive ad load is one of the top reasons users uninstall. Google Play also enforces this directly: ads that interrupt without warning, appear outside the app, or cover content are policy violations that get an app removed. The pattern that actually earns is fewer, better-placed ads at natural breaks — a session boundary, a level end, an opt-in reward — measured on revenue per daily active user over 30 days rather than impressions per session.

AdMob approval normally takes a few days, and the common rejection reasons are an app that is not yet publicly available, thin or placeholder content, and a mismatch between the account identity and the Play Console developer identity. Google reviews a new AdMob account against its publisher policies before serving live ads; until it clears, ad units return test or blank fills. Three things shorten the wait in practice: have the app actually live on Google Play (or in open testing) with real functionality rather than a shell, complete the payments profile with a name and address that match your Play developer identity, and make sure the app has a working privacy policy linked from the store listing. If an application is rejected, fix the substantive issue before re-applying — repeatedly re-submitting the same app does not help.

Because Google detects ad clicks or impressions it judges were not genuine user interest — most often the publisher clicking their own ads, asking friends to click, or traffic bought from a low-quality install source. Invalid traffic enforcement is automated and largely unappealable, and it usually arrives with the current period's earnings clawed back. The honest list of what triggers it: testing with live ad unit IDs instead of test ads, incentivising clicks (“tap the ad to support us”), placing ads where accidental taps are likely, and bot or emulator traffic from paid install campaigns. The protections are straightforward — always use Google's test ad unit IDs and registered test devices during development, never touch a live ad in your own app, keep ad placements clear of buttons, and buy installs only from sources you can audit.

Yes — if your app serves ads to users in the European Economic Area or the UK, Google requires you to gather consent through a Google-certified Consent Management Platform. In practice that means integrating Google's User Messaging Platform (UMP) SDK, or another certified CMP, and showing the consent form before requesting ads. The requirement came into force in January 2024 and is enforced at the ad-serving level: without a valid consent signal, ad requests from EEA and UK users are limited to non-personalised inventory or refused outright, which shows up as a sharp eCPM drop for European traffic. Setting it up is a one-off job — configure a GDPR message in the AdMob privacy and messaging section, add the UMP SDK, and request consent at app start before initialising the ads SDK. Apps aimed only at non-European markets still benefit from having it, because traffic mix changes.

Apps aimed at children may only use ad SDKs Google has certified for families, must not show interest-based or remarketing ads, and must keep ads clearly separated from app content. If your app targets children, or targets both children and adults, it falls under the Designed for Families requirements, and the ad rules are stricter than the general policy in four specific ways: only self-certified ad SDKs from Google's published list may serve, ads must be non-personalised, interstitials that are disruptive or appear before a child can understand them are prohibited, and the app must correctly set its target audience and child-directed treatment flags in both Play Console and AdMob. The commercial consequence matters: non-personalised inventory earns materially less, so a children's app typically has a lower ceiling on eCPM and is better served by a monetisation mix that does not depend on ads alone.

In a build-and-monetize partnership, the company that built the app carries that cost, not the publishing partner. That is the practical dividing line between this model and freelance app development: a freelancer hands over a finished app and moves on, leaving updates, crash fixes and policy compliance to whoever owns it; a monetization partner like ConsoleMint keeps the app on its own maintenance schedule for the app's whole life, because ongoing compliance directly protects the ad revenue the arrangement depends on — a suspended or policy-flagged app earns nothing for either side. A publishing partner should confirm, in writing, that maintenance and compliance costs sit with the company doing the building, not with them.

Scoped Developer-role access to the Google Play Console — never owner access, and never a password. Developer-role access lets ConsoleMint publish and update apps under the account without being able to change account ownership, remove the partner, or access anything outside Play Console app management. The partner keeps ownership of the account permanently and can revoke access at any time with 30 days' notice. This is the same access-scoping test worth applying to any similar arrangement: if a company asks for the account owner's password or full account credentials rather than scoped developer access, that is a red flag regardless of what it pays.

You can revoke ConsoleMint's Developer-role access to your Google Play account at any time, with 30 days' notice — the account was never transferred, so nothing needs to be handed back. Because ConsoleMint only ever holds scoped Developer-role access (never owner access, never a password), ending the arrangement is a permissions change, not an account transfer: you revoke access after the notice period and the account, with whatever apps remain published on it, stays yours throughout.

Yes — the partner owns the Google Play developer account permanently; ConsoleMint only ever holds scoped Developer-role access to it. There is no password handover and no ownership transfer, and the access can be revoked at any time with 30 days' notice. That design matters because Google ties a developer account to one verified owner: nothing about the arrangement asks the owner to give up control of their identity, their payments profile or the account itself. If the partnership ends, the partner revokes access and the account carries on exactly as before.

Grant the narrowest role that lets them release and manage store listings, never the account owner role, and never share the Google login itself. Google Play Console lets an account owner invite other users by email and assign specific permissions, so a publisher can be given release and store-listing rights without being able to change account ownership or manage other users. Keep financial data and user management with the owner unless there is a specific reason to share them, review the Users and permissions page periodically, and remove the invitation when the work ends. Permission names and groupings change over time, so check the current list in your own Console. ConsoleMint works on exactly this basis: Developer-role access only, never owner access, never a password, revocable with 30 days' notice.