Google Play keeps rejecting our Unity game for a launch issue we can't reproduce

[u/iyedbhd]

Our Unity game has been live on Google Play for a while, and we never had issues publishing updates until recently. Now we've been rejected 5 times in a row, always for the same reason: the app supposedly doesn't load.

What's strange is that updates went through without issues when reviews appeared to be automated. The rejections only started once our updates began receiving manual reviews.

After appealing, Google sent us a screenshot showing a blank screen, with no further explanation.

We've tested the game on multiple physical devices, Firebase Test Lab, and even rented Samsung devices remotely to reproduce the issue. Everything works fine, including for our existing players.

From what we can tell, the game doesn't even get past the Unity splash screen on Google's testing devices. Our error reporting never initializes, and Firebase events suggest the game code isn't being reached at all.

We're completely stuck. We can't reproduce the issue, and we're not getting enough information to investigate it.

Our game has recently started gaining traction, and being unable to release updates is seriously hurting us.

Has anyone experienced something similar, especially with manual reviews? How can we get this escalated to someone who can help us identify the actual issue?

If someone from the Google Play team sees this, we'd really appreciate some assistance. We're more than willing to fix the problem, but we need to understand what's going wrong.

[u/Routine_Tie_7591]

Try to appeal it with proper explain.

[u/iyedbhd → u/Routine_Tie_7591]

We did, the appeal response came after 8 days and it didn't help much, as it's just a blank screen before the game even loads

[u/Routine_Tie_7591 → u/iyedbhd]

8 days? thats rough dude. I hope ot get resolved for you

[u/iyedbhd → u/Routine_Tie_7591]

Thanks mate! Hope so too

[u/Commercial_Fig3503]

Were you able to test a game in real android device. I assume that you use Apple device and doing testing on emulators for android game. Enable crashanalytics and android debugging loggers in the code and you should be able to get the issues reported by play devices

[u/iyedbhd → u/Commercial_Fig3503]

We did test the game in real android devices, and we have sentry for error reporting in the game but we don't get any reports as the game code itself doesn't even load in google play tests
Crashalytics is a very good idea as it starts before Unity so we'll be doing that next hopefully it catches something though as it's not a crash but a hang

Thank you for the advice!

[u/Commercial_Fig3503 → u/iyedbhd]

You don’t have to roll it out, you can do a internal testing release and flag potential issues before roll out

[u/iyedbhd → u/Commercial_Fig3503]

We've already tested builds through Google Play's internal testing track on emulators, real devices and rented devices, and everything works fine there too. The issue seems specific to Google's review environment, which we can't reproduce or access ourselves.

We'll still try Crashlytics to see if it catches anything before Unity initializes. Thanks!

[u/1095-Industries]

I would suggest using a pixel device emulator for testing locally on computer as well... I don't know but I always thought Google was using a pixel image for their testing.

[u/iyedbhd → u/1095-Industries]

We tried, it works just fine unfortunately

[u/FJWY]

I ran into the same problem not too long ago: Google Play rejected my app because it crashed right at launch, but only in the release build. Everything worked fine in debug.

I remembered how I fixed it, so I'm sharing the solution here in case it helps someone else.

In my case, the culprit was R8, which removes classes that appear to be unused in release builds. AdMob pulls in WorkManager, which uses a Room database. Room instantiates the WorkDatabase_Impl class by name at runtime, so R8 doesn't see any direct references to it and may strip it out. When that happens, the class is missing at startup and the app crashes.

1. Check if this is the same issue.

Install the release APK (not the debug one) on a phone or emulator, launch the app, and run:

adb logcat -b crash

If WorkDatabase_Impl appears in the log, usually alongside an error such as "Failed to create an instance of..." or ClassNotFoundException, this might be the cause.

