admob-ads-diagnosis
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseAdMob ads diagnosis
AdMob广告诊断
When ads don't show, do not jump to editing code. The config is often
correct and the cause is account-side or environment-side. Debug in order.
当广告无法显示时,不要急于修改代码。配置通常是正确的,问题往往出在账户端或环境端。请按顺序进行调试。
Steps
步骤
1. Verify the config matches the AdMob console (2 min, no code change)
1. 验证配置与AdMob控制台一致(2分钟,无需修改代码)
Check all of these against the user's AdMob account:
- Package name (→
app.jsonfor Expo, or the applicationId inandroid.package) must equal the package theandroid/app/build.gradlewas created for (checkgoogle-services.jsonin the file, and the app IDpackage_name).ca-app-pub-XXXX~YYYY - App ID in the app config (Expo: →
app.jsonor via the plugin) must equal the AdMob app ID (theandroid.config.googleMobileAdsAppIdform).~ - Unit IDs in the ads config file (e.g. ) must equal the ad unit IDs from the console (the
lib/ads.tsform), per platform and per format (banner/interstitial/rewarded/app open)./
Wrong package or wrong is a hard mismatch; wrong app
ID or unit IDs also are. All four being right means config is fine — move to
step 2.
google-services.json对照用户的AdMob账户检查以下所有项:
- 包名(Expo项目为→
app.json,或android.package中的applicationId)必须与生成android/app/build.gradle时使用的包名一致(可查看文件中的google-services.json,以及应用IDpackage_name)。ca-app-pub-XXXX~YYYY - 应用配置中的应用ID(Expo项目:→
app.json或通过插件配置)必须与AdMob应用ID(含android.config.googleMobileAdsAppId的格式)一致。~ - 广告配置文件(如)中的单元ID必须与控制台中的广告单元ID(含
lib/ads.ts的格式)一致,且需匹配对应平台和广告格式(横幅/插屏/激励式/开屏广告)。/
包名错误或不匹配属于严重错误;应用ID或单元ID错误也会导致问题。若以上四项均正确,则配置无问题——进入步骤2。
google-services.json2. Read the actual error (adb logcat on the real device)
2. 查看实际错误信息(在真实设备上使用adb logcat)
Device must be connected () and the app installed. Open the app
and capture the ad errors:
adb devicesbash
adb logcat | grep -iE "ads|admob|banner|interstitial"The error code tells you which side is broken:
| Error code | Meaning | Where the problem is |
|---|---|---|
| Ad request is valid; Google has no ad to serve | AdMob account side — account not yet approved/active, or ad units not live. NOT a code bug |
| Request malformed | Check unit ID + request setup |
| Unit ID wrong | Fix the ads config unit ID |
| No network | Device connectivity |
NO_FILL设备需已连接(执行确认)且应用已安装。打开应用并捕获广告相关错误:
adb devicesbash
adb logcat | grep -iE "ads|admob|banner|interstitial"错误代码可指明问题出在哪一端:
| 错误代码 | 含义 | 问题所在 |
|---|---|---|
| 广告请求有效;Google没有可投放的广告 | AdMob账户端——账户尚未获批/激活,或广告单元未上线。不是代码问题 |
| 请求格式错误 | 检查单元ID + 请求配置 |
| 单元ID错误 | 修改广告配置中的单元ID |
| 无网络连接 | 设备网络问题 |
NO_FILL3. Check the TEST_ADS flag and consent gate
3. 检查TEST_ADS标识与UMP consent gate
Most apps gate real vs test ads with a flag (e.g. in a config
file). It decides everything:
TEST_ADS- — every format uses Google's official test unit IDs on both platforms; the UMP consent gate is skipped (test ads are non-personalized, they always fill, and AdMob never limits the account for test activity). Use this for dev/verification.
TEST_ADS = true - (production ship) — real unit IDs are used; the UMP consent flow (
TEST_ADS = false→initializeAds) gates ad requests on EEA/UK. On a non-EEA device (e.g. VN) consent auto-passes, so consent is rarely the cause of missing ads.gatherConsent
If a user expects visible ads while but the account is not
approved, the result is NO_FILL (step 2). Switching back to is a quick
way to confirm the pipeline works end-to-end while the account is pending.
TEST_ADS = falsetrue大多数应用通过标识(如配置文件中的)控制真实广告与测试广告的切换,该标识决定所有广告行为:
TEST_ADS- —— 所有广告格式在双平台均使用Google官方测试单元ID;UMP consent gate会被跳过(测试广告为非个性化广告,始终可投放,且AdMob不会因测试操作限制账户)。用于开发/验证阶段。
TEST_ADS = true - (生产环境发布)—— 使用真实单元ID;UMP授权流程(
TEST_ADS = false→initializeAds)会在EEA/UK地区限制广告请求。在非EEA设备(如越南地区设备)上,授权会自动通过,因此授权问题很少导致广告不显示。gatherConsent
若用户在时期望显示广告,但账户未获批,结果会是NO_FILL(见步骤2)。在账户审批期间,切换回可快速确认广告链路是否端到端正常。
TEST_ADS = falsetrue4. If code actually needs changing
4. 仅在必要时修改代码
Only change code when step 2 shows an error or step 1 shows a
mismatch. After any change: run the project's typecheck + relevant tests
(tests that lock the TEST_ADS true/false paths are common), then rebuild the
app.
INVALID_*Completion criterion: you can state, with evidence (config table + error
code from logcat), whether the problem is code-side (fixed) or account-side
(AdMob console action needed, no code change possible).
仅当步骤2显示错误,或步骤1发现配置不匹配时,才需要修改代码。修改后:运行项目的类型检查 + 相关测试(通常会有锁定TEST_ADS为true/false路径的测试),然后重新构建应用。
INVALID_*完成标准:你可以依据证据(配置核对表 + logcat中的错误代码)明确说明问题是代码端(已修复)还是账户端(需在AdMob控制台操作,无法通过修改代码解决)。
Reference
参考资料
- Google's official test ad unit IDs are documented in the AdMob docs; apps
usually keep them in next to the production IDs.
TEST_AD_UNIT_IDS - Consent re-review UI often lives in Settings when the UMP flow requires it.
- Expo: is usually committed, while the
google-services.jsonfolder is NOT committed (regenerated byandroid/on every build).expo prebuild
- Google官方测试广告单元ID可在AdMob文档中查看;应用通常会将其与生产环境ID一同存放在中。
TEST_AD_UNIT_IDS - 当UMP流程要求时,授权重新审核界面通常位于设置页面。
- Expo项目:通常会提交到版本控制,而
google-services.json文件夹不会提交(每次构建时通过android/重新生成)。expo prebuild