How to add AdMob to an Android app correctly — and the single mistake that can stall an entire account's approval.
AdMob integration looks simple on paper: add the SDK, create an ad unit, show an ad. In practice, most of the problems developers run into aren't technical — they're policy and configuration mistakes that are easy to make and hard to notice until an app gets stuck in review.
Create your AdMob account and link it to the Play Console app entry first. Confirm your account is fully verified — a pending or unverified account will block ad serving regardless of how correct your code is.
Create separate ad units for each ad format you plan to use (banner, interstitial, rewarded, etc.). Each ad unit has its own ID, and that ID is what goes into your production build.
This is worth calling out on its own, because it's a genuinely common and quiet failure: during development, it's normal to use Google's official test ad unit IDs so you can see sample ads without risking policy violations from clicking your own live ads. The problem is when that test ID is never swapped out before the app is published. The app runs fine, ads show up fine in testing — but the live production build is still serving test ads, which stalls AdMob's review of the account entirely, often without an obvious error message pointing at the cause. Before any release build, explicitly check every ad unit ID against your AdMob dashboard, not just your memory of having "already changed it."
Google's AdMob and Play policies restrict where and how ads can appear — no ads that overlap navigation controls, no ads placed to cause accidental clicks, and no full-screen ads shown without a clear way to close them. Review the current AdMob policies before finalizing placement, since these rules are updated periodically.
Once test IDs are replaced with production IDs, test again. Ads can take some time to start serving on a brand-new ad unit, so don't mistake an empty ad slot immediately after switching IDs for a broken integration.
An interstitial ad that interrupts a core action (like skipping a song mid-playback) creates a worse user experience and a higher risk of accidental clicks, which policies specifically discourage. Placing ads at natural breakpoints — between levels in a game, or when returning to a home screen — tends to perform better and cause fewer issues.
If your app serves ads, your privacy policy needs to reflect that, including any data collection used for ad personalization. This is checked as part of Play Store review, not just AdMob's own review.
This is frequently caused by exactly the issue above — a published app still using a test ad unit ID instead of a real production ID. Double-check every ad unit ID in your live build against your AdMob dashboard.
One per ad format actually used in the app (e.g., one banner unit, one interstitial unit). Don't create more than you need — it adds confusion without benefit.
No — this violates AdMob policy and can get an account suspended. Always use official test ad unit IDs for development and testing.