We haven't been able to build NativeActivity-based apps (like the
android/qa/sc and anroid/qa/desktop thingies) since we switched to
DISABLE_DYNLOADING and a single DSO liblo-native-code.so anyway.
No lo_main() any more. <sal/main.h> should not be included ever when
compiling for Android of iOS now.
Lots of stuff binned from vcl's androidinst.cxx, in the (vain?) hope
that it will reduce the amount of never invoked GUI code that gets
linked in.
Change-Id: I25f584864c40110774c728a23151e089620442d9
As we don't use any dlopen() etc wrappers now with just one single
DSO, we have no use for the library search path either.
Change-Id: Ifaf11c4785a90fe5c7dafb3310bc7933ea31238c
We gzip them separately in the Makefile and the gzipped result will be
stored without (further) compression in the .apk.
Use this to store the ttf font files. Shaves off a bit .apk size.
This might seem a bit odd way to do it, why not store these files in
the normal Zip compressed fashion in the .apk? It seems hard to tell
Ant (based on path, not extension) what files to compress and what
not, so we have to keep telling it to not (further) compress any files
at all.
Change-Id: I0d40d8811e6c9df6b28c285845b1db225507f5d4
Use a version script ("version map") that exports only the Java_* and
JNI_OnLoad symbols that the JNI machinery needs. No non-dynamic
symbols are needed (in the .so that goes into the .apk; the one kept
locally for debugging is not stripped).
Change-Id: Ie874e59c593ec9e5d08ba369612cef1a3ea85fe4
IN this branch these changes are not conditional. Unclear yet whether
this is what we finally will want to use or not. Maybe should make
these changes conditional and do this stuff in master instead?
Change-Id: I379d570a0e00648d295c675fd90eba6594ba3182
Serialize the Ant cleaning and building of android/abs-lib so that one
Ant is not cleaning it while another is building something that
depends on it.
Change-Id: I22fde47bf84208fa129b8f6a65a2314c885451a0
Modify DocumentLoader correspondingly. Take Android bug 32588 into
account.
Ideal would be to extend the XDevice stuff, or something, so that one
could hand it a pre-allocated RGBA buffer into which the
drawing/rendering would go. Then one could get rid of the silly
convert-to-BMP phase, which prefixes the bitmap data with BMP and DIB
headers (and thus, I guess, has to copy and allocate another
copy). Will see.
Change-Id: I4597cd933db8faa8105dc8f19638d712d5d2238a
Sorry for the large unstructured commit. But hey, the Android code is
experimental so far.
Extract the native lo-bootstrap code into a fairly normal library
built in sal. (Previously it was the JNI part of the "Bootstrap" app.)
Just linkink normally to liblo-bootstrap from C++ code that uses it
works fine, no need to do a dlsym lookup.
Bootstrap is still a subclass of NativeActivity and can thus still be
used as an "app" (to start unit tests, or whatever), but can also be
used from some other app's Java code to just get access to the
lo-bootstrap native methods.
Introduce a new top-level "module", android, for Bootstrap and the
experiments with DocumentLoader.
Note that the experimental DocumentLoader app still crashes. It can't
create the com.sun.star.frame.Desktop instance.
I spent lots of time debugging in the painfully inadequate
ndk-gdb. (Even the newer gdb build from the "mingw-and-ndk" project is
quite crappy in many ways.) I should really experiment with
corresponding code on a normal platform first before even trying on
Android. Basically, I think that if I just can get the concept of Java
code that instantiates and uses LO components *in-process* working on
a normal desktop platform, it should work on Android, too.
