The SDK tooling that constructs .apk packages doesn't put empty
directories in them. Which makes sense I guess. "Hidden" files (like
.gitignore) are also skipped. So a directory like
sc/qa/unit/qpro/indeterminate does not show up at all.
So, we must pretend that any opendir() of a directory under /assets
succeeds. If the .apk doesn't contain any files in such a directory,
treat it as existing but empty. We can't know if the corresponding
directory from which /assets was constructed actually does exist but
is empty or if it doesn't exist.
Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to retrieve it from there. Store it in the AndroidSalInstance.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the name of that file in NDK/sources. "android.h" sounded to me too
grand, as if it was some universal Android header. But if we do start
to modify the android_native_app_glue stuff heavily, then it indeed
makes sense to call it something else. Until then, revert also some
whitespace changes to android_native_app_glue.c for it to be as close
as possible to the "upstream" one in the NDK, for clarity.
We must build a directory tree structure corresponding to the files in
the .apk, and use that then in lo_apk_opendir()/readdir().
We can't just return the same subdirectory once for each time we come
across an entry that has it as a prefix in the zip directory.
Use the BSD-licensed "uthash" library (just one .h file actually) from
http://uthash.sourceforge.net/ .
We used to patch in a simple "b" instruction with a relative offset
that has to fit in 24(+2) bits. Which was not enough in practice.
Now patch in a "ldr pc, [pc, #-4]" instead which loads PC from the
next word; in ARM code PC cotains the address of the executing
instruction + 8), and put the full address of the replacement code
into the next word.
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.
2011-11-30 21:52:52 +02:00
Renamed from sal/osl/android/jni/lo-bootstrap.c (Browse further)
