Where Rork Apps Stall on Google Play — AD_ID Leakage, Manifest Merging, and the 12-Tester Closed Test

AD_ID stalls you both by omission and by contamination

The advertising ID permission is a special case, because it has two directions and stepping the wrong way stalls you either way.

Apps targeting Android 13 or above that use the advertising ID must declare com.google.android.gms.permission.AD_ID. If you don't declare it and request the ID anyway, you don't get an error — you get a string of zeros. Nothing throws. You find out when revenue drops.

For apps whose audience includes children, the direction reverses. Google Play's Families policy requires that identifiers including the advertising ID not be transmitted for children or users of unknown age. Here, AD_ID must not be declared at all.

Child-directed tagging has to be set once, before any ad request goes out:

// ads/configure.ts
// Call before requesting ads. Setting this later won't retroactively affect in-flight requests.
import mobileAds, { MaxAdContentRating } from "react-native-google-mobile-ads";
 
export async function configureAdsForFamilies() {
  await mobileAds().setRequestConfiguration({
    maxAdContentRating: MaxAdContentRating.G,
    tagForChildDirectedTreatment: true,  // treat as COPPA-covered
    tagForUnderAgeOfConsent: true,       // treat as below the age of consent
  });
 
  await mobileAds().initialize();
}

Catching the zero-fill before your revenue tells you

What makes the missing declaration nasty is that it fails quietly. The advertising ID lookup appears to succeed, and the value you get back is 00000000-0000-0000-0000-000000000000.

The consequence is that you drop out of personalized ad targeting. Inventory narrows to non-personalized only, and eCPM falls with it. On one of my ad-supported apps, comparing a release that shipped with the declaration missing against the corrected build over a matched set of weekdays, the eCPM gap was roughly 30–40%. That number will move with your app's composition and regional mix, so don't transplant it directly — but it isn't a rounding error either.

The problem is that this decline never surfaces as a crash or an error log. You find out days later, looking at a revenue dashboard.

So I check the shape of the value once at startup:

// ads/verifyAdId.ts
// A zero-filled ID throws nothing. Go look for it yourself.
 
const ZERO_AAID = "00000000-0000-0000-0000-000000000000";
 
export function isAdIdZeroed(advertisingId: string | null): boolean {
  if (!advertisingId) return true;
  return advertisingId === ZERO_AAID;
}
 
// Usage (warn on development builds only)
// if (__DEV__ && isAdIdZeroed(await getAdvertisingId())) {
//   console.warn("[ads] AAID is zero-filled. Check the AD_ID declaration and your target API level.");
// }

A user who resets their advertising ID produces the same value, so this alone doesn't prove a missing declaration. Confirm the declaration in the merger report first; treat this as an early-warning net rather than a diagnosis. And if you're deliberately stripping AD_ID for a children's audience, zero-filled is the correct state — the check isn't needed at all.

When you stripped it from the manifest and the violation persists

This is the nastiest variant. You block AD_ID, confirm in the merger report that it's gone — and the resubmission still comes back as a Families policy violation.

The cause is usually an SDK reaching for the advertising ID through reflection, bypassing the permission declaration entirely. Nothing shows up in the manifest, so no amount of permission auditing will surface it.

At that point you have to work from the dependency tree:

# Surface dependencies that might be touching advertising ID APIs
cd android && ./gradlew :app:dependencies --configuration releaseRuntimeClasspath > deps.txt
grep -iE "ads|advertis|analytics|attribution|facebook|appsflyer" deps.txt

From there it's an unglamorous loop: pull one suspect SDK, rebuild, push to internal testing, observe. I lost a full day to this once. The ordering that tends to pay off is ads first, then measurement, then social login SDKs.

If it's the Data safety form itself that's blocking you rather than the permission, I've put the SDK-by-SDK disclosure mapping in fixing a Google Play rejection for an incomplete Data safety section.

When it's the ad presentation that trips the clause

