path: root/README.Android
diff options
authorTor Lillqvist <>2012-09-10 14:28:34 +0300
committerTor Lillqvist <>2012-09-10 14:29:53 +0300
commit0f9f8ef8b07cad66be20e705d4ad0a5cb6394818 (patch)
tree11f29b5e507001660c9288ee9fe3b78b04051204 /README.Android
parent090901874f58997f23dda1cdfac5462788073dfb (diff)
Change-Id: I8e859eb34a053ac0efefc566fde002aef963b520
Diffstat (limited to 'README.Android')
1 files changed, 20 insertions, 2 deletions
diff --git a/README.Android b/README.Android
index 633ec52f2f35..04d1684b43bb 100644
--- a/README.Android
+++ b/README.Android
@@ -1,6 +1,9 @@
Android-specific notes
-* Getting something running
+Note that this document has not necessarily been updated to match
+* Getting something running on an emulated device
Create an AVD in the android UI, don't even try to get
the data partition size right in the GUI, that is doomed to producing
@@ -29,6 +32,12 @@ hand, this phenomenon might not happen on actual devices.
and continue onwards & upwards.
+* What about using a real device?
+ That works fine, too. You won't be able to use the "adb shell
+stop" and "adb shell start" commands to do anything, as far as I
+know. But don't seem to be necessary on a real device anyway?
* Debugging
Debugging is fun, the default NDK gdb (in v7) is busted, you
@@ -50,6 +59,10 @@ to run: ndk-gdb and it will attach the process.
may show you the native code trace.
+ In r8b the ndk-gdb seems to work a bit better, and I think it isn't
+necessary to use the mingw-and-ndk ndb-gdb any longer.
* Common Errors / Gotchas
lo_dlneeds: Could not read ELF header of /data/data/
@@ -75,7 +88,7 @@ which real end-user apps with GUI etc run. 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
+virtual machine. Yes, you can also have apps where all *your* code is
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.
@@ -84,6 +97,11 @@ 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.
+Anyway, our current "experimental" apps (DocumentLoader and
+LibreOffice4Android) are not based on NativeActivity any more. They
+have normal Java code for the activity, and just call out to native
+libraries to do all the heavy lifting.
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