admob-ads-diagnosis

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

AdMob 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.json
    android.package
    for Expo, or the applicationId in
    android/app/build.gradle
    ) must equal the package the
    google-services.json
    was created for (check
    package_name
    in the file, and the app ID
    ca-app-pub-XXXX~YYYY
    ).
  • App ID in the app config (Expo:
    app.json
    android.config.googleMobileAdsAppId
    or via the plugin) must equal the AdMob app ID (the
    ~
    form).
  • Unit IDs in the ads config file (e.g.
    lib/ads.ts
    ) must equal the ad unit IDs from the console (the
    /
    form), per platform and per format (banner/interstitial/rewarded/app open).
Wrong package or wrong
google-services.json
is a hard mismatch; wrong app ID or unit IDs also are. All four being right means config is fine — move to step 2.
对照用户的AdMob账户检查以下所有项:
  • 包名(Expo项目为
    app.json
    android.package
    ,或
    android/app/build.gradle
    中的applicationId)必须与生成
    google-services.json
    时使用的包名一致(可查看文件中的
    package_name
    ,以及应用ID
    ca-app-pub-XXXX~YYYY
    )。
  • 应用配置中的应用ID(Expo项目:
    app.json
    android.config.googleMobileAdsAppId
    或通过插件配置)必须与AdMob应用ID(含
    ~
    的格式)一致。
  • 广告配置文件(如
    lib/ads.ts
    )中的单元ID必须与控制台中的广告单元ID(含
    /
    的格式)一致,且需匹配对应平台和广告格式(横幅/插屏/激励式/开屏广告)。
包名错误或
google-services.json
不匹配属于严重错误;应用ID或单元ID错误也会导致问题。若以上四项均正确,则配置无问题——进入步骤2。

2. Read the actual error (adb logcat on the real device)

2. 查看实际错误信息(在真实设备上使用adb logcat)

Device must be connected (
adb devices
) and the app installed. Open the app and capture the ad errors:
bash
adb logcat | grep -iE "ads|admob|banner|interstitial"
The error code tells you which side is broken:
Error codeMeaningWhere the problem is
3
(
ERROR_CODE_NO_FILL
)
Ad request is valid; Google has no ad to serveAdMob account side — account not yet approved/active, or ad units not live. NOT a code bug
1
(
INVALID_REQUEST
)
Request malformedCheck unit ID + request setup
2
(
INVALID_AD_UNIT_ID
)
Unit ID wrongFix the ads config unit ID
4
(
NETWORK_ERROR
)
No networkDevice connectivity
NO_FILL
is the classic "real ads don't show" answer
: package, app ID and unit IDs are all correct and consent is passed (a banner that mounts and requests is proof consent gated correctly). The fix is in the AdMob console (account approval / ad unit status), not in code. New accounts take ~24h–2 weeks to start filling.
设备需已连接(执行
adb devices
确认)且应用已安装。打开应用并捕获广告相关错误:
bash
adb logcat | grep -iE "ads|admob|banner|interstitial"
错误代码可指明问题出在哪一端:
错误代码含义问题所在
3
(
ERROR_CODE_NO_FILL
)
广告请求有效;Google没有可投放的广告AdMob账户端——账户尚未获批/激活,或广告单元未上线。不是代码问题
1
(
INVALID_REQUEST
)
请求格式错误检查单元ID + 请求配置
2
(
INVALID_AD_UNIT_ID
)
单元ID错误修改广告配置中的单元ID
4
(
NETWORK_ERROR
)
无网络连接设备网络问题
NO_FILL
是「真实广告不显示」的典型原因
:包名、应用ID和单元ID均正确,且已完成授权校验(横幅广告能加载并发起请求即可证明授权校验配置正确)。修复需在AdMob控制台操作(账户审批/广告单元状态),无需修改代码。新账户通常需要24小时至2周才能开始投放广告。

3. 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.
TEST_ADS
in a config file). It decides everything:
  • TEST_ADS = true
    — 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 = false
    (production ship) — real unit IDs are used; the UMP consent flow (
    initializeAds
    gatherConsent
    ) 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.
If a user expects visible ads while
TEST_ADS = false
but the account is not approved, the result is NO_FILL (step 2). Switching back to
true
is a quick way to confirm the pipeline works end-to-end while the account is pending.
大多数应用通过标识(如配置文件中的
TEST_ADS
)控制真实广告与测试广告的切换,该标识决定所有广告行为:
  • TEST_ADS = true
    —— 所有广告格式在双平台均使用Google官方测试单元ID;UMP consent gate会被跳过(测试广告为非个性化广告,始终可投放,且AdMob不会因测试操作限制账户)。用于开发/验证阶段。
  • TEST_ADS = false
    (生产环境发布)—— 使用真实单元ID;UMP授权流程(
    initializeAds
    gatherConsent
    )会在EEA/UK地区限制广告请求。在非EEA设备(如越南地区设备)上,授权会自动通过,因此授权问题很少导致广告不显示。
若用户在
TEST_ADS = false
时期望显示广告,但账户未获批,结果会是NO_FILL(见步骤2)。在账户审批期间,切换回
true
可快速确认广告链路是否端到端正常。

4. If code actually needs changing

4. 仅在必要时修改代码

Only change code when step 2 shows an
INVALID_*
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.
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显示
INVALID_*
错误,或步骤1发现配置不匹配时,才需要修改代码。修改后:运行项目的类型检查 + 相关测试(通常会有锁定TEST_ADS为true/false路径的测试),然后重新构建应用。
完成标准:你可以依据证据(配置核对表 + logcat中的错误代码)明确说明问题是代码端(已修复)还是账户端(需在AdMob控制台操作,无法通过修改代码解决)。

Reference

参考资料

  • Google's official test ad unit IDs are documented in the AdMob docs; apps usually keep them in
    TEST_AD_UNIT_IDS
    next to the production IDs.
  • Consent re-review UI often lives in Settings when the UMP flow requires it.
  • Expo:
    google-services.json
    is usually committed, while the
    android/
    folder is NOT committed (regenerated by
    expo prebuild
    on every build).
  • Google官方测试广告单元ID可在AdMob文档中查看;应用通常会将其与生产环境ID一同存放在
    TEST_AD_UNIT_IDS
    中。
  • 当UMP流程要求时,授权重新审核界面通常位于设置页面。
  • Expo项目:
    google-services.json
    通常会提交到版本控制,而
    android/
    文件夹不会提交(每次构建时通过
    expo prebuild
    重新生成)。