Inbound has code to handle Binder transactions delivered out-of-order, something that can't happen (see IBinder#FLAG_ONEWAY). At the same time, it fails to handle the rare case where transactions are silently dropped.
We should simplify the message reassembly code and fail fast on gaps instead of waiting forever for a transaction that will never come. If an incoming transaction index doesn't have the next expected value, immediately close the stream (with DATA_LOSS? UNAVAILABLE?). This avoids a hang, allowing callers to retry sooner.
Inbound has code to handle Binder transactions delivered out-of-order, something that can't happen (see IBinder#FLAG_ONEWAY). At the same time, it fails to handle the rare case where transactions are silently dropped.
We should simplify the message reassembly code and fail fast on gaps instead of waiting forever for a transaction that will never come. If an incoming transaction index doesn't have the next expected value, immediately close the stream (with
DATA_LOSS?UNAVAILABLE?). This avoids a hang, allowing callers to retry sooner.