errore Android: Impossibile leggere i descrittori di file di input canale dal pacco

Question

ho fatto un'applicazione per Android che funziona più o meno così:

• applicazione comunica con le informazioni di servizio Web e trasferimenti (non i file)
• posso passare a un'altra schermata utilizzando Intent e startActivity

Sfortunatamente, a volte l'applicazione si blocca con il seguente errore nel diversa attività:

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) 

Ma non so cosa significa questo errore perché non lavoro con i file. Qualche idea?

Answer 1

Questa domanda sembra essere la stessa di Could not read input channel file descriptors from parcel, che era (erroneamente) chiusa come off-topic. È anche più o meno uguale a Could not read input channel file descriptors from parcel crash report. Sfortunatamente quelle domande non hanno ottenuto una risposta soddisfacente (e sufficientemente generale), quindi proverò comunque.

descrittori di file sono utilizzati in più posti in Android:

• Sockets (sì, le connessioni di rete aperte sono "file" troppo);
• I file reali (non necessariamente file su dischi, potrebbero anche essere istanze android.os.MemoryFile);
• Pipes-Linux li utilizza ovunque, ad esempio il tentativo di aprire pipe, che ha provocato l'eccezione, è stato probabilmente richiesto per inviare eventi di input tra il processo IME (tastiera) e l'applicazione.

Tutti i descrittori sono soggetti a shared maximum limit; quando viene superato il conteggio, la tua app inizia a subire problemi gravi. Avere il processo muore è lo scenario migliore in tal caso, perché altrimenti il ​​kernel avrebbe esaurito la memoria (i descrittori dei file sono memorizzati nella memoria del kernel).

Potrebbe non essere possibile risolvere i problemi con i descrittori (file, connessioni di rete). Devi chiuderli il prima possibile. Potresti anche avere problemi con perdite di memoria - oggetti che non vengono raccolti con garbage collection quando dovrebbero (e alcuni oggetti trapelati possono a loro volta trattenersi sui descrittori di file).

Il tuo codice non deve essere colpevole, le librerie che usi e anche alcuni componenti di sistema possono avere bug, che portano a perdite di memoria e perdite dei descrittori di file. Vi consiglio di usare Square's Leak Canary -una libreria semplice e facile da usare per il rilevamento automatico di perdite (beh, almeno le perdite di memoria, che sono più frequenti).

Answer 2

L'arresto anomalo potrebbe essere causato da troppa attività sul dispositivo che ha come conseguenza il sistema che ha esaurito i descrittori di file. Sebbene non sia possibile dichiarare file o descrittori di file nel codice, vengono utilizzati internamente dal sistema e il numero utilizzato aumenta con il numero di attività, servizi, thread, ecc. La traccia dello stack è molto simile a molte tracce dello stack in AOSP issue 32470. Un primo passo verso la risoluzione del crash potrebbe essere quello di rivedere il tuo design per confermare che non stai creando un numero eccessivo di thread/attività/servizi/ecc.

Si potrebbe anche provare a eseguire con StrictMode.VmPolicy attivato per vedere se le perdite di risorse.