Hi, We are developing an Android Service that communicates with an HTTP backend, and offers its services to other apps via IPC / AIDL.
I was therefore quite surprised to discover that if the client app does an IPC to the bound service and the bound service then does a network call, this will actually lead to a NetworkOnMainThreadException in the client app. The bound service and the client app run in separate processes (separate APKs), and the service stub that implements the AIDL interface does not actually run on the main thread, but on a Binder thread. I verified that by comparing Thread.currentThread() with the main looper thread. I am well aware of the reasons why blocking activity should not happen on the main thread, and I'm also aware that a started Service runs on the main thread, but this is a different scenario. It makes sense to me that IPC operations that result in blocking network activity should not be executed in the app's main thread. I just find it surprising that this activity that is executed on the service's binder thread bubbles up to client in this way. It's not documented anywhere, at least not where I could find it. Should AIDL methods that end up in network activity always be asynchronous then, and take a callback object as argument? Or should instead the burden be on the client app to perform the service invocation in an AsyncTask or similar? I also have an Android Studio project with a minimal app and service that exposes a single AIDL method that just downloads a URL from the Internet to verify this behavior. Kind Regards Alex -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/aac38f45-3e49-4928-9abb-153d9e8dc035%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
