Pause GC Error after updating Android 4.4.2

Question

Recently, my Galaxy Note 2 has been updated to version 4.4.2. I use this phone for development (using ADT), and life was wonderful, but after this update, the error "Pause GC" appeared, and I can not solve it. It appears every time the user screen changes status in my ADT LogCat tool. Below is an error dump.

Thanks in advance for your help.

05-13 22:39:22.538: W/dalvikvm(8350): No implementation found for native Ldalvik/system/VMRuntime;.pauseGc:(Ljava/lang/String;)I 05-13 22:39:22.543: E/MyThread(8350): Pause GC 05-13 22:39:22.543: E/MyThread(8350): java.lang.reflect.InvocationTargetException 05-13 22:39:22.543: E/MyThread(8350): at java.lang.reflect.Method.invokeNative(Native Method) 05-13 22:39:22.543: E/MyThread(8350): at java.lang.reflect.Method.invoke(Method.java:515) 05-13 22:39:22.543: E/MyThread(8350): at android.app.MyThread.pauseGC(MyThread.java:5525) 05-13 22:39:22.543: E/MyThread(8350): at android.app.MyThread.performLaunchActivity(MyThread.java:2324) 05-13 22:39:22.543: E/MyThread(8350): at android.app.MyThread.handleLaunchActivity(MyThread.java:2471) 05-13 22:39:22.543: E/MyThread(8350): at android.app.MyThread.access$900(MyThread.java:175) 05-13 22:39:22.543: E/MyThread(8350): at android.app.MyThread$H.handleMessage(MyThread.java:1308) 05-13 22:39:22.543: E/MyThread(8350): at android.os.Handler.dispatchMessage(Handler.java:102) 05-13 22:39:22.543: E/MyThread(8350): at android.os.Looper.loop(Looper.java:146) 05-13 22:39:22.543: E/MyThread(8350): at android.app.MyThread.main(MyThread.java:5602) 05-13 22:39:22.543: E/MyThread(8350): at java.lang.reflect.Method.invokeNative(Native Method) 05-13 22:39:22.543: E/MyThread(8350): at java.lang.reflect.Method.invoke(Method.java:515) 05-13 22:39:22.543: E/MyThread(8350): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283) 05-13 22:39:22.543: E/MyThread(8350): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099) 05-13 22:39:22.543: E/MyThread(8350): at dalvik.system.NativeStart.main(Native Method) 05-13 22:39:22.543: E/MyThread(8350): Caused by: java.lang.UnsatisfiedLinkError: Native method not found: dalvik.system.VMRuntime.pauseGc:(Ljava/lang/String;)I 05-13 22:39:22.543: E/MyThread(8350): at dalvik.system.VMRuntime.pauseGc(Native Method) 05-13 22:39:22.543: E/MyThread(8350): ... 15 more 

UPDATE: I triggered the problem on code.android.com ( http://code.google.com/p/android/issues/detail?id=71073 ). According to their Samsung error, so I raised a question on the Samsung forum now.

Answer 1

After viewing this issue for some time on my note 2 (GT-N7100), Android 4.4.2, I would like to make my comment above the correct answer.

Sorted by size:

I used webrtc to track the allocation when using the Android camera, and it is clear that every time the camera is called and the video is displayed in GLSurfaceView in a new action, more than 2 MB of garbage remains that the GC never collects.

To compare, here is the same distribution that is tracked on the ASUS Memo Pad 2, Android 4.2.2:

Sorted by size:

In other words, on note 2, you can start watching live video about 20-30 times before the memory is full and the device works.

In other words: Samsung introduced this problem with the update last year and has not yet fixed it, and they do not react in any way. Samsung wants to force us to buy a new device? It looks like this.

-

And here is my original comment from 2014-12-11:

This is causing problems. This causes the device to receive much more memory than necessary, and a failure. We are developing an application with many images and videos, and due to the lack of GC, you can make Android reach the limit of 64 MB (Note 2) and crash, while in the memory of other devices the consumption is much lower and the memory is saved after use. For example, an ASUS Memo Pad with the same resolution of 12 MB, for which Samsung Note 2 takes up 24 MB. Samsung's device is much faster, although probably due to the lack of GC.

Answer 2

I had the same problem as you. I used ACRA and it swallowed the crash and showed it only in the logarithm.

The error actually returned the server, and I was able to debug it correctly. It is possible to disable ACRA during debugging and you will see the correct error.