1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
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
an 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:
cd android/experimental/LOAndroid3
ant debug install
adb logcat
And if all goes well - you should have some nice debug output to enjoy
when you start the app. 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.
* What about using a real device?
That works fine, too.
* Debugging
First of all, you need to configure the build with --enable-debug or
--enable-dbgutil. You may want to provide --enable-selective-debuginfo too,
like --enable-selective-debuginfo="sw/" or so, in order to fit into the memory
during linking.
Building with all symbols is also possible but the linking is currently
slow (around 10 to 15 minutes) and you need lots of memory (around 16GB + some
swap).
You also want to avoid --with-android-package-name (or when you use
that, you must set it to "org.libreoffice"), otherwise ndk-gdb will complain
that
ERROR: Could not extract package's data directory. Are you sure that
your installed application is debuggable?
When you have all this, install the .apk to the device, and:
cd android/experimental/LOAndroid3
<android-ndk-r10d>/ndk-gdb --adb=<android-sdk-linux>/platform-tools/adb --start
Pretty printers aren't loaded automatically due to the single shared
object, but you can still load them manually. E.g. to have a pretty-printer for
rtl::OString, you need:
(gdb) python sys.path.insert(0, "/master/solenv/gdb")
(gdb) source /master/instdir/program/libuno_sal.so.3-gdb.py
* Debuggint the Java part
At the moment the code is not organized in a way that would make Eclipse or
Android Studio happy as-is, so the quickest way is to use the jdb command-line
debugger. Steps to use it:
1) Find out the JDWP ID of a debuggable application:
adb jdwp
From the list of currently active JDWP processes, the last number is the just
started debuggable application.
2) Forward the remote JDWP port/process ID to a local port:
adb forward tcp:7777 jdwp:31739
3) Connect to the running application:
jdb -sourcepath src/java/ -attach localhost:7777
Assuming that you're already in the LOAndroid3 directory in your shell.
* 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.
|