Do not assume WebView is running on the main thread.

Cherry pick of Change-Id: I981136571782352889684e4c3181d8cc22a1679d

WebView will run at most one UI thread per process, but that
thread is not necessarily the main thread.

If the first WebView that an app constructs is on the main thread,
then we will bind Chromium's notion of the UI thread to the main
thread. This mitigates the risk introduced by this refactoring for the vast
majority of apps that create their Views on the main thread.

In the case that the WebView is created on a background thread, we delay
binding of Chromium's notion of the UI thread until we get a clear
signal from the apps usage of WebView that it is intended to use that
background thread as an Android UI thread.

In the case that the app does not intend to use the thread it creates
the WebView on as an Android UI thread, we defer as long as possible
before we are required to run operations that require Chromium to be
started, at which point we bind to the main thread. This covers the case
that an app creates WebView on a background thread to read some state
from it (e.g. the user agent) and then later intends to use WebView
as a View on the main thread.

This change does not support:
 - Apps that create more than one Android UI thread in the same process
 and expect to use a WebView as a View on both of them.

Bug 10932261

Conflicts:
	chromium/java/com/android/webview/chromium/WebViewChromium.java

Change-Id: Ief406e30d12b201b6cac2c10c73a0aa0631ca900
4 files changed
tree: f0f8f56edaf97d3e72950b561af783bfb5152719
  1. chromium/
  2. Android.mk