What are the ordering guarantees of AIDL "oneway" remote calls?

Question

AIDL methods and interfaces marked with the "oneway" keyword are asynchronous Binder calls for remote processes, and it is said that the ordering of the calls is not guaranteed. On the other hand, the last comment of Dianne Hackborn (author of Binder) in this thread ( https://groups.google.com/forum/#!topic/android-developers/FFY-hg2Jx0M) says:

"ordering of delivery is tied to the target object (so you can receive calls on different interfaces out of order)"

Which seems to suggest, that calls to the same interface keep their order.

Can anyone clarify this?

Answer 1

As far as I remember, all transactions in Binder are synchronous, meaning that a client initiates a call and waits a reply from a server. However, in case of oneway communication, the server received such call simply returns, thus, this type of communication is oneway.

The calls in a service are processed in different Binder threads, thus, in case of synchronous communication you can be sure that the client will receive the reply after the request (because the client waits for the response from the server). However, in case of oneway call it can be a case that your requests from the client will be processed in different Binder threads. That is why, to my point of view, it is written that the order are not defined.

Answer 2

AIDL calls are synchronous by default which means the client will be in waiting state until method returns but in case we use "oneway" keyword,the method call is asynchronous i.e it returns immediately and client will receive callback later.Hence,the ordering is not defined for callbacks.

Answer 3

As a general rule, oneway calls are asynchronous and can be dispatched on different threads concurrently with no ordering guarantees. However, the system imposes special ordering guarantees on oneway calls happening on the same IBinder object: in this case the transactions will be dispatched one at a time, in order of the original calls. Note that this ordering only applies in the specific case of oneway calls on the same IBinder object. Anything else -- calls on different IBinder objects or mixing oneway and sync calls -- will not give you any ordering guarantees between them.

The way this work is that in the kernel each IBinder object has a queue of oneway transactions to dispatch. A oneway call adds to that queue (a non-oneway call bypasses the queue). Transactions are dispatched out of the queue one at a time, as each previous transaction completes. So you may see these calls being dispatched on different threads, but the system makes sure that only one is executing at a time. (Again only for a single IBinder object, oneway calls on two different IBinder objects can execute concurrently.)