android error: Could not read input channel file descriptors from parcel

Question

I've made an application for Android that works more or less like this:

• Application communicates with the Web service and transfers information (not files)
• I can navigate to a different screen using Intent and startActivity

Unfortunately, sometimes the application crashes with the following error in different activity:

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:135)  
at android.view.IWindowSession$Stub$Proxy.add(IWindowSession.java:523)  
at android.view.ViewRootImpl.setView(ViewRootImpl.java:481)  
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:301)  
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:215)  
at android.view.WindowManagerImpl$CompatModeWrapper.addView(WindowManagerImpl.java:140)  
at android.view.Window$LocalWindowManager.addView(Window.java:537)  
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2507)  
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1986)  
at android.app.ActivityThread.access$600(ActivityThread.java:123)  
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1147)  
at android.os.Handler.dispatchMessage(Handler.java:99)  
at android.os.Looper.loop(Looper.java:137)  
at android.app.ActivityThread.main(ActivityThread.java:4424)  
at java.lang.reflect.Method.invokeNative(Native Method)  
at java.lang.reflect.Method.invoke(Method.java:511)  
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)  
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)  
at dalvik.system.NativeStart.main(Native Method) 

But I don't know what does this error mean because I don't work with files. Any idea?

Answer 1

This question appears to be the same as Could not read input channel file descriptors from parcel, which was (incorrectly) closed as off-topic. It is also more or less same as Could not read input channel file descriptors from parcel crash report. Unfortunately those questions haven't gotten a satisfactory (and sufficiently general) answer, so I am going to try anyway.

File descriptors are used in multiple places in Android:

• Sockets (yes, open network connections are "files" too);
• Actual files (not necessarily files on disks, may as well be android.os.MemoryFile instances);
• Pipes—Linux uses them everywhere, for example the attempt to open pipe, that resulted in your exception, was likely required to send input events between IME (keyboard) process and your application.

All descriptors are subject to shared maximum limit; when that count is exceeded, your app begins to experience serious problems. Having the process die is the best scenario in such case, because otherwise the kernel would have run out of memory (file descriptors are stored in kernel memory).

You may have issues with descriptors (files, network connections) not being closed. You must close them ASAP. You may also have issues with memory leaks—objects not being garbage-collected when they should (and some of leaked objects may in turn hold onto file descriptors).

Your own code does not have to be guilty, libraries you use and even some system components may have bugs, leading to memory leaks and file descriptor leaks. I recommend you to use Square's Leak Canary—a simple, easy to use library for automatic detection of leaks (well, at least memory leaks, which are most frequent).

Answer 2

The crash may be caused by too much activity on the device resulting in the system running out of file descriptors. Although you may not declare files or file descriptors in your code, they are used internally by the system and the number used increases with the number of activities, services, threads, etc. Your stack trace is very similar to many of the stack traces in AOSP issue 32470. A first step toward solving the crash may be to review your design to confirm that you are not creating an excessive number of threads/activities/services/etc.

You might also try running with StrictMode.VmPolicy enabled to see if resources are being leaked.