Provide dummy Android UI thread with looper for C++ unit tests

base/test/android/java/src/org/chromium/base/TestUiThread.java

Index: base/test/android/java/src/org/chromium/base/TestUiThread.java
diff --git a/base/test/android/java/src/org/chromium/base/TestUiThread.java b/base/test/android/java/src/org/chromium/base/TestUiThread.java
new file mode 100644
index 0000000000000000000000000000000000000000..fc84de410e91526beb46be4bb3fea558b6f20763
--- /dev/null
+++ b/base/test/android/java/src/org/chromium/base/TestUiThread.java
@@ -0,0 +1,46 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.base;
+
+import android.os.Looper;
+
+import java.util.concurrent.CountDownLatch;
+
+/**
+ * Set up a thread as the Chromium UI Thread, and run its looper. This is is intended for C++ unit
+ * tests (e.g. the net unit tests) that don't run with the UI thread as their main looper, but test
+ * code that, on Android, uses Ui thread events, so need a running Ui thread.

[nyquist, 2015/06/08 23:38:19]

Nit: UI*

[aberent, 2015/06/09 10:33:12]

Done.

+ */
+public class TestUiThread {
+    static boolean sStarted = false;

[nyquist, 2015/06/08 23:38:19]

Nit: private

[aberent, 2015/06/09 10:33:13]

Done.

+
+    @CalledByNative
+    private static void loop() {
+        // setUiThread can only be called once in a test run, so do this once, and leave it running.

[nyquist, 2015/06/08 23:38:19]

Nit: @{link ThreadUtils#setUiThread(Looper)}

+        if (sStarted) return;

[nyquist, 2015/06/08 23:38:19]

It's not clear to me that we are guaranteed to get the call to loop() from the
same thread every time. There seems to be a race condition here where multiple
threads could be started and the last call to setUiThread(...) would win.

Could we do something simple like using an AtomicBoolean?

if (sStarted.getAndSet(false)) return;

Or of course some other way you'd prefer to make calls to this method thread
safe.

I'd mildly argue for also adding @ThreadSafe annotation to the class at that
point to make it clear that you've thought about that case.

[aberent, 2015/06/09 10:33:12]

Done.

+
+        final CountDownLatch startLatch = new CountDownLatch(1);
+        new Thread(new Runnable() {
+
+            @Override
+            public void run() {
+                Looper.prepare();
+                ThreadUtils.setUiThread(Looper.myLooper());
+                startLatch.countDown();
+                Looper.loop();
+            }
+
+        }).start();
+
+        sStarted = true;
+
+        try {
+            startLatch.await();
+        } catch (InterruptedException e) {
+            // TODO(aberent): Auto-generated catch block

[nyquist, 2015/06/08 23:38:19]

Nit: Could we log an error message here instead of printStackTrace?

[aberent, 2015/06/09 10:33:12]

Done.

+            e.printStackTrace();
+        }
+    }
+}