*dLeyna* Spent the week extending my Android native-lib-test app to handle multiple tests, and then tried plugging in everything I could find that looked like a GLib test -- any program from the Glib source tree that has "test" in its name, and a main() function. The Android tester app has a main Activity with a scrolling tty view and a few buttons. The Settings button takes you to an Activity with a list of checkboxes for enabling/disabling each test. The Start button runs the selected tests, and displays progress in the tty view. Meanwhile, any output written by the native code to stdout or stderr is visible in the log associated with the emulated device. Of the 31 native test programs I found, 2 of them fail to compile, 8 of them fail to link, 8 of them fail at run time, and the remaining 13 passed. I haven't spent any time at all yet looking into the build failures. At first glance, the run time problems include failure of mkstemp() and attempts to fork() which is a no-no in an Android app process. There may be other problems though. One tricky thing I ran into is that the test programs often include a header file that is not built out to the distribution -- a source .h file that's produced during the config stage and that differs according to the target architecture. So I have to be careful about keeping a separate copy of the configured source file for each architecture (x86/arm) and include the right one when building the Android app. So now I need to investigate all these failures, and see if I can fix any of them. I also should try pretty soon to define the Java API that will be presented to Android apps to get a better feel for the scope of this whole endeavor. -- Tom