Three conditions that make Play Policy Insights report nothing on an Expo project

Condition 2: Expo's default Gradle shape hides your target SDK

Google Play requires target API level 36 or higher starting August 31, 2026 — listed under Reminders in that same July announcement. Target SDK is the first thing you want a pre-submission check to confirm.

It is also the thing that came back null. I fed four Gradle styles directly into parse_application_modules to find the boundary.

The cause is the variable reference. The skill resolves gradle.properties entries and version catalog entries, but it does not follow values declared in the ext { } block of android/build.gradle — which is exactly where Expo prebuild puts them. So target_sdk stays null in manifest_details.json and travels that way into every downstream prompt.

applicationId fared no better: three of the four styles failed to resolve it. When resolution fails, package_name falls back to the name field in package.json. In my reproduction the recorded package name was wallpaper-demo, which is not a package name at all.

With a deadline in sight, two nulls in the report means you checked without checking. Resolve the effective values yourself before you run anything.

#!/usr/bin/env bash
# preflight.sh — verify the entry point before running Play Policy Insights
# usage: ./preflight.sh /path/to/expo-project
set -euo pipefail
ROOT="${1:?pass the project root}"
 
# 1) Scan root sanity: is package.json actually here?
if [ ! -f "$ROOT/package.json" ]; then
  echo "FAIL: no package.json in $ROOT — hybrid detection will not fire and JS will be skipped."
  echo "      Point the tool at the repository root instead."
  exit 1
fi
echo "OK: scan root = $ROOT"
 
# 2) Effective targetSdk: a variable reference reads as null to the skill
GRADLE="$ROOT/android/app/build.gradle"
if [ -f "$GRADLE" ]; then
  LINE=$(grep -E '^\s*targetSdk(Version)?\s' "$GRADLE" || true)
  if echo "$LINE" | grep -qE 'targetSdk(Version)?\s+[0-9]+'; then
    echo "OK: targetSdk is a literal -> ${LINE//[[:space:]]/ }"
  else
    EXT=$(grep -E 'targetSdkVersion\s*=\s*[0-9]+' "$ROOT/android/build.gradle" 2>/dev/null | head -1 || true)
    echo "WARN: targetSdk is a variable reference; the skill will report null."
    echo "      Value declared in ext: ${EXT:-not found}"
  fi
else
  echo "WARN: no android/ directory (managed workflow). Confirm targetSdk from app.json."
fi

Managed-workflow projects have no Gradle files at all, so the skill says nothing about target API level. Teams that ship builder output as-is are the most likely to read that silence as approval. For pulling the value the build actually uses rather than the value you declared, I wrote up the procedure separately in the three places I had to fix to reach targetSdkVersion 36.

Condition 3: node_modules is excluded from the scan

node_modules sits in ignored_directories in scanner_config.json, alongside .git and build. Reasonable for scan speed. Consequential for Expo and Rork projects.

What usually creates a Data safety obligation is not the code you wrote — it is what your dependencies collect on their own. When I reviewed declarations across the two Android and four iOS apps I run, the additions that mattered were the AdMob advertising ID and the crash logs Crashlytics transmits. Neither appears in my source as a getAdvertisingId() call. Both start the moment the SDK initializes.

So the bulk of the declaration surface sits outside the scanner's reach. That part has to be inventoried by hand, from the dependency list.

# Inventory collection-capable SDKs — surface declaration candidates from deps
node -e '
const pkg = require("./package.json");
const deps = Object.keys({...pkg.dependencies, ...pkg.devDependencies});
const rules = [
  [/google-mobile-ads|admob|applovin|unity-ads|inmobi|liftoff/i, "Advertising ID, approximate location"],
  [/crashlytics|sentry|bugsnag/i,                                "Crash logs, diagnostics"],
  [/analytics|amplitude|mixpanel|firebase\/app$/i,               "App interactions, diagnostics"],
  [/expo-location|geolocation/i,                                 "Location"],
  [/image-picker|expo-media-library|camera/i,                    "Photos and videos"],
  [/purchases|revenuecat|iap|billing/i,                          "Purchase history"],
];
const hits = [];
for (const d of deps) for (const [re, label] of rules) if (re.test(d)) hits.push([d, label]);
if (!hits.length) { console.log("No collection-capable dependencies matched"); process.exit(0); }
console.log("Dependencies that may require a Data safety declaration:");
for (const [d, label] of hits) console.log(`  ${d.padEnd(42)} -> ${label}`);
'

These are candidates, not conclusions — confirm against each SDK's own documentation. Even so, mechanically surfacing "present in dependencies, absent from the declaration" removes most of the oversights.

And it over-reports in the other direction

Even when the scan does reach your code, do not transcribe its output into Play Console. Here is what the minimal project produced.

MUSIC fired on the analytics endpoint https://api.example.com/v1/track. The configuration registers track as a MUSIC keyword. Anyone who names their analytics helper trackEvent will hit this on the first run.

PHOTOS and VIDEOS fired purely because expo-image-picker appears in package.json. No call site exists. Generated projects routinely carry dependencies they never use, so this class of over-report is the normal case, not the edge case.

Simultaneous over-reporting and structural blindness is simply what static scanning is. I treat the output as a list of places to look, not as a draft declaration. Open the cited file, decide one at a time. It is slow, but a wrong Data safety entry is a rejection reason, and fixing it after the fact costs more. If the declaration itself is what is blocking you, fixing the Google Play Data safety section covers that ground.

The order I run it in

With six apps in flight, an unfixed order is how you lose track of which app got which check. This is where mine settled.

1. Run preflight.sh to pin the scan root and the effective targetSdk
2. Run orchestrator.py init from the repository root and confirm Hybrid app detected appears on stderr
3. Confirm activated_goals is non-empty — an empty array means the entry point is wrong
4. Run the dependency inventory and add SDK-originated collection by hand
5. Walk each finding back to its cited file and drop the false positives
6. Diff against the current Play Console Data safety entries and change only what differs

Step 3 is explicit because that is the one that fooled me. An empty activated_goals does not mean clean. It means nothing ran. There is no error, no warning — just an empty array in a JSON file.

Post-launch monitoring is a separate discipline, but I keep it separate on purpose: thresholds for crash-free users and ANR get decided first, and a staged rollout does not advance to the next slice until they hold. Passing review and surviving after review are two different design problems, and keeping them apart has consistently been faster for me.

What to do next

Run orchestrator.py init once from your repository root and watch stderr for the Hybrid app detected line. If it is there, your entry point is right. If it is not, nothing you have checked so far was actually checked.

Twelve days remain before the target API level 36 requirement. Verifying that the scan reaches your code takes a few minutes.

One caveat on the numbers above: they come from a minimal reproduction of an Expo project shape, not from a production repository. Your dependencies and call sites differ, so your counts will differ. What transfers is not the values — it is the conditions under which the scan reaches anything at all.

I am still working this into my own release routine and have not yet judged the accuracy of Phase 2. When I have, I will write it up.