Permissions can be perfect and the presentation can still stall you. The recurring shapes:

• A full-screen ad appears mid-transition, before the user has initiated anything
• The close button is small, or sits outside the ad's own bounds
• An ad sits directly beneath an action button, inviting mistaps
• No visual boundary between ad and content

It's tempting to add a frequency cap and call it done. But the clause is less concerned with frequency than with unexpected timing. Adding a don't-show-during-transitions condition on top of the interval moves you to the safe side.

// ads/interstitialGate.ts
// Gate on "the user just finished an action", not only on "enough time has passed".
 
const AD_MIN_INTERVAL_MS = 60_000;
 
let lastShownAt = 0;
let isNavigating = false;
 
export function markNavigationStart() {
  isNavigating = true;
}
 
export function markNavigationEnd() {
  isNavigating = false;
}
 
export function canShowInterstitial(): boolean {
  // During a transition, the user's intended tap target and the ad's overlap
  if (isNavigating) return false;
 
  return Date.now() - lastShownAt >= AD_MIN_INTERVAL_MS;
}
 
export function notifyInterstitialShown() {
  lastShownAt = Date.now();
}

The reason to exclude transitions specifically: when a full-screen ad lands at the tail of a transition animation, the ad's button slides into the spot the user was already reaching for. You can be well within your frequency cap and still be judged to be inviting mistaps on that basis alone.

For close buttons, I work to 48dp minimum size and 48dp minimum separation from other interactive elements. You can't touch what AdMob renders itself, but the surrounding layout is yours.

12 testers, 14 days — the closed test for new personal accounts

This isn't a policy violation, but it's an increasingly common reason nothing moves.

Personal developer accounts created on or after November 13, 2023 must run a closed test before applying for production access. The requirement: at least 12 testers, opted in continuously for at least 14 days.

It was originally 20 testers; that dropped to 12 on December 11, 2024. Plenty of articles still say 20, so check the date on anything you read. Organization accounts registered to a legal business entity are exempt.

What I learned running it is that the hard part isn't the headcount — it's the continuity.

• A tester opening the link doesn't count. They have to reach an actual install from the Play Store.
• If even one drops off, the day count gets shaky
• Count the 14 days from "12 testers are in place and staying", not from "testing started"

I ended up recruiting 15–16 people for margin, and checking on day 3 and day 10 that the installs were still present. I under-thought this once, came up short on day 14, and started the count over.

The test window isn't dead time, either. The Pre-launch Report runs your app on real devices and hands you the results. Permission errors and crashes surface there, so spending the 14 days on verification cuts down on production-track bounces.

Write appeals in the language of the clause

If the enforcement doesn't lift after your fix, or if it's a clear false positive, file an appeal.

There's a shape that works. No emotion, aligned to the clause's own vocabulary, facts only.

1. Which clause, when, which version (include the version code)
2. What you changed, specifically (setting names, file names, values)
3. How you verified the change took (the relevant merger report line, aapt2 dump output)
4. If you believe it's a false positive, why (the gap between the clause's qualifying conditions and your app's actual state)

"We've addressed this" and "this should be fine now" hand the reviewer nothing to act on, and you get the same answer back. Item three is what changes the quality of the reply. A few lines of pasted output is enough.

The three things I run before every resubmission

Checklists get shorter the longer you run this. Mine is down to three.

1. Run aapt2 dump permissions against the AAB and look at the list with your own eyes. Fixing the config and shipping the fix are separate facts.
2. Confirm the AD_ID direction matches your target audience. Declare or strip — make sure you haven't stepped the wrong way.
3. Push to the internal testing track before the production track. It takes minutes and the policy pre-checks run.

If you're going to do one thing next, do the first. Run aapt2 dump permissions against your most recent AAB. Anything in that list you don't remember asking for is a candidate for your next rejection.

I still misread merger reports from time to time. I don't have a perfect process here — but I've stopped breaking the one rule that matters: locate the cause before touching the fix.