apk-based test runner work for android

testing/android/java/src/org/chromium/native_test/ChromeNativeTestActivity.java

+// Copyright (c) 2012 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.native_test;
+
+import android.app.Activity;
+import android.os.Bundle;
+import android.util.Log;
+
+// Android's NativeActivity is mostly useful for pure-native code.
+// Our tests need to go up to our own java classes, which is not possible using
+// the native activity class loader.
+// We start a background thread in here to run the tests and avoid an ANR.
+// TODO(bulach): watch out for tests that implicitly assume they run on the main
+// thread.
+public class ChromeNativeTestActivity extends Activity {
+    private final String TAG = "ChromeNativeTestActivity";
+
+    // Name of our shlib as obtained from a string resource.
+    private String mLibrary;
+
+    @Override
+    public void onCreate(Bundle savedInstanceState) {
+        super.onCreate(savedInstanceState);
+
+        mLibrary = getResources().getString(R.string.native_library);
+        if ((mLibrary == null) || mLibrary.startsWith("replace")) {
+            nativeTestFailed();
+            return;
+        }
+
+        try {
+            loadLibrary();
+            new Thread() {
+                @Override
+                public void run() {
+                    Log.d(TAG, ">>nativeRunTests");
+                    nativeRunTests(getFilesDir().getAbsolutePath());
+                    // TODO(jrg): make sure a crash in native code
+                    // triggers nativeTestFailed().

[bulach, 2012/04/12 15:51:42]

is it needed? the runner should be smart enough to detect all failures (i.e.,
essentially pexpect there should capture a [RUN] without a corresponding [OK] as
an error...).

[John Grabowski, 2012/04/13 01:11:37]

Yes, it is needed.  If we crash we have to wait for a "no activity in 60sec"
timeout which sucks.

[bulach, 2012/04/13 09:42:51]

right, sorry, I wasn't clear: rather than add yet-another failure case, wouldn't
it be sufficient to print something like:
[RUN] Native Loader Failure / LOG / [FAIL] and reuse the existing mechanism?

that would simplify the upper layers..

[John Grabowski, 2012/04/13 22:51:02]

I would prefer to make 'a test failed' distinct from 'failed to run any tests'. 
I've made the error more generic; is that OK?

+                    Log.d(TAG, "<<nativeRunTests");
+                }
+            }.start();
+        } catch (UnsatisfiedLinkError e) {

[bulach, 2012/04/12 15:51:42]

you probably need to wrap just loadLibrary, not the Thread creation..

[John Grabowski, 2012/04/13 01:11:37]

Not sure I agree; is possible loadLibrary() works but didn't resolve
nativeRunTests().  But offhand I can't say that'll throw the same exception.

+            Log.e(TAG, "Unable to load lib" + mLibrary + ".so: " + e);
+            nativeTestFailed();
+            throw e;
+        }
+    }
+
+    // Signal a failure of the native test loader to python scripts
+    // which run tests,.  For example, we look for

[Yaron, 2012/04/12 01:29:53]

s/,././

[John Grabowski, 2012/04/13 01:11:37]

Done.

+    // NATIVE_LOADER_FAILED build/android/test_package.py.
+    private void nativeTestFailed() {
+        Log.e(TAG, "[ NATIVE_LOADER_FAILED ]");

[bulach, 2012/04/13 09:42:51]

see above, we could probably reuse the existing mechanism here..

+    }
+
+    private void loadLibrary() throws UnsatisfiedLinkError {
+        Log.i(TAG, "loading: " + mLibrary);
+        System.loadLibrary(mLibrary);
+        Log.i(TAG, "loaded: " + mLibrary);
+    }
+
+    private native void nativeRunTests(String filesDir);
+}