android lỗi: Không thể đọc input file descriptor kênh từ bưu kiện

Question

Tôi đã thực hiện một ứng dụng cho Android hoạt động nhiều hay ít như thế này:

• ứng dụng giao tiếp với các dịch vụ Web và chuyển thông tin (không files)
• tôi có thể điều hướng đến một màn hình khác nhau sử dụng Intent và startActivity

Thật không may, đôi khi bị treo ứng dụng với các lỗi sau đây trong hoạt động khác nhau:

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) 

Nhưng tôi không biết lỗi này có ý nghĩa gì vì tôi không làm việc với tệp. Bất kỳ ý tưởng?

Answer 1

Câu hỏi này có vẻ giống như Could not read input channel file descriptors from parcel, được (không chính xác) đóng thành chủ đề không chính xác. Nó cũng nhiều hơn hoặc ít hơn giống như Could not read input channel file descriptors from parcel crash report. Thật không may những câu hỏi đó đã không nhận được một câu trả lời thỏa đáng (và đủ chung), vì vậy tôi sẽ cố gắng anyway.

mô tả tập tin được sử dụng ở nhiều nơi trong Android:

• Sockets (có, kết nối mạng mở là "tác phẩm" quá);
• Tệp thực tế (không nhất thiết phải tệp trên đĩa, cũng có thể là android.os.MemoryFile trường hợp);
• Đường ống — Linux sử dụng chúng ở khắp mọi nơi, ví dụ như nỗ lực mở ống dẫn đến ngoại lệ của bạn, có thể được yêu cầu gửi các sự kiện đầu vào giữa quá trình IME (bàn phím) và ứng dụng của bạn.

Tất cả các trình mô tả phải tuân theo shared maximum limit; khi vượt quá số lượng đó, ứng dụng của bạn bắt đầu gặp phải sự cố nghiêm trọng. Có quá trình chết là kịch bản tốt nhất trong trường hợp này, bởi vì nếu không hạt nhân sẽ hết bộ nhớ (các bộ mô tả tệp được lưu trữ trong bộ nhớ hạt nhân).

Bạn có thể gặp sự cố với bộ mô tả (tệp, kết nối mạng) không bị đóng. Bạn phải đóng chúng càng sớm càng tốt. Bạn cũng có thể gặp vấn đề với rò rỉ bộ nhớ — đối tượng không bị thu gom rác khi cần (và một số đối tượng bị rò rỉ có thể lần lượt giữ lại các bộ mô tả tệp).

Mã riêng của bạn không cần phải có tội, thư viện bạn sử dụng và thậm chí một số thành phần hệ thống có thể có lỗi, dẫn đến rò rỉ bộ nhớ và rò rỉ bộ mô tả tệp. Tôi khuyên bạn nên sử dụng Square's Leak Canary —một thư viện đơn giản, dễ sử dụng để tự động phát hiện rò rỉ (tốt, ít nhất là rò rỉ bộ nhớ, thường xuyên nhất).

Answer 2

Sự cố có thể do quá nhiều hoạt động trên thiết bị dẫn đến hệ thống hết bộ mô tả tệp. Mặc dù bạn không thể khai báo tệp hoặc bộ mô tả tệp trong mã của mình nhưng chúng được sử dụng nội bộ bởi hệ thống và số được sử dụng tăng với số lượng hoạt động, dịch vụ, chủ đề, v.v. Dấu vết ngăn xếp của bạn rất giống với nhiều dấu vết trong AOSP issue 32470. Bước đầu tiên để giải quyết sự cố có thể là xem xét thiết kế của bạn để xác nhận rằng bạn không tạo quá nhiều luồng/hoạt động/dịch vụ/v.v.

Bạn cũng có thể thử chạy với StrictMode.VmPolicy được bật để xem tài nguyên có bị rò rỉ hay không.