I realize your original comment captured what I was trying to say just fine, so I'm just updating the bug summary instead.

Also +boliu@ for Android expertise. I don't know off-hand, is it actually necessary that the Java ChildProcessLauncher run on the main thread, or can we move it?

We tried to move as much of launching child process to the launcher thread as possible. But these two callbacks from android are still on the UI thread and can't be moved without an android OS change:
https://cs.chromium.org/chromium/src/base/android/java/src/org/chromium/base/process_launcher/ChildProcessConnection.java?rcl=4f9c35c3635144e2c2d1b87d09cbcf076d138b66&l=144

This has come up before in the context of performance when the UI is busy doing work during start up. I have requested a new API that let us control the thread where those callbacks happen in the context of performance for site isolation, but at best that's going to be new in Q.

So can't really do much right now, and synchronous IPCs from UI have to take care to make sure the process is started already for the foreseeable future

Cool, thanks for the confirmation and additional details. I think in
practice this only affects test environments, and we have a suitable
workaround there.

And FWIW... we could probably hack up a way to allow the
ChildProcessLauncher to be entered during sync Mojo waits if we really have
to. Mojo's sync waiting infrastructure allows for arbitrary WaitableEvents
to be added to the set of waiting primitives[1]. We could have the launcher
thread signal an event to wake up the main thread and push launch forward.

(actual citation for above)

[1]
https://cs.chromium.org/chromium/src/mojo/public/cpp/bindings/sync_handle_registry.h?rcl=4f9c35c3635144e2c2d1b87d09cbcf076d138b66&l=47

The signal is on the UI thread though. I can't see that working in my head..

Ah I think UI get it. So this is a Binder IPC dispatched by the system directly, presumably via some Looper machinery? And I guess we have no way hook into the Looper and give it some something it can call synchronously every time it schedules work?

> So this is a Binder IPC dispatched by the system directly, presumably via some Looper machinery?

Surely that's the underlying implementation, but at the android API level, it's just an opaque callback and probably shouldn't assume much more than that. :/

> I guess we have no way hook into the Looper and give it some something it can call synchronously every time it schedules work?

I don't see any API to observe having tasks appended to the queue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b6be5ff6a2530bfab33340805d437fa9d2c1916

commit 4b6be5ff6a2530bfab33340805d437fa9d2c1916
Author: Clark DuVall <cduvall@chromium.org>
Date: Mon Nov 05 18:21:37 2018

Make sure network process is started before making sync calls

This prevents a deadlock on Android, see bug for more details.

Bug: 901026
Change-Id: I768be1479205d5efd3dbede943573a4558957297
Reviewed-on: https://chromium-review.googlesource.com/c/1313112
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605388}
[modify] https://crrev.com/4b6be5ff6a2530bfab33340805d437fa9d2c1916/content/public/test/content_mock_cert_verifier.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f742bcbd77743ff14bde036ddbd8aab2dc4b4947

commit f742bcbd77743ff14bde036ddbd8aab2dc4b4947
Author: Clark DuVall <cduvall@chromium.org>
Date: Wed Nov 07 17:16:20 2018

Add browsertest for sync call deadlock on Android

This also enables NetworkServiceRestartBrowserTests on Android, since
OOP NS is supported now.

Bug: 901026
Change-Id: If66c1fcd7d0286fd2bf545dc406e541c69fd77a8
Reviewed-on: https://chromium-review.googlesource.com/c/1313111
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606069}
[modify] https://crrev.com/f742bcbd77743ff14bde036ddbd8aab2dc4b4947/content/browser/network_service_restart_browsertest.cc
[modify] https://crrev.com/f742bcbd77743ff14bde036ddbd8aab2dc4b4947/content/test/BUILD.gn

I'm assigning this to Bo for now since he's the expert on this. This isn't high priority right now though, since this is only a problem for tests at the moment.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2f78cba78b01953a4d828cc00b4233eee090f93b

commit 2f78cba78b01953a4d828cc00b4233eee090f93b
Author: Bo Liu <boliu@chromium.org>
Date: Sat Dec 08 01:28:12 2018

Avoid UI work for process launching where possible

In N, a hidden API Context.bindServiceAsUser was added that takes a
Handler parameter that allows the caller to control which thread the
ServiceConnection callbacks happen.
https://android.googlesource.com/platform/frameworks/base/+/691546e5b7f94a6e2d76630ee1287e0b9c69e7a8

For chromium's use cases, using Process.myUserHandle should be the
correct UserHandle. Only need reflection to look up this hidden method,
so reflection is relatively simple. So use this method on N and up.

Note the N implementation did not add a ContextWrapper implementation,
so we need to manually unwrap the Context. It was added to
ContextWrapper in Android O:
https://android.googlesource.com/platform/frameworks/base/+/6192bff1fc3044f6aef5f775f322e640a129ca54

Bug: 901026
Change-Id: Icd97e6774f85d9ad0d4b13af6d0214658d3730dd
Reviewed-on: https://chromium-review.googlesource.com/c/1364294
Commit-Queue: Bo <boliu@chromium.org>
Reviewed-by: ssid <ssid@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614898}
[modify] https://crrev.com/2f78cba78b01953a4d828cc00b4233eee090f93b/base/BUILD.gn
[add] https://crrev.com/2f78cba78b01953a4d828cc00b4233eee090f93b/base/android/java/src/org/chromium/base/process_launcher/BindService.java
[modify] https://crrev.com/2f78cba78b01953a4d828cc00b4233eee090f93b/base/android/java/src/org/chromium/base/process_launcher/ChildProcessConnection.java