I can see something strange at WebView based app start. It doesn't affect the app at all but I'm curious why the error appears. Nothing crashes, everything seems to be ok, but the error...
Here is logcat
Loading com.google.android.webview version 42.0.2311.137 (code 2311137)
I/LibraryLoader﹕ Time to load native libraries: 2 ms (timestamps 3347-3349)
I/LibraryLoader﹕ Expected native library version number "",actual native library version number ""
V/WebViewChromiumFactoryProvider﹕ Binding Chromium to main looper Looper (main, tid 1) {2d3b4b2c}
I/LibraryLoader﹕ Expected native library version number "",actual native library version number ""
I/chromium﹕ [INFO:library_loader_hooks.cc(112)] Chromium logging enabled: level = 0, default verbosity = 0
I/BrowserStartupController﹕ Initializing chromium process, singleProcess=true
W/art﹕ Attempt to remove local handle scope entry from IRT, ignoring
E/SysUtils﹕ ApplicationContext is null in ApplicationStatus
W/chromium﹕ [WARNING:resource_bundle.cc(286)] locale_file_path.empty()
I/chromium﹕ [INFO:aw_browser_main_parts.cc(63)] Load from apk succesful, fd=34 off=6850672 len=3697
I/chromium﹕ [INFO:aw_browser_main_parts.cc(76)] Loading webviewchromium.pak from, fd:35 off:7953036 len:1161174
I/Adreno-EGL﹕ <qeglDrvAPI_eglInitialize:379>: QUALCOMM Build: 01/15/15, ab0075f, Id3510ff6dc
W/AudioManagerAndroid﹕ Requires BLUETOOTH permission
W/chromium﹕ [WARNING:data_reduction_proxy_config.cc(150)] SPDY proxy OFF at startup
W/art﹕ Attempt to remove local handle scope entry from IRT, ignoring
W/AwContents﹕ onDetachedFromWindow called when already detached. Ignoring
I/GAv4﹕ Google Analytics 4.5.0/7327 is starting up. To enable debug logging on a device run:
adb shell setprop log.tag.GAv4 DEBUG
adb logcat -s GAv4
I suppose the error comes from here:
https://chromium.googlesource.com/chromium/src/base/+/master/android/java/src/org/chromium/base/SysUtils.java
A few lines of WebView initialisation
...
// load url in webView
webView.loadUrl(webViewUrl);
webView.setWebViewClient(new MyAppWebViewClient());
// implement WebChromeClient inner class
// we will define openFileChooser for select file from camera
webView.setWebChromeClient(new WebChromeClient() {
...
What's going on?
What is happening here is:
The ApplicationStatus is not initialized yet, so the context cannot be obtained from it. This is a completely natural situation, so no error should be raised. Logging this as an error was an exaggeration from the coder.
However:
This does not cause any real problem, because the function tries to get a context object only to perform yet another check to assess the performance capabilities of the device. Since it sometimes fails to call the "isLowRamDevice()", it will just carry on performing the rest of the checks. So worst case scenario is not being able to detect a low-end phone at this point, and subsequent checks will be made.
Also it is completely normal that
"I see this error in a Lollipop device (Nexus 10) but not in a JellyBean device", because the function has an early return if it detects anything below KitKat. (// Any pre-KitKat device cannot be considered 'low-end')
Related
Today I noticed the following in my logcat:
D/OpenGLRenderer: endAllStagingAnimators on 0xa2c70600 (CardView) with handle 0xa2c9d350
First of all, I haven't noticed any errors when running the application, but I did some research and couldn't find anything about this. There is also a few questions about this with no answers:
endAllStagingAnimators on RippleEffect
what is endAllStagingAnimators
endAllStagingAnimators on CardView
The name endAllStagingAnimators kind of says what it is, "ending all animators". But like I said, I can't find any information about this.
So my question is:
What is endAllStagingAnimators, should I be worried about it and where can I get more information about this?
This message is related to RippleEffect Animation. It is an internal message which must have been logged after ripple effect has finished (indicating that all staged animators of ripple effect are successfully removed from CardView).
This is not an error message and thus won't affect you in any way. It is internal debug message( D/ OpenGLRenderer). Refer here
I am currently implementing a fullscreen-exclusive mode in my Java2D-Application. While testing on several systems (all Windows 7/8.x) with most recent (18. February 2015) JRE, I can reproduce a application crash which does NOT throw an exception:
If you are in fullscreen-exclusive mode (yes: I check for supported display modes) and turn off the monitor which displays the application, the application crashes. No exception thrown. My guess is, that the vsync-component of Java2D crashes, but I lack the required experience in Java. Can someone help me out here on how I can handle this exception (by switching back to windowed-mode for example). Something like "isDisplayDeviceReady()" might also be helpful.
Thank you for your time.
This is what Windows shows me after application crash:
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: javaw.exe Anwendungsversion: 8.0.31.13
Anwendungszeitstempel: 54925fd3 Fehlermodulname: StackHash_915d
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea8e7 Ausnahmecode: c0000374
Ausnahmeoffset: 000ce753
Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055
Zusatzinformation 1: 915d
Zusatzinformation 2:
915d12e427f130d100a5a047f72f08c0
Zusatzinformation 3: 8dd4
Zusatzinformation 4: 8dd4ced129ecb79ce625a0ed8d82cee9
I am using latest Facebook Android SDK and getting that error from dozens of users in my remote crash control app in my latest released apk. I have looked here for such error, but most of the answers are too outdated for last FB SDK, and in this case there are two weird circumstances:
a) The error seems to happen randomly. I have been unable to reproduce it at all on none of my devices.
b) There were no changes in FB logic at all between that release and the previous one, and in the previous release I have never had such error.
Since I couldn't find any relevant difference in the code between such versions, I thought the problem was something wrong could have happened with Android Tools while generating the last apk, but giving the fact that very same apk is the one I am using and have been unable to reproduce the problem and, despite dozens or users are affected, hundreds using the same apk aren't, I discarded also such hypothesis.
Any ideas on how to solve or just debug this thing are welcome.
More info that could be relevant:
All crashes happened in Android 4.0.3 or older. The highest percentage is for 2.3.6 with 48% of all the crashes.
That class is actually exported in the APK. I have checked it by unzipping the apk and using dexdump to see what is inside classes.dex. I couldn't expected other thing, since it works perfectly in all my devices and if the class weren't there, it would not.
$ ~/android-sdks/build-tools/21.1.1/dexdump classes.dex | grep 'com.facebook.internal.Utility$1'
Class descriptor : 'Lcom/facebook/internal/Utility$1;'
#0 : (in Lcom/facebook/internal/Utility$1;)
#1 : (in Lcom/facebook/internal/Utility$1;)
#2 : (in Lcom/facebook/internal/Utility$1;)
#0 : (in Lcom/facebook/internal/Utility$1;)
#0 : (in Lcom/facebook/internal/Utility$1;)
#1 : (in Lcom/facebook/internal/Utility$1;)
#2 : (in Lcom/facebook/internal/Utility$1;)
#3 : (in Lcom/facebook/internal/Utility$1;)
It seems to fail after an invocation of a Utility's static method from loadAppSettingsAsync, that happens to be a static method within the same class. So, if the com.facebook.internal.Utility class does not exist or couldn't be loaded, how it is possible that com.facebook.internal.Utility.loadAppSettingsAsync is executed in first place? and if it exists and it is loaded, why is NoClassDefFoundError thrown on com.facebook.internal.Utility? I am so f* lost...
Here the stack from splunk mint (formerly known as bugsense), I just changed the name of the app. I retraced it with the proguard map file, but it seems it missed some line numbers anyway:
java.lang.NoClassDefFoundError: com.facebook.internal.Utility$1
at com.facebook.internal.Utility.void loadAppSettingsAsync(android.content.Context,java.lang.String)(Unknown Source)
at com.facebook.Settings.void sdkInitialize(android.content.Context)(Unknown Source)
at com.facebook.UiLifecycleHelper.<init>(Unknown Source)
at net.iberdroid.androidgames.framework.impl.AndroidGame.void onCreate(android.os.Bundle)(Unknown Source)
at com.marzoa.ruletafree.xmas2012.RuletaAfortunadaGame.void onCreate(android.os.Bundle)(Unknown Source)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1050)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1623)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1675)
at android.app.ActivityThread.access$1500(ActivityThread.java:121)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:943)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:130)
at android.app.ActivityThread.main(ActivityThread.java:3770)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:670)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: com.facebook.internal.Utility$1 in loader dalvik.system.PathClassLoader[/data/app/com.marzoa.ruletafree.xmas2012-2.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:240)
at java.lang.ClassLoader.loadClass(ClassLoader.java:551)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
... 18 more
As the NoClassDefFoundError occurs in loadAppSettingsAsync at an anonymous implementation of AsyncTask it seems to be the same problem like this NoClassDefFoundError - Android 2.3.X
Its a bug in google play services. (https://code.google.com/p/android/issues/detail?id=81083)
Try to add following into your Application#onCreate() method as described in the answer of the referred issue.
try {
Class.forName("android.os.AsyncTask");
}
catch(Throwable ignore) {
// ignored
}
Firstly, be sure that you are checking for the right class. According to the error message, the "missing" class is com.facebook.internal.loadAppSettingsAsync$1. Note the $1!! That means we are talking about an anonymous inner class that is declared within the Utility.loadAppSettingsAsync.
Second, java.lang.NoClassDefFoundError can have a number of causes:
The class may be missing.
The class could be present but unloadable for some reason.
The class could be loadable, but a previous attempt to initialize it ... or some dependent class ... has failed.
The last case typically happens if a static initialization or static initializer block throws an unchecked exception the first time it was run. (You will typically a log message for this exception.) Once the class initialization has failed once, the class is marked as broken. This stops the class and any other classes that depends on it from being initialized.
I am using crashlytics to track my app's crash. There is one bug which is quite hard to figure out. The stack trace from crashlytics is as below:
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
at android.view.InputChannel.nativeReadFromParcel(InputChannel.java)
at android.view.InputChannel.readFromParcel(InputChannel.java:148)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:39)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:36)
at com.android.internal.view.InputBindResult.<init>(InputBindResult.java:62)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:102)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:99)
at com.android.internal.view.IInputMethodManager$Stub$Proxy.windowGainedFocus(IInputMethodManager.java:851)
at android.view.inputmethod.InputMethodManager.startInputInner(InputMethodManager.java:1292)
at android.view.inputmethod.InputMethodManager.onWindowFocus(InputMethodManager.java:1518)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:3550)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:157)
at android.app.ActivityThread.main(ActivityThread.java:5293)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1265)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1081)
at dalvik.system.NativeStart.main(NativeStart.java)
I know there is one similar question about this here. But there is a bit different. And as statistics from crashlytics, the crash happens mainly in SAMSUNG android phone.
I am new to android and don't know why the crash happened and how to fix this kind of crash.
Any suggestion would be much appreciated.
Think it's a very wide area and there could be a lot of situations which can trigger this system level exception. But maybe this example of how it was fixed in a particular project can help someone.
I experienced a similar exception:
"Could not read input channel file descriptors from parcel" on Samsung phone:
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
at android.view.InputChannel.nativeReadFromParcel(Native Method)
at android.view.InputChannel.readFromParcel(InputChannel.java:148)
at android.view.IWindowSession$Stub$Proxy.addToDisplay(IWindowSession.java:690)
at android.view.ViewRootImpl.setView(ViewRootImpl.java:525)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:269)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:69)
at android.widget.Toast$TN.handleShow(Toast.java:402)
at android.widget.Toast$TN$1.run(Toast.java:310)
at android.os.Handler.handleCallback(Handler.java:730)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5103)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:525)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:737)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
at dalvik.system.NativeStart.main(Native Method)
It happened in a big old project which I got for maintenance and this floating bug occurred only after several hours. I spent quite some time on it and also read some related answers on SO regarding it and had no clue except it's a system level bug of Android, and there should be some extra data or duplicates of objects or big objects in memory etc:
https://code.google.com/p/android/issues/detail?id=32470
The last thing I could think about was SoundPool. It's not used a lot in the project - there are not more than 10 different sounds played from time to time. But it was the root cause! Sometimes there were floating exceptions from SoundPool "unable to load sample (null)". And it helped to realize that SoundPool was used in a wrong way:
public void play(int rscId) {
...
final int soundId = soundPool.load(mContext, rscId, 1);
...
soundPool.play(soundId, volume, volume, 5, 0, 1f);
So new id was generated and sound resource was reloaded each time application called play sound method! And after certain amount of time some non related exceptions started to occur until application crashed with the "Could not read input channel file descriptors from parcel" exception.
It's interesting that one of those non related exceptions was: "ExceptionHandled in unable to open database file (code 14)":
ExceptionHandled in unable to open database file (code 14)
android.database.sqlite.SQLiteCantOpenDatabaseException:
unable to open database file (code 14)
at android.database.sqlite.SQLiteConnection.nativeExecuteForCursorWindow
(Native Method)
at android.database.sqlite.SQLiteConnection.executeForCursorWindow
(SQLiteConnection.java:845)
And of course it has nothing to do neither with database nor with toasts/parcels. The fix for that particular situation was very easy: just preload all sounds as it's suggested in Android documentation:
http://developer.android.com/reference/android/media/SoundPool.html
"The loading logic iterates through the list of sounds calling the appropriate SoundPool.load() function. This should typically be done early in the process to allow time for decompressing the audio to raw PCM format before they are needed for playback.
Once the sounds are loaded and play has started, the application can trigger sounds by calling SoundPool.play()."
So I moved soundPool.load() out from play() method and the exception :
"Could not read input channel file descriptors from parcel" has gone as well as the exception "unable to open database file (code 14)".
public void play(int soundId) {
...
soundPool.play(soundId, volume, volume, 5, 0, 1f);
And soundPool.release(); soundPool = null should be called as well when it's not needed anymore. And maybe it also can have an effect on such exceptions, see details here
Could not read input channel file descriptors from parcel
Most probably it's not the exact situation for the original question but hope it can give some information to dig further. I.e. looking for some additional exceptions, swallowed exceptions, or wrong files/data handling.
I am looking for the answer for a long time such as the others facing at this exception.
As I see it, this crash can also be triggered by the unexceptional TextView or EditText which works with the InputMethodManager:
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
at android.view.InputChannel.nativeReadFromParcel(Native Method)
at android.view.InputChannel.readFromParcel(InputChannel.java:148)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:39)
at android.view.InputChannel$1.createFromParcel(InputChannel.java:36)
at com.android.internal.view.InputBindResult.<init>(InputBindResult.java:68)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:112)
at com.android.internal.view.InputBindResult$1.createFromParcel(InputBindResult.java:109)
at com.android.internal.view.IInputMethodManager$Stub$Proxy.startInput(IInputMethodManager.java:697)
at android.view.inputmethod.InputMethodManager.startInputInner(InputMethodManager.java:1407)
at android.view.inputmethod.InputMethodManager.checkFocus(InputMethodManager.java:1518)
at android.view.inputmethod.InputMethodManager.restartInput(InputMethodManager.java:1286)
at android.widget.TextView.setText(TextView.java:4718)
at android.widget.TextView.setText(TextView.java:4656)
at android.widget.TextView.append(TextView.java:4330)
at android.widget.TextView.append(TextView.java:4320)
...
When TextView appending text, it will make text to Editable, and start InputMethodManager. But at this time, something goes wrong in the InputMethod process, and it leads to fail to create InputBindResult which reading error from the parcel.
In this case, the workaround is very simple: DO NOT call append on textview directly, use StringBuilder or SpannableStringBuilder to build text and call TextView.setText(text) instead!
Previous users have commented that this can be a hard bug to track down. I caused this by building a custom alert dialog (containing multiple TextView objects) inside of a while loop vice an if statement. The application crashed before displaying the dialog box(es).
I have meet this problem recently.
java.lang.RuntimeException: Could not read input channel file descr
iptors from parcel.
I search the log find following info:
01-01 09:07:52.164 5162 6777 W zygote64: ashmem_create_region failed
for 'indirect ref table': Too many open files
The problem is that I create HandlerThread repeatedly, but don't do it's quit() method, at last result in fd leaked.
ViewRootImpl$ViewRootHandler means you have view.post or view.postDelay.
and in the post method maybe requestFocus or Keyboard
We're debugging an error that causing a crash in a Tomcat web application.
The application uses 2 3rd-party apps over jni, one of the 3rd-parties using SmartHeap (it is a memory management library for c/c++ applications), the other don't (it is webMethods broker version 5).
The strange thing is I see in the crash log that webMethods calls its native methods to initiate a connection to the broker server, but if I print the call trace of the thread where the crash happened using WinDbg (loading the minidump file created when the JVM crashed), it contains calls to SmartHeap functions. Now i feel I'm a bit lost... because I've checked, and found no references to this dll from the webMethods binaries.
(actually a memory allocation is called)
My question is how is it possible?
I mean anybody could describe how this part is working? Because I thought that the interpreted/compiled and native frames are called in a fixed order (it is logical).
maybe the call stack is invalid? (now we have many dump files with almost the same call trace)
or the call trace (the calling order of the native functions) is valid, only some of the functions have been reordered before calling (like a lazy object has to be generated before sending it to the webMethods broker, but i don't see any sign of this)
I'm querying the call trace on the dump file by calling ".ecxr" and "kv", the output is:
0:060> .ecxr
eax=4d330554 ebx=4d350010 ecx=4d330010 edx=00000000 esi=4d350010 edi=00000000
eip=4c912f15 esp=4bf1dad0 ebp=3574884d iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
shsmp!shi_allocSmall2+0x195:
4c912f15 8b4d00 mov ecx,dword ptr [ebp] ss:0023:3574884d=????????
0:060> k
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
4bf1daec 4c912bbd shsmp!shi_allocSmall2+0x195
4bf1dafc 4c91b973 shsmp!MemAllocPtr+0x5d
*** WARNING: Unable to verify checksum for awssl50jn.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for awssl50jn.dll -
4bf1db14 49abc38d shsmp!shi_malloc_dbg+0x23
WARNING: Stack unwind information not available. Following frames may be wrong.
4bf1db3c 49abeca2 awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0xa1cd
4bf1db48 49ab5e66 awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0xcae2
4bf1db4c 49ab5e55 awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0x3ca6
4bf1db60 49ab667d awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0x3c95
4bf1db80 49abdbbc awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0x44bd
4bf1dc20 4c912f4f awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0xb9fc
4bf1dc78 49abd607 shsmp!shi_allocSmall2+0x1cf
00000000 00000000 awssl50jn!Java_COM_activesw_api_client_ssl_AwSSLNative_getSecurityInfo+0xb447`
Any help would be appreciated!