Binder: address race condition where a new transport may attempt to s…

[mateusazis]

…tart despite the server having shutdown already.

Part of #10897.

[mateusazis]

I didn't find a good way to test this. I looked into BinderTransportTest, but calling transport.shutdownNow() forbids me from starting new transports for that service. HostServices attempts to spin up a new server intead. Let me know if you have any ideas.

[jdcormie]

How about:

// After reporting ServerListener#serverShutdown() above, the InternalServer API contract forbids us from creating any new ServerTransports. But any incoming SETUP_TRANSPORT transactions that were already in-flight before shutdown are still going to arrive here. We must not accept them and the easiest thing is just to ignore.

[jdcormie]

I didn't find a good way to test this. I looked into BinderTransportTest, but calling transport.shutdownNow() forbids me from starting new transports for that service. HostServices attempts to spin up a new server intead. Let me know if you have any ideas.

Yeah this is basically AbstractTransportTest#serverNotListening(), which BinderTransportTest currently @Ignores (#8931). Plus the extra challenge of getting your SETUP_TRANSPORT through after shutdown() but before hostServiceBinder.detach();.

It would be difficult but you could:

1. substitute in a different implementation of LeakSafeOneWayBinder that delayed detach() actuation.
2. Instead of silently dropping SETUP_TRANSPORT after shutdown, have BinderServer reply (over callbackBinder) with SHUTDOWN_TRANSPORT. Kind of like a GOAWAY response.

We could then just re-enable AbstractTransportTest#serverNotListening().

[mateusazis]

No longer needed since #11260