We received ANR Downside in Google Play – Cocos Creator

We’ve encountered a number of ANR (Utility Not Responding) points on Google Play, with the next output content material. Has anybody else skilled comparable issues?

com.google.androidgamesdk.GameActivity.onPauseNative

“most important” tid=1 Native
#00 laptop 0x000000000005c074 /apex/com.android.runtime/lib/bionic/libc.so (syscall+32)
#01 laptop 0x000000000006180d /apex/com.android.runtime/lib/bionic/libc.so (__futex_wait_ex(void unstable*, bool, int, bool, timespec const*)+92)
#02 laptop 0x00000000000a822b /apex/com.android.runtime/lib/bionic/libc.so (pthread_cond_timedwait+76)
#03 laptop 0x0000000000773193 /information/app/~~PKN2hJTO5SaMO566aWeGlA==/com.magicgame.momskitchencrush-hWTbnwJhCMw_hC_qLaEQ_Q==/split_config.armeabi_v7a.apk!libcocos.so
at com.google.androidgamesdk.GameActivity.onPauseNative (GameActivity.java)
at com.google.androidgamesdk.GameActivity.onPause (GameActivity.java:261)
at com.cocos.lib.CocosActivity.onPause (CocosActivity.java:136)
at com.cocos.sport.AppActivity.onPause (AppActivity.java:2809)
at android.app.Exercise.performPause (Exercise.java:8234)
at android.app.Instrumentation.callActivityOnPause (Instrumentation.java:1530)
at android.app.ActivityThread.performPauseActivityIfNeeded (ActivityThread.java:5072)
at android.app.ActivityThread.performPauseActivity (ActivityThread.java:5033)
at android.app.ActivityThread.handlePauseActivity (ActivityThread.java:4985)
at android.app.servertransaction.PauseActivityItem.execute (PauseActivityItem.java:47)
at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2247)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:201)
at android.os.Looper.loop (Looper.java:288)
at android.app.ActivityThread.most important (ActivityThread.java:7886)
at java.lang.replicate.Methodology.invoke (Native technique)
at com.android.inner.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:568)
at com.android.inner.os.ZygoteInit.most important (ZygoteInit.java:1045)

[split_config.arm64_v8a.apk] android_app_set_activity_state

“most important” tid=1 Native
#00 laptop 0x000000000004f670 /apex/com.android.runtime/lib64/bionic/libc.so (syscall+32)
#01 laptop 0x0000000000054060 /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex+144)
#02 laptop 0x00000000000c1208 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_cond_timedwait+136)
#03 laptop 0x0000000000c17974 /information/app/~~mACo8CW7KmrKLw6XeJ7MQA==/com.magicgame.momskitchencrush-PPoXFUMt6N3upRUTzGnkPg==/split_config.arm64_v8a.apk (android_app_set_activity_state+4096) (BuildId: c4ba318d4eb6a06602e9d6bbc0404a1e30ffe8ea)
at com.google.androidgamesdk.GameActivity.onResumeNative (GameActivity.java)
at com.google.androidgamesdk.GameActivity.onResume (GameActivity.java:267)
at com.cocos.lib.CocosActivity.onResume (CocosActivity.java:142)
at com.cocos.sport.AppActivity.onResume (AppActivity.java:2761)
at android.app.Instrumentation.callActivityOnResume (Instrumentation.java:1531)
at android.app.Exercise.performResume (Exercise.java:8422)
at android.app.ActivityThread.performResumeActivity (ActivityThread.java:4833)
at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:4877)
at android.app.servertransaction.ResumeActivityItem.execute (ResumeActivityItem.java:54)
at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2345)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:201)
at android.os.Looper.loop (Looper.java:288)
at android.app.ActivityThread.most important (ActivityThread.java:7941)
at java.lang.replicate.Methodology.invoke (Native technique)
at com.android.inner.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:569)
at com.android.inner.os.ZygoteInit.most important (ZygoteInit.java:1019)

We’ve got additionally encountered the identical drawback. Did you discovered an answer for this?

No, I’m at present utilizing this model.
Cocos Creator Model: 3.7.2
Goal SDK: 33

I searched the discussion board. Plainly model 3.8.2 and above even have this drawback.

Might you please contact the customers to ask them to document the sport state of affairs when the error happens? At the moment, we’re unable to investigate the reason for the issue primarily based on the error report.

Sorry, We are able to’t contact our customers.

However after I commented like this. The ANR is decreased.

static void onPause_native(JNIEnv *env, jobject javaGameActivity,
jlong deal with) {
LOG_TRACE(“onPause_native”);
/*if (deal with != 0) {
NativeCode *code = (NativeCode )deal with;
if (code->callbacks.onPause != NULL) {
code->callbacks.onPause(code);
}
}/
}

What’s the anticipated proportion of discount?

We’re at present at 2.07%, however ought to or not it’s 0.47%?

This was talked about by Google Play, which states: “Your 28-day user-perceived ANR (Utility Not Responding) charge exceeds the dangerous conduct threshold of 0.47%. Your app is more likely to be much less discoverable on Google Play throughout all gadgets.”

This difficulty was attributable to a bug in android_native_app_glue inside AGDK that resulted in thread lock blockages when switching between the foreground and background（pthread_cond_timedwait）, and it’s a widespread drawback.

I’m unclear why Google hasn’t addressed it persistently.

We managed to resolve the problem by modifying android_native_app_glue and including a stack construction to save lots of the APP_CMD_PAUSE occasion of android_native_app_glue .
After practically a month of statement, the ANR charge has dropped to only one third of its unique charge.
Shifting ahead，I’ll think about pushing a PR to Cocos as quickly as doable for them to evaluate whether or not to merge it into the engine.

On April twenty fourth, we launched a repair model, and you may see the comparability.

@haroel So, to what extent has this drawback been resolved? I’m at present utilizing cocos creator model 3.8.1. Are you able to inform me which model the answer was solved in?

Is it doable to share extra detailed know-how? We imagine this difficulty may be very pressing.

In your sport, what’s the approximate measurement of the audio recordsdata, what number of will be performed concurrently, and what’s the most quantity?

Are there logs from different threads when an ANR happens?

@Azaratur @gandangf @quriouschirag @haroel @Lukeluo
Certain, right here is the interpretation of the textual content into English:

We’ve got applied logic to observe unresponsive applications for timeouts. Please consult with this PR. On Android, it could be essential to alter SIGUSR1 to SIGUSR2.

Clarification:

The offered textual content discusses a mechanism for monitoring the responsiveness of applications and dealing with timeouts. It means that the present implementation would possibly make the most of SIGUSR1 indicators for timeout detection, and on Android platforms, it is likely to be useful to modify to SIGUSR2 indicators as a substitute.

Timeout Monitoring and Stack Printing:

The textual content mentions that upon enabling timeout monitoring, the system will print C++ and TypeScript stacks when a timeout happens. This gives beneficial info for debugging and figuring out unresponsive sections of this system.

Storing Stack Traces in Recordsdata:

If the necessity arises to retailer these stack traces in recordsdata, the textual content suggests two potential approaches:

1. Modify dispatchScriptExecutionTimeout: This means that the dispatchScriptExecutionTimeout perform, which is probably going accountable for dealing with timeout detection and stack printing, may very well be modified to incorporate performance for saving stack traces to recordsdata.
2. Implement Stack Storage in TypeScript Callback: Alternatively, the stack storage logic may very well be applied throughout the TypeScript callback that’s invoked when a timeout happens. This would offer extra granular management over how and the place stack traces are saved.

Please consult with the adjustments on this PR. ALooper_pollAll could trigger anr

Can anybody share the results of making use of the above PR? Does it repair the problem?