⬡ Dev Tools/2026-04-07Advanced

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

When a Rork-generated Expo app gets held up on Google Play, the cause is usually a permission you never wrote. Here's how to pin down what actually landed in your merged manifest, when to declare AD_ID versus strip it, and how to keep the 12-tester closed test from resetting on you.

Google Play²⁷ Android⁴⁶ Rork⁵³⁹ Expo¹⁷⁵ AD_ID permissions⁷ app review³

✦ Premium Article

Just after 10pm, an email arrived from Play Console. Subject line: "Policy issue."

The body doesn't tell you which file, or which line. It gives you a policy clause and a link.

When you ship apps as a solo developer, that one email eats your evening. The first few times, I spent most of that evening clicking around Play Console without getting any closer to an answer.

What eventually became clear is that Rork-generated Expo apps stall on Google Play in a fairly small number of places. And most of those places are things you never wrote yourself.

The notification tells you the verdict, not the location

The first thing worth internalizing: the email and the Play Console banner are the outcome, not the cause.

There are two places to look:

Google Play Console → [Your app] → Policy and programs → App content
Google Play Console → [Your app] → Policy and programs → Policy status

The part that matters is this: always open the linked policy clause. The email summary is too compressed to tell you which condition you actually tripped. The linked page spells out the qualifying conditions and the exceptions.

The habit I've settled into is to open that page and write down, in one sentence, the specific condition my app was judged to meet.

❌ "Violated the ads policy"
⭕ "Showed a full-screen ad during a screen transition the user hadn't initiated"

Until you can write the second version, you haven't found the cause yet. Start fixing before that sentence exists and you'll ship a change that misses, then hit the same clause on resubmission.

The permission list in app.json doesn't subtract anything

Permissions are far and away the most common stall for Rork-generated Expo apps. And there's a structural misunderstanding sitting underneath it.

The instinct is to trim android.permissions in app.json and expect the permission count to drop. That isn't how it works.

// app.json — this declares what to ADD. It is not a removal list.
{
  "expo": {
    "android": {
      "permissions": ["INTERNET", "VIBRATE"]
    }
  }
}

In an Expo build, your dependencies each ship their own AndroidManifest.xml or config plugin, and those get merged at build time. Permissions that arrive through the merge are unaffected by shortening your permissions array.

Removal is a separate directive:

// app.json — explicitly strip permissions injected by libraries
{
  "expo": {
    "android": {
      "permissions": ["INTERNET", "VIBRATE"],
      "blockedPermissions": [
        "android.permission.RECORD_AUDIO",
        "android.permission.ACCESS_FINE_LOCATION",
        "com.google.android.gms.permission.AD_ID"
      ]
    }
  }
}

blockedPermissions applies tools:node="remove" during the merge. The detail that bites people: use fully qualified names, not the short form. The permissions array happily accepts "RECORD_AUDIO", but blockedPermissions won't match anything unless you write "android.permission.RECORD_AUDIO" in full. This fails silently, which is the worst way for it to fail.

Find out who injected it — don't guess

Before removing anything, establish what's actually there. Listing guesses in blockedPermissions just burns time when they don't match.

Gradle's manifest merger leaves a full trace of the merge:

npx expo prebuild -p android
cd android && ./gradlew :app:processReleaseManifest
 
# Line-by-line record of which library injected which permission
grep -n "AD_ID" app/build/outputs/logs/manifest-merger-release-report.txt

The report gives you entries like ADDED from [com.google.android.gms:play-services-ads:...] AndroidManifest.xml:26:5-84 — the injecting library and the line number. Only once you can see that can you decide whether the permission should stay or go.

You can also verify from the artifact side:

# Inspect what actually got baked into the thing you're shipping
bundletool build-apks --bundle=app-release.aab --output=app.apks --mode=universal
unzip -o app.apks -d apks_out
aapt2 dump permissions apks_out/universal.apk

I run this before every resubmission. Having fixed the config and having the artifact reflect that fix are two different facts. I've had an EAS Build cache serve me a binary where my blockedPermissions change simply wasn't there.

What you want to know	Where to look	What it tells you
Permissions you declared	`android/app/src/main/AndroidManifest.xml`	Your own app's entries, post-prebuild
Who injected what	`manifest-merger-release-report.txt`	Source library and line number
What actually shipped	`aapt2 dump permissions` on the AAB	The real contents of the artifact

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A procedure for pinning down permissions that app.json cannot remove, using blockedPermissions and the manifest merger report

✦A decision table for when to declare AD_ID and when to strip it, keyed to target age and the Families policy

✦How to run the 12-tester, 14-day closed test required of new personal accounts without resetting the count

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

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.

Target audience	Ads	AD_ID	What else is required
13+ only	AdMob	Declare it	Disclose "Device or other IDs" in Data safety
Includes children (Families)	AdMob	Strip it	Tag for child-directed treatment; GMA SDK 20.6.0 or later
Children only	No ads	Strip it	Target API level 33+; cut off library-side injection too
13+ only	No ads	Strip it	Check whether an analytics SDK dragged it in

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.

Situation	Applies?	What's required
Personal account created on/after 2023-11-13	Yes	12+ testers, opted in for 14 consecutive days
Personal account created before that	No	Standard submission flow
Organization account with a legal entity	No	Standard submission flow

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.

Which clause, when, which version (include the version code)
What you changed, specifically (setting names, file names, values)
How you verified the change took (the relevant merger report line, aapt2 dump output)
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.

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.
Confirm the AD_ID direction matches your target audience. Declare or strip — make sure you haven't stepped the wrong way.
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.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.