Thank you for your answer. On 25 Nov., 19:14, "Dianne Hackborn" <[EMAIL PROTECTED]> wrote: > A oneway interface currently only applies when an IPC is needed to go > through the interface -- that is when the callee and caller are running in > different processes -- and is handled by Binder, the low-level IPC > transport. >
When I wrote my message yesterday, I had two services in the same APK. They were BOTH defined in the AndroidManifest.xml with the attribute android:process=":remote". I expected that the services will run in different processes, because I thought android:process=":remote" will automatically place each service in its own process. The FLAG_ONEWAY option didn't work while the services were communicating with each other. Today I edited the APK's AndroidManifest.xml and now only one of the both processes has the android:process=":remote" attribute in its <service> tag. Now the asynchronous communication works in both directions with the FLAG_ONEWAY option in the transact()-method of both AIDL interfaces. I read the documentation about android:process. I understood that in case we define two services inside one APK with the android:process=":remote" attribute, then the both services are inside the same process because the attribute refers to the same process name. If a developer want to have each service inside one APK in its own process, she/he has to declare the android:process attribute like that : android:process=":Service_Process_Unique_Name_For_This_APK". In this way the asynchronous communication between services in own processes in Android is possible. I hope the fact each service run in separate process does not have enormous and destructive impact on Android's performance and runtime environment. > When two interfaces are in the same process, calls on them are just direct > function calls into the other object, so there is no way to introduce > asynchronicity. I'd like to do the user-space work to allow for async local > interfaces, but don't know when that may happen. In the meantime, what we > generally do is use a Handler on the receiving side to schedule the work in > another thread so that all calls into the object are async. > I shall probably also take a look at the possibility for Handler usage. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
