libbinder: setupPolling flushes commands

Calling setupPolling and then handling polled commands has the effect
of never telling the kernel anything, and then then waiting for it to
get back to you. While this type of (non)communication may be common
among some humans, it should not be common among our processes.

So - the general requirement for a flushCommands call by every client of
this call is lifted.

Critically, also, this means that LL-NDK users of the setupPolling
command don't also need a flushCommand. This avoids an extra API. Sure,
it may be useful to have such a command, but whenever it is used in our
tree, it is mostly used as a hack. So, hopefully this delay in adding it
will instead encourage fixes in libbinder which help avoid people
needing to understand binder internals.

Bug: 139697085
Test: use with servicemanager and boot
Change-Id: I45d19bf6b58950f9d91dd6f7dcaa94b8061d3666

2 files changed, 1 insertions, 4 deletions

diff --git a/cmds/servicemanager/main.cpp b/cmds/servicemanager/main.cpp
index b1bc6dc7d5..627dfe6382 100644
--- a/cmds/servicemanager/main.cpp
+++ b/cmds/servicemanager/main.cpp
@@ -45,10 +45,6 @@ public:
         IPCThreadState::self()->setupPolling(&binder_fd);
         LOG_ALWAYS_FATAL_IF(binder_fd < 0, "Failed to setupPolling: %d", binder_fd);
 
-        // Flush after setupPolling(), to make sure the binder driver
-        // knows about this thread handling commands.
-        IPCThreadState::self()->flushCommands();
-
         int ret = looper->addFd(binder_fd,
                                 Looper::POLL_CALLBACK,
                                 Looper::EVENT_INPUT,
diff --git a/libs/binder/IPCThreadState.cpp b/libs/binder/IPCThreadState.cpp
index 7d01e0b1c3..2eee2c40a3 100644
--- a/libs/binder/IPCThreadState.cpp
+++ b/libs/binder/IPCThreadState.cpp
@@ -629,6 +629,7 @@ status_t IPCThreadState::setupPolling(int* fd)
     }
 
     mOut.writeInt32(BC_ENTER_LOOPER);
+    flushCommands();
     *fd = mProcess->mDriverFD;
     return 0;
 }