Prepare a controlled test session
Use a supported SDK version and a registered test device as required by the selected integration. Open Ad Inspector through the documented gesture or API for that SDK family. Keep the build version and test-device configuration in the diagnostic record.
Do not expose a debug-only inspector control to ordinary users without a product reason. Never test by generating clicks on live inventory.
Inspect the layers in order
| Layer | What to investigate |
|---|---|
| SDK initialization | Correct SDK family, app ID and lifecycle |
| Adapter integration | Missing, incompatible or uninitialized adapters |
| Ad request | Unit, format, response and error information |
| Individual source | Supported test setup and source-specific response |
| Full mediation | Behavior after the isolated integrations work |
A missing adapter is actionable in the build. An account-side mapping error requires the relevant dashboard configuration. A no-fill result is not automatically either of those.
Reproduce the user path
Run the consent flow and navigate to the actual placement before inspecting the request. A debug button that loads a different ad unit can prove the wrong integration works.
Record timestamps, SDK/adapter versions and sanitized error details. Avoid placing raw user identifiers or sensitive response data in public tickets.
Compare test and production cautiously
Demo ads can validate rendering and callbacks without testing your production account. Test-device requests with your own units add a different layer of evidence. Neither makes every region, time or partner inventory condition identical.
For intermittent failures, correlate the inspector findings with network state and lifecycle transitions. Repeated immediate retries can make the original problem harder to see.
APKLint's SDK detector helps identify packaged libraries but cannot open Ad Inspector inside your app. Use the official inspector guide and test-ad instructions to build a repeatable diagnostic sequence instead of treating one successful ad as a complete integration audit.
Connect the inspector result to one reproducible request
Start with a registered test device and one known test placement. Open the screen that requests the ad, reproduce the failure once and then inspect that request's details. Record the SDK version, ad format and relevant error category. A screenshot of a healthy adapter list from another session does not explain why this particular request failed.
The Ad Inspector guide describes its test-device requirement and diagnostic capabilities. Keep the distinction between launching the inspector successfully and observing a successful ad request. The inspector is a diagnostic interface, not a certificate that the account, application or every placement is ready for production traffic.
Change one suspected cause at a time
Suppose a banner works with a Google demo unit but fails through a mediated test placement. First preserve both request records. Compare whether the intended adapter was present, initialized and eligible for the requested format. Then inspect that partner's configuration and test instructions. Replacing several adapters and the core SDK simultaneously makes it difficult to identify which change affected the outcome.
If the inspector reports an adapter integration problem, compare its observation with the dependencies resolved into the actual installed artifact. An adapter declared in the build file can resolve differently through dependency constraints. Reinstall the newly built test artifact after changing it; clearing the screen alone does not replace the native libraries already installed on the device.
Use a privacy-state test separately from an adapter-version test. Document the consent branch and audience configuration used for the request, then repeat the intended alternate branch with supported testing controls. Do not interpret an unavailable ad source as proof that the consent interface was displayed or that a particular user choice was honored.
When sharing diagnostics with another developer, include the reproduction steps and selected request details while removing account credentials and unrelated user information. Retain the earlier failing observation as well as the later successful one. That comparison shows what changed and prevents a later integration regression from being dismissed because the inspector happened to open without an error.
Sources and further reading
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
