123 lines
4.5 KiB
Text
123 lines
4.5 KiB
Text
Android-specific notes
|
|
|
|
Note that this document has not necessarily been updated to match
|
|
reality...
|
|
|
|
For instructions on how to build for Android, see README.cross.
|
|
|
|
* 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
|
|
and AVD that doesn't work. Instead start it from the console:
|
|
|
|
LD_LIBRARY_PATH=$(pwd)/lib emulator-arm -avd <Name> -partition-size 500
|
|
|
|
In order to have proper acceleration, you need the 32-bit libGL.so:
|
|
|
|
sudo zypper in Mesa-libGL-devel-32bit
|
|
|
|
Where <Name> is the literal name of the AVD that you entered.
|
|
|
|
Then:
|
|
|
|
make cmd cmd=bash
|
|
cd android/qa/sc
|
|
make clean all install
|
|
make run ; adb shell logcat
|
|
|
|
And if all goes well - you should have some nice unit test output to
|
|
enjoy. After a while of this loop you might find that you have lost a lot of
|
|
space on your emulator's or device's /data volume. If using the emulator, you
|
|
can do:
|
|
|
|
adb shell stop; adb shell start
|
|
|
|
but on a (non-rooted) device you probably just need to reboot it. On the other
|
|
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
|
|
|
|
Some versions of the NDK had a broken gdb in the way that it can see
|
|
symbols only for shlibs that were already loaded when the debuggee was
|
|
attached, so you need to carefully guess where to put:
|
|
|
|
fprintf(stderr, "Sleeping NOW!\n"); ::sleep(20);
|
|
|
|
into the code; and when you see that in logcat, you have time
|
|
to run: ndk-gdb and it will attach the process.
|
|
|
|
thread 12 # or perhaps 13
|
|
backtrace
|
|
|
|
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.
|
|
|
|
* Getting the symbols
|
|
|
|
In order to be able to debug, you also need the symbols. Currently they are
|
|
stripped using a $(STRIP) call in android/Bootstrap/Makefile.shared ; make
|
|
sure you change it only to 'cp'.
|
|
|
|
But then you need to limit the size of the resulting binary by other means,
|
|
that is strip most of the symbols (but the interesting ones) already during
|
|
the build. For that, use something like
|
|
|
|
--enable-dbgutil
|
|
--enable-selective-debuginfo="sal/"
|
|
|
|
in your autogen.input (but of course limit the --enable-selective-debuginfo
|
|
only to directories / libraries that are interesting to you).
|
|
|
|
* Common Errors / Gotchas
|
|
|
|
lo_dlneeds: Could not read ELF header of /data/data/org.libreoffice...libfoo.so
|
|
This (most likely) means that the install quietly failed, and that
|
|
the file is truncated; check it out with adb shell ls -l /data/data/....
|
|
|
|
|
|
* Detailed explanation
|
|
|
|
Note: the below talk about unit tests is obsolete; we no longer have
|
|
any makefilery etc to build unit tests for Android.
|
|
|
|
Unit tests are the first thing we want to run on Android, to get some
|
|
idea how well, if at all, the basic LO libraries 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
|
|
code.
|
|
|
|
Sure, we could quite easily build unit tests as plain Linux
|
|
executables (built against the Android libraries, of course, not
|
|
GNU/Linux ones), 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 such processs run in is completely different from that in
|
|
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 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.
|
|
|
|
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,
|
|
LibreOffice4Android and LibreOfficeDesktop) are not based on
|
|
NativeActivity any more. They have normal Java code for the activity,
|
|
and just call out to a single, app-specific native library (called
|
|
liblo-native-code.so) to do all the heavy lifting.
|