Ugly duplication of the list if components. Could obviously do some
elegant refactoring to have each component mentioned just once. But on
the other hand, this is just a temporary way to build this unit test
app, no? If/when eventually gbuildifying this, the data from the
gb_CppunitTest_add_components calls in the correspondig
CppunitTest_FOO.mk files can be used, one hopes.
Add a --with-android-sdk switch, and make that and the
--with-android-ndk mandatory when building for Android. Automatically
create a proper android/sc/qa/local.properties file (which points to
the SDK) for Ant.
Restore the Android ARM code generation related flags that I think we
want to use (that used to be mentioned in README.cross but were
accidentally dropped) to the automated setting of CC and CXX.
Berkeley DB is used for help index and extension database. (Possibly
only for a backward-compatible format of the latter, I am not sure.)
Neither use makes much sense on Android and iOS.
The existing help is for LO on desktop OSes anyway, help for LO-based
apps on iOS and Android will naturally be quite different.
On iOS there will definitely be no "extensions", and probably we don't
want to bother with such on Android either.
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.
Start of an app to just load some document. Uses API from the
org.libreoffice.android.Bootstrap class.
Not sure what is the sanest way to build an app like this. It needs a
bunch of shared libraries of course to be copied into libs/armeabi-v7a
so that they get included in the .apk. Perhaps a Makefile similar to
the one for lo-bootstrap might be good?
But for debugging the Java code Eclipse is the way to go (?), and to
be able to do that Eclipse wants a "project". So should this then be
built only through Eclipse? Can one build Eclipse projects from the
command line?