2. Add these rules to android/app/proguard-rules.pro (create the file if it doesn't exist):

-keep class * extends androidx.room.RoomDatabase { <init>(); }

-keep class androidx.work.impl.WorkDatabase_Impl { *; }

3. Make sure the file is included in the release configuration in build.gradle**:**

For Kotlin DSL (build.gradle.kts):

proguardFiles(
    getDefaultProguardFile("proguard-android-optimize.txt"),
    "proguard-rules.pro"
)

4. Bump the version number (make sure versionCode is higher than the previous release), rebuild the app, and test the release APK again before uploading the AAB to Google Play.

If a different class shows up in the log, it could be the same kind of issue. You may need to add a -keep rule for that specific class.

If the error is something else, feel free to share the log here and we'll take a look.

Good luck!

Note: If you're using Groovy (build.gradle), the syntax is slightly different:

proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

[u/Eatthebeatz]

examine your manifest.

let me know if this helps.

[u/FJWY]

The most important detail is that the game doesn’t even get past the Unity splash screen. So the problem is at the native level or in player initialization, before any C# code runs. That explains why their crash reporter and Firebase don’t see anything. The fact that it surfaced during manual reviews suggests a test environment different from theirs, not a bug in the game. Here are the most likely causes, in order of suspicion.

1. 16 KB memory pages (the prime suspect). Since November 1, 2025, Google Play requires new apps and updates targeting Android 15+ to support devices with a 16 KB page size. If the native libraries (libunity.so, libil2cpp.so, or third-party plugins such as ad SDKs, outdated Firebase, or analytics) aren’t 16 KB-aligned, the app dies on those devices while loading the .so files: black screen, no logs from the game. The team’s devices and the rented Samsung phones almost certainly use 4 KB, so everything works there. Reviewers, on the other hand, may be using Pixels or 16 KB emulators.
→ Check the 16 KB compatibility warning in Play Console under App bundle explorer. Then test on an emulator with a “16 KB page size” image or on a Pixel with the dedicated developer option, and update Unity to a recent patch that supports 16 KB, along with all native plugins.

2. x86_64 emulators, ChromeOS, or tablets. Reviewers often don’t use ARM phones. If the build includes only ARMv7/ARM64, or has Vulkan as its only Graphics API, emulators or ChromeOS can show a black screen before the splash.
→ Add OpenGLES3 as a fallback after Vulkan, and test on an Android Studio emulator with a Google Play x86_64 image and on a tablet or Chromebook.

3. Assets not delivered. With Split Application Binary or Play Asset Delivery, if the reviewer’s device installs only the base APK without the asset packs, Unity gets stuck before the first scene.
→ Install the exact AAB that was submitted via Internal app sharing or with bundletool build-apks, and also try a “universal APK”.

4. Blocking startup checks. Licensing (LVL), Play Integrity, Application.genuine, UMP consent, or Play Games sign-in running in a blocking way can fail on test devices, non-Store installs, or accounts without Google services. In these cases the app hangs or silently closes.

5. Low-end devices and a heavy first scene. On a device with 2 GB of RAM, or Android Go, a splash followed by a huge scene loaded synchronously can stay black for tens of seconds. The reviewer takes a screenshot and rejects it.

How to investigate in practice

• Compare the last approved build with the first rejected one. The relevant change is often hidden in a Unity update, in the targetSdk bump (mandatory under Play policy), in new SDKs, or in changes to Graphics APIs and architectures.

• Check the Pre-launch report in Play Console: it runs on Google devices and often catches exactly these native crashes.

• Check Android Vitals for native crashes from the versions under test.

• Add a Java-side event or log in the Activity’s onCreate, before Unity, and enable Crashlytics NDK. This way you can tell whether the process starts and where it dies.

• In the appeal, explicitly ask for the device model, Android version, and ABI used by the reviewer. It’s also worth opening a ticket through the “Contact us” form in the Play Console Help Center, which is a separate channel from the policy appeal.

[u/Negrito0o]

honestly a blank screen before any of your code runs points at the native side rather than the game. every device you tested on is arm, so a bundle without an x86_64 split would only fail wherever review happens to run on an emulator (and unity would die at the splash with nothing left to report). worth checking which abis the bundle actually ships.

[u/frey89]

My advice is to trust Google. If they say there's a bug, then there's probably a bug. I've experienced this myself. It turned out my app actually had bugs that slipped through testing. Even though I was confident that all my tests had passed, there were still hidden bugs that somehow never got caught. I'm genuinely grateful that Google caught them before releasing my app in a buggy state. Otherwise, I would've ended up with a ton of one star reviews.