path: root/README.Android
diff options
authorTor Lillqvist <>2011-11-11 16:44:18 +0200
committerTor Lillqvist <>2011-11-11 16:46:43 +0200
commita9d167ba98672277c1ac57c5fe54965c21c02446 (patch)
tree7d9db2076efe8b05f33ff0e6f569d9e909f42e95 /README.Android
parent305878f44bfee90c8ddba1f40b30d18150d4adde (diff)
More baby steps for Android
Diffstat (limited to 'README.Android')
1 files changed, 49 insertions, 0 deletions
diff --git a/README.Android b/README.Android
new file mode 100644
index 000000000000..540ac583d837
--- /dev/null
+++ b/README.Android
@@ -0,0 +1,49 @@
+Android-specific notes
+Unit tests are the first thing we want to run on Android, to get some
+idea how well, if at all, the basic LO libraraies work. We want to
+build even unit tests as normal Android apps, i.e. packaged as .apk
+files, so that they run in a sandboxed environment like that of
+whatever eventual end-user Android apps there will be that use LO
+Sure, we could quite easily build unit tests as plain Android
+executables, push them to the device or emulator with adb and run them
+from adb shell, but that would not be a good test as the environment
+would be completely different. They would run as root, and not
+sandboxed. We have no intent to require LibreOffice code to be used
+only on "rooted" devices etc.
+All Android apps are basically Java programs. They run "in" a Dalvik
+virtual machine. Yes, you can also have apps where your code is only
+native code, written in a compiled language like C or C++. But also
+also such apps are actually started by system-provided Java
+bootstrapping code (NativeActivity) running in a Dalvik VM.
+Such a native app (or actually, "activity") is not built as a
+executable program, but as a shared object. The Java NativeActivity
+bootstrapper loads that shared object with dlopen.
+It is somewhat problematic to construct .apk packages except by using
+the high-level tools in the Android SDK. At least I haven't figured
+out how to manually construct an .apk that is properly signed so that
+it will run in the emulator. (I don't have any Android device...) I
+only know how to let the SDK Ant tooling do it...
+A LO Android app would work would something like this:
+We have a top Java bootstrapping class that loads a small helper native
+library that implements JNI wrappers for dlopen(),
+dlsym(), and ELF header scanning coresponding to looking for DT_NEEDED
+entries with readelf.
+The Java code then loads the actual native library that corresponds to
+the LibreOffice-related "program" we want to run. For unit tests, a
+library that corresponds to cppunittester program. Then through helper
+functions in liblo-bootstrap it calls a named function in that
+This Android-specific code is for now in sal/osl/android.
+--Tor Lillqvist <>