Google Play disruptive ads rejection: interstitials, unexpected ads and ads outside the app

Google has found an ad in your app that a user did not ask for, could not get rid of, or could not tell was an ad. The Ads policy is enforced heavily and often lands as a removal rather than a rejection, because the ads only misbehave once the app is live and monetising.

How the rejection is worded

Almost always a policy email, and it usually names the sub-policy. Common shapes:

"Your app contains ads that interfere with the app's usability or the use of the device."

"We found full-screen interstitial ads that appear unexpectedly, interrupting normal use of the app."

"Your app displays ads outside of the app's own interface."

"Your app contains ads that mislead users, including ads that mimic system notifications or warnings."

Two systems can act on this independently, and confusing them wastes days. Play enforces the Developer Program Policies and can reject, remove or suspend your app. AdMob or your ad network enforces its own publisher policies and can stop serving ads or suspend the ad account. An email from one does not mean the other has acted, and fixing one does not clear the other.

What it means

Play's Ads policy governs the ads inside your app regardless of whose network serves them. You are responsible for what your mediation stack does, including creatives you have never seen. The parts that generate rejections:

Disruptive ads. Full-screen interstitials that appear when the user has chosen to do something else, starting a level, tapping a menu item, returning from the background, are prohibited. So are interstitials served during gameplay rather than at a natural break, and interstitials the user cannot dismiss. Play has historically required that a full-screen ad be closeable, with unskippable video limited in length.

Ads outside the app. Ads shown when your app is not in the foreground, on the home screen, over another app, in the notification shade, or on the lock screen, are not permitted unless that is the app's declared purpose and the user consented.

Deceptive ads. Ads that look like system warnings, battery or virus alerts, missed-call or message notifications, or part of your own interface. Fake close buttons and close buttons placed where a tap will register on the ad instead are the classic version.

Ads context. The user must be able to tell an ad from content. Ads inserted into a feed, a results list or a settings screen without labelling fail this.

Ad placement and interference. Ads placed over navigation controls, over a game's action area, or immediately where a user is about to tap.

Inappropriate ads. Ad content must suit the app's declared audience. This is where the Ads policy meets the Families policy, and where mediation networks most often cause trouble.

Why it happens

• An interstitial fires on app open or on level start. The single most common trigger, and often a deliberate revenue decision that someone made two years ago.
• A network in the mediation chain serves a creative you never approved: a fake system alert, an auto-redirect, or an ad that opens the Play Store without a tap.
• The close button is small, delayed, or off-screen on some device sizes. Test on a small screen and a tablet, not just your own phone.
• Ad frequency capping is absent, so a user who backgrounds and returns sees an ad every time.
• A banner sits over the bottom navigation bar on devices with gesture navigation or a different aspect ratio.
• The app posts ads in notifications: including "re-engagement" pushes that are really adverts.
• Rewarded ads without a genuine opt-in. Rewarded formats are fine; presenting one as unavoidable is not.

How to fix it

1. Reproduce it before you change anything. Install the released build from Play on a real device, use it as a user would for ten minutes, and record the screen. Most developers cannot say where their own interstitials fire because the placement lives in a config the ad network controls.
2. Move every interstitial to a natural break. Between levels, after a completed task, on returning to a menu, never on launch, never when the user has just tapped something else, never mid-action.
3. Make dismissal obvious and immediate. A visible close control that works on the smallest supported screen, with enough padding that a near-miss does not open the ad.
4. Cap frequency and add cooldowns. A session limit and a minimum interval between full-screen ads, enforced in your own code rather than trusted to the network.
5. Kill anything that renders outside your app. No overlays, no lock-screen placements, no notification ads.
6. Audit the mediation chain. List every network that can fill an impression, check what creative types each is allowed to serve, and disable formats you cannot supervise. If a network keeps serving deceptive creatives, remove it. Google will hold you responsible, not them.
7. Label ads clearly wherever they sit next to content, and keep them out of your own controls.
8. Match ads to the audience. If the app is directed at children, the Families rules apply on top of everything here: certified SDK, no personalised advertising.
9. Retest on a small phone and a tablet before you resubmit. Placement bugs are usually layout bugs.

Appeal, or fix and resubmit?

The Ads policy tends to produce removals rather than rejections, because the behaviour only shows up in a live app. Know which one you got:

• Rejected: the release did not publish. Fix the placement, upload a new release.
• Removed: the app is off Play; users who already have it keep it. Fix and submit an update.
• Suspended: off Play and recorded against your developer account, which matters for everything else you publish.

Appeals go through the form linked in the policy email or the app's Policy status page in Play Console.

Appeal when the ad was not yours to control and you have already cut it off. If a mediation partner served a deceptive creative, say which network, which creative, when you disabled it, and what you changed so it cannot recur. That is a factual account, and it is the version of this appeal that works.

Do not appeal a placement you chose. If an interstitial fires on launch because launch-time interstitials pay well, Google knows exactly what it is looking at. Move it and ship.

One more thing worth saying plainly: ads violations are treated as a pattern. Google sees the same behaviour across your catalogue, and a developer with several ad-heavy apps that each pick up a finding is heading for account-level enforcement rather than another app removal. If one app got caught, check the others this week.

What to send

The interstitial that appeared on app launch has been removed; full-screen ads now appear only after a completed session, with a minimum interval of [X] seconds and a per-session cap. Every full-screen placement has a visible close control from the first frame, verified on the smallest supported screen. We have disabled [network] in our mediation configuration after identifying the creative described, and no ad is rendered outside the app in any state. A screen recording of the current build is at [link].

If you want the email read back to you in plain English before you start, AppSubmit's rejection explainer separates the sub-policy actually cited from the boilerplate and orders the fixes by effort, the ad configuration itself still lives in your network's dashboard.