Choose one documented SDK path
As checked on 29 September 2026, the setup pages show these dependency examples:
// Legacy SDK path:
implementation("com.google.android.gms:play-services-ads:25.5.0")
// Next-Gen path — an alternative, not an extra dependency:
implementation("com.google.android.libraries.ads.mobile.sdk:ads-mobile-sdk:1.5.0")
These are dated examples, not instructions to add both. Check migration and mediation support for your required networks before changing families.
Keep initialization and identifiers aligned
The legacy setup uses the com.google.android.gms.ads.APPLICATION_ID manifest metadata. The Next-Gen setup supplies the app ID through InitializationConfig and requires initialization on a background thread before most SDK interactions.
Do not move a legacy ad-unit ID into the Next-Gen app-ID field. App IDs contain a tilde; ad-unit IDs contain a slash.
Follow the selected SDK's lifecycle and callback guidance. For mediation, verify when the relevant adapters are ready rather than assuming all partner initialization has finished after the first method returns.
Apply privacy and audience configuration first
SDKs or partners may preload during initialization. Complete the required consent handling and set applicable audience/request controls before triggering collection or ad loading. A consent form shown after initialization is not automatically equivalent.
Use official demo ad units or configured test devices. Never click production ads to test callbacks.
Diagnose in layers
Check dependency resolution, app ID, initialization, ad format, request error details and adapter state in that order. “No fill” and a missing application ID are not the same class of problem.
APKLint's advertising and SDK tools can help inspect manifest and dependency signals. They do not connect to your AdMob account or prove that inventory will be available.
Use the legacy setup, Next-Gen setup and SDK disclosure reference for the chosen integration. Recheck versions and supported adapters before a later release instead of treating this dated dependency example as permanently current.
Follow one build variant from dependency to first test request
Consider an app with development and production variants. Give the development variant its own explicit advertising configuration and inspect the artifact produced for that variant. A value in a source manifest is insufficient when placeholders, a flavor manifest or an imported library can change the merged result. Record the resolved SDK coordinate alongside the application ID used by the installed build.
The legacy setup and Next-Gen setup describe different integration paths. Select one before implementing initialization. A migration should replace the old dependency and API usage deliberately; adding the second SDK while retaining the first does not constitute a completed migration.
Separate initialization from a successful ad load
Instrument three development events: initialization requested, initialization callback received and test-ad load completed. Keep a separate failure record for each stage. If initialization completes but the request fails, investigate the request's error and response information instead of repeatedly changing the manifest app ID. Conversely, a missing initialization callback is not explained by a banner being too small to see.
Use one process-level owner for the initialization transition. Rotate the activity and reopen the screen during startup to check that two screens cannot each start an independent initialization sequence. Make the screen subscribe to the owner's current state, and avoid retaining a destroyed activity as the permanent owner merely because it initiated the first request.
For a migration comparison, retain two separate test builds with their dependency inventories. Exercise the same supported ad format, device and test configuration in each. Compare startup errors and callback behavior, then investigate differences with the relevant SDK documentation. Do not attribute a change to the new SDK when the experiment also changed the ad unit, mediation setup and consent branch.
Finally, install the optimized release variant on a test device and repeat the request. Preserve the artifact hash and non-sensitive error information with that result. This checks the delivered dependency and configuration path; a successful development build alone cannot establish that release resource merging and optimization preserved the integration.
Sources and further reading
- Google: Legacy Google Mobile Ads SDK setup
- Google: Mobile Ads SDK data disclosure
- Google Mobile Ads: Next-Gen Android SDK setup
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
