Google Play Console rejection – Family Policy & App Stability (Unreal Engine Android)

by

Summary

This postmortem analyzes a Google Play Console production‑stage rejection for an Unreal Engine Android game targeting children. The app passed internal and closed testing but failed only when promoted to production, with rejection reasons citing Families Policy and App Stability. This document explains why this happens, what the real root cause usually is, and how senior engineers resolve it.

Root Cause

The most common underlying causes in cases like this are:

  • Unreal Engine automatically packaging plugins that trigger Google Play’s Families Policy scanners (e.g., analytics, advertising, or tracking‑related libraries).
  • Hidden or unused Android permissions included by default in Unreal Engine builds.
  • Crashes or ANRs detected only in production pre‑launch reports, not during manual testing.
  • Incorrect Play Console declarations, especially for:
    • Data safety
    • Target audience
    • Families Policy compliance
  • Google Play automated scanning detecting SDKs that are not allowed in child‑directed apps, even if unused.

The rejection is rarely caused by your gameplay code. It is almost always caused by packaged libraries, permissions, or metadata mismatches.

Why This Happens in Real Systems

Google Play’s production pipeline is significantly stricter than internal or closed testing. Real systems behave differently because:

  • Production builds undergo automated deep scanning for:
    • Disallowed SDKs
    • Hidden permissions
    • Behavioral signals
  • Pre‑launch automated device testing runs on dozens of real devices, catching:
    • Crashes
    • ANRs
    • Rendering issues
    • Startup failures
  • Family‑targeted apps are scanned with additional rules, including:
    • No analytics SDKs
    • No advertising identifiers
    • No permissions that imply data collection
    • No libraries referencing tracking APIs

Unreal Engine often includes modules that unintentionally violate these rules.

Real-World Impact

These issues can cause:

  • Automatic rejection even if the app works perfectly for human testers.
  • False positives where Google flags unused libraries as “data collection”.
  • Unexpected stability failures due to:
    • GPU differences
    • Device‑specific crashes
    • Unreal Engine’s large native footprint
  • Delayed release cycles because each production attempt requires a full review.

Example or Code (if necessary and relevant)

Below is an example of disabling unwanted Unreal Engine Android plugins in DefaultEngine.ini:

[/Script/AndroidRuntimeSettings.AndroidRuntimeSettings]
bEnableGooglePlaySupport=False
bEnableGooglePlayGamesSupport=False
bEnableGooglePlayAdMob=False
bEnableGooglePlayServices=False

This prevents packaging of analytics/ads libraries that violate Families Policy.

How Senior Engineers Fix It

Experienced engineers typically follow a structured approach:

1. Strip all unnecessary Unreal Engine Android plugins

  • Disable:
    • OnlineSubsystemGooglePlay
    • Google Play Services
    • AdMob
    • Analytics
    • In‑App Purchases
  • Remove any plugin that references:
    • Advertising ID
    • Analytics
    • Tracking

2. Inspect the final APK/AAB

  • Use bundletool or apktool to check:
    • Included libraries
    • Permissions
    • Manifest entries
  • Look for:
    • com.google.android.gms.*
    • android.permission.GET_ACCOUNTS
    • android.permission.AD_ID
    • Any analytics SDK

3. Fix Data Safety and Families Policy declarations

  • Declare no data collection
  • Ensure no SDKs contradict that declaration
  • Ensure target age group is correctly set

4. Analyze Play Console Pre‑Launch Reports

  • Check for:
    • Crashes
    • ANRs
    • Device‑specific failures
    • Startup timeouts

5. Build a clean shipping configuration

  • Disable:
    • Logging
    • Console commands
    • Debug symbols (unless needed)
  • Ensure arm64‑only if required by Play

6. Re‑upload and verify

  • Upload a new AAB
  • Wait for automated scanning
  • Confirm no policy warnings appear before submitting to production

Why Juniors Miss It

Junior developers often overlook these issues because:

  • Unreal Engine hides many Android settings, making it unclear which plugins are included.
  • Internal testing does not replicate production scanning, so everything appears fine.
  • Google Play’s policy language is vague, especially around “stability” and “families”.
  • They assume unused plugins do nothing, but Google scans for presence, not usage.
  • They rely on manual testing, unaware that automated device testing catches different failures.

Senior engineers know that Google Play production is a different environment with stricter rules, and they proactively audit builds before submission.

If you want, I can also generate a checklist specifically for Unreal Engine Android builds targeting children, or help you analyze your AAB to identify which plugin is causing the rejection.

Leave a Comment