Home » Android » How to fix ANR issue on /data/app/com.android.chrome-1/base.apk?

How to fix ANR issue on /data/app/com.android.chrome-1/base.apk?

Posted by: admin June 15, 2020 Leave a comment


can you help me with this ANR issue? Users reports lots of times to Google Play Console, but I cannot reproduce it myself. Many thanks.

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x73898658 self=0xb0204400
  | sysTid=3708 nice=-4 cgrp=default sched=0/0 handle=0xb2f69534
  | state=S schedstat=( 5873509009 1942619080 10289 ) utm=484 stm=102 core=3 HZ=100
  | stack=0xbe00c000-0xbe00e000 stackSize=8MB
  | held mutexes=
  #00  pc 00000000000174d4  /system/lib/libc.so (syscall+28)
  #01  pc 0000000000046a5d  /system/lib/libc.so (_ZL24__pthread_cond_timedwaitP23pthread_cond_internal_tP15pthread_mutex_tbPK8timespec+102)
  #02  pc 0000000000039bb1  /data/app/com.android.chrome-1/base.apk (???)
  at org.chromium.ui.base.WindowAndroid.nativeOnVSync (Native method)
  at org.chromium.ui.base.WindowAndroid.access$700 (WindowAndroid.java:134)
  at org.chromium.ui.base.WindowAndroid$1.onVSync$5166USJ75THMGSJFDLKNAR9FELKIULIJF5N66JBFDPKN8RRI7D52ILG_0 (WindowAndroid.java:16)
  at org.chromium.ui.VSyncMonitor$1.doFrame (VSyncMonitor.java:22)
  at android.view.Choreographer$CallbackRecord.run (Choreographer.java:872)
  at android.view.Choreographer.doCallbacks (Choreographer.java:686)
  at android.view.Choreographer.doFrame (Choreographer.java:618)
  at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:860)
  at android.os.Handler.handleCallback (Handler.java:751)
  at android.os.Handler.dispatchMessage (Handler.java:95)
  at android.os.Looper.loop (Looper.java:154)
  at android.app.ActivityThread.main (ActivityThread.java:6165)
  at java.lang.reflect.Method.invoke! (Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:888)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:778)
How to&Answers:

“ANR” stands for “Application not responding”. It means your app has locked up for the user. There are usually 1 of two causes:

  • you have a deadlock
  • you are doing some slow operation on the UI thread, which means your UI doesn’t respond

In this case we see the top of the stack trace is in “org.chromium.ui.base.WindowAndroid.nativeOnVSync”. It is helpful to know that “chromium” is the open source project that powers Google Chrome, among other things. This means you can go to look at the source code.

Googling “nativeOnVysnc” on github finds the java source code

Basically it looks like something is locking up inside some Chrome rendering code.
It helps to know at this point Chromium is used for Webkit which is used for rendering webview windows in Android apps. So chances are you have some sort of webview in your app which is misbehaving for rendering, but I can’t help you beyond that. I’d check the javascript in my webviews for memory usage or other risky behavior, or look inside the Chromium repositry at the C++ native code to try to get a better idea of what is happening.


There are few things you can do :

  1. open source git project called ANR-WatchDog.
    You can catch every anr using very simple few steps.
    You can define the number of seconds you consider to be an ANR (for example, if you set it to 0.5 seconds, you might catch the ANR described above.
  2. Search for Wakelocks in your code
  3. Are you using sqlite(or any other db library)? If so, i’d check using the ANR-Watchdog if inserting, updating, fetching takes too long. Overall, check that all the queries aren’t blocking the ui thread for too long.


I had same problem. But I could decrease ANRs about this problem so much.

1. Chromium bug

The previous version of Chrome had a bug, which did not sometimes release VSync listeners.
However, at the latest version of chromium, it seems that this bug has been fixed.


2. Admob – long holding UnifiedNativeAdView

If your project have AdMob native ads, it may be a cause.
It seems that UnifiedNativeAdView uses VSync internally, if you do not call destroy(), VSync listener remains and leaks, I think.


I had the same problem a week ago. I could not find an answer anywhere. ANR analysis for me was not clear. As a result, it turned out that it’s my fault – in onResume () I used recreate () if (camera == null). When testing everything was ok, and after the first installation there is a request for permission to the camera and the activity was restarted to infinity. After editing the code, this error was reduced to almost zero. You must search for an error in your code.