Updates

Change-Id: I8e859eb34a053ac0efefc566fde002aef963b520

README.Android

@@ -1,6 +1,9 @@
 Android-specific notes
 
-* Getting something running
+Note that this document has not necessarily been updated to match
+reality... 
+
+* 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/org.libreoffice...libfoo.so
@@ -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

README.cross

@@ -332,6 +332,11 @@ particular) and Mac OS X. The Android cross-buld tool-chain (the
 X. Sure, for Windows, too, but trying to cross-compile LO from Windows
 will probably drive you insane.
 
+You will also need the SDK as full "make" also builds a couple of
+Android apps (written in Java). Use the "android" tool from the SDK to
+install the SDK Tools, SDK Platform Tools, the API 14 SDK Platform,
+and the Android Support Library. (Hopefully that list is enough.)
+
 Here is an autogen.lastrun for Android, when cross-compiling from Mac
 OS X 10.8 with Xcode 4.4.1:
 
@@ -348,22 +353,17 @@ OS X 10.8 with Xcode 4.4.1:
 
 And here is an autogen.lastrun for Android when cross-compiling from Linux:
 
-CC_FOR_BUILD=ccache gcc
-CXX_FOR_BUILD=ccache g++
---with-android-ndk=/home/tml/android-ndk-r7b
+--with-android-ndk=/home/tml/android-ndk-r8b
+--with-android-ndk-toolchain-version=4.6
 --with-android-sdk=/home/tml/android-sdk-linux_x86
 --with-ant-home=/opt/apache-ant-1.8.2
 --build=x86_64-unknown-linux-gnu
 --disable-zenity
 --disable-python
 --with-distro=LibreOfficeAndroid
---with-num-cpus=1
---with-max-jobs=1
 
 And here is an autogen.lastrun for Android when cross-compiling to x86 from Linux:
 
-CC_FOR_BUILD=ccache gcc
-CXX_FOR_BUILD=ccache g++
 --with-android-ndk=/opt/libreoffice/android-ndk-r8b
 --with-android-ndk-toolchain-version=4.6
 --with-android-sdk=/opt/libreoffice/android-sdk-linux