High ANR on the game and would like to ask some suggestions

[seal2002]

Hi everyone,

I'am seeing ANR rates on the main thread that consistently exceed my game threshold in production (via Play Console / crash reporting), but I cannot reproduce the issue locally or in test environment at all.

Some context:
- The ANRs are reported on the main thread
- I'm using Android NDK 27.3 with Native target API is 29
- The ANR rate is high enough to trigger alerts, but the stack traces don't point to an obvious bottleneck
- I have not been able to reproduce it on any device or emulator in-house. ( The tester team cannot reproduce it as well)

So my questions:
1. Can I trust that the ANR signals from Play Console are genuinely triggering on the main thread, or could there be false positives / misattribution from the NDK layer?
2. What are the best strategies to debug ANRs that only appear in production and cannot be reproduced locally — especially when native code is involved? Please note that I used the Firebase Crashlytic before and transitioned to Backtrace last year, but nothing help. And I'm switching back to Firebase because it has some cool feature now.
3. Are there any NDK-specific pitfalls (e.g., JNI calls blocking the main thread, mutex contention from native threads) that could silently cause ANRs without being obvious in traces?

Any insights or pointers to relevant tools/techniques would be greatly appreciated. Thank you.

"main" tid=1 Native
  #00  pc 0x000000000004f55c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28)
  #01  pc 0x0000000000053e40  /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex+144)
  #02  pc 0x00000000000c0838  /apex/com.android.runtime/lib64/bionic/libc.so (pthread_cond_wait+72)
  #03  pc 0x000000000fa44538  /data/app/~~q3-XfR3iyyF17omqs8QHow==/com.haiphan.MyMiniGame-BEC99_6SixMGMBQDZtU7fw==/lib/arm64/libMyMiniGame.so (std::__ndk1::condition_variable::wait(std::__ndk1::unique_lock<std::__ndk1::mutex>&)+24) (BuildId: 646cd20ab818e061769e8fbb84690797)
  #04  pc 0x000000000e63b2fc  /data/app/~~q3-XfR3iyyF17omqs8QHow==/com.haiphan.MyMiniGame-BEC99_6SixMGMBQDZtU7fw==/lib/arm64/libMyMiniGame.so (_MainThreadOnNativeWindowDestroyed+146) (BuildId: 646cd20ab818e061769e8fbb84690797)
  #05  pc 0x000000000e640678  /data/app/~~q3-XfR3iyyF17omqs8QHow==/com.haiphan.MyMiniGame-BEC99_6SixMGMBQDZtU7fw==/lib/arm64/libMyMiniGame.so (onSurfaceDestroyed_native+827) (BuildId: 646cd20ab818e061769e8fbb84690797)
  at com.google.androidgamesdk.GameActivity.onSurfaceDestroyedNative (GameActivity.java)
  at com.google.androidgamesdk.GameActivity.surfaceDestroyed (GameActivity.java:591)
  at com.haiphan.jpal.JPal.surfaceDestroyed (JPal.java:317)
  at com.haiphan.MyMiniGame.CommonActivity.surfaceDestroyed (CommonActivity.java:521)
  at android.view.SurfaceView.notifySurfaceDestroyed (SurfaceView.java:1954)
  at android.view.SurfaceView.updateSurface (SurfaceView.java:1089)
  at android.view.SurfaceView.onWindowVisibilityChanged (SurfaceView.java:364)
  at android.view.View.dispatchWindowVisibilityChanged (View.java:15457)
  at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1627)
  at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1627)
  at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1627)
  at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:3017)
  at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:2506)
  at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:9478)
  at android.view.Choreographer$CallbackRecord.run (Choreographer.java:1323)
  at android.view.Choreographer$CallbackRecord.run (Choreographer.java:1331)
  at android.view.Choreographer.doCallbacks (Choreographer.java:964)
  at android.view.Choreographer.doFrame (Choreographer.java:878)
  at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:1306)
  at android.os.Handler.handleCallback (Handler.java:942)
  at android.os.Handler.dispatchMessage (Handler.java:99)
  at android.os.Looper.loopOnce (Looper.java:204)
  at android.os.Looper.loop (Looper.java:291)
  at android.app.ActivityThread.main (ActivityThread.java:8134)
  at java.lang.reflect.Method.invoke (Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:588)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1019)

[enh]

On Wed, Jun 24, 2026 at 7:40 PM seal2002 <phann...@gmail.com> wrote:
>
> Hi everyone,
>
> I'am seeing ANR rates on the main thread that consistently exceed my game threshold in production (via Play Console / crash reporting), but I cannot reproduce the issue locally or in test environment at all.
>
> Some context:
> - The ANRs are reported on the main thread
> - I'm using Android NDK 27.3 with Native target API is 29
> - The ANR rate is high enough to trigger alerts, but the stack traces don't point to an obvious bottleneck
> - I have not been able to reproduce it on any device or emulator in-house. ( The tester team cannot reproduce it as well)
>
> So my questions:
> 1. Can I trust that the ANR signals from Play Console are genuinely triggering on the main thread, or could there be false positives / misattribution from the NDK layer?

i'm not aware of any issues there, no.

> 2. What are the best strategies to debug ANRs that only appear in production and cannot be reproduced locally — especially when native code is involved? Please note that I used the Firebase Crashlytic before and transitioned to Backtrace last year, but nothing help. And I'm switching back to Firebase because it has some cool feature now.
> 3. Are there any NDK-specific pitfalls (e.g., JNI calls blocking the main thread, mutex contention from native threads) that could silently cause ANRs without being obvious in traces?

i'm a bit confused: your trace below shows you blocked waiting on a
lock in your _MainThreadOnNativeWindowDestroyed() function... why
don't you believe that?

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/android-ndk/935d3d91-e0b8-47e6-9048-e12556735f83n%40googlegroups.com.

[seal2002]

Hi,

Sorry to make you confused.

The trace I copied from the Google Console, I cannot reproduce this issue, even the test team from one year ago until now.  

Maybe because it happens on some random countries or devices? Our testers locate at Vietnam, Indonesia, and Spain as well.  

For the first one, I asked it because I saw something different on the [Backtrace](https://backtrace.io/) but it looks like weird, we switched to Firebase and will release new version next Month, I hope that we have more insight from Firebase.  

Vào lúc 03:20:29 UTC+7 ngày Thứ Bảy, 27 tháng 6, 2026, enh đã viết:

[Dime Bar]

I agree with the comment about the lock 

When u test locally do u also test with production?

Have u tried 

> killing the app from the android OS 

> swiping app up and killing it while it’s in background or foreground 

You might need to add logging to your app so u can trace. But that only helps if u can identify the user causing the crash 

Good luck 

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/723d3729-32bc-45a4-96f7-169010f4d7f1n%40googlegroups.com.

[seal2002]

Hi Dime,

Ofcouse I test locally with the production, I still my game around one year until now with 3 devices and steps as your description. Actually the ANR rate is not high too much, around 0.7%, and for the top 1 mentioned, It is around 0.5%, that means 200 times and appear only one.
However, it is still higher than threshold of the console - 0.47%. https://developer.android.com/topic/performance/vitals/anr#detect

Vào lúc 21:47:21 UTC+7 ngày Thứ Bảy, 27 tháng 6, 2026, Dime Bar đã viết:

[seal2002]

I will provide the code of this function later. Indeed, there is a waitable in this function, however, I cannot find which function make is wait more than 5 seconds.

Vào lúc 13:19:33 UTC+7 ngày Chủ Nhật, 28 tháng 6, 2026, seal2002 đã viết:

[Michael Ambrus]

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/723d3729-32bc-45a4-96f7-169010f4d7f1n%40googlegroups.com.