On Android, when an app is installed, arbitrary files bundled in the
app won't be unpacked into actual separate files in the file
system. They will exist only as archive entries in the .apk file
(which is a zip archive).
The SDK tooling puts such files under the /assets folder in the
.apk. The LibreOffice bootstrapping code for Android maps the .apk
file into memory.
osl_openFile() knows about the /assets special case, and uses a
separate abstraction for such memory-mapped files.
Obviously, when producing an .apk, one needs to make sure these
bundled files are not compressed, if one wants to be able to use them
directly from the memory-mapped .apk file. We do that in our test and
sample Android projects.
When mapping such files under /assets , just return a pointer to the
file's location inside the mapped .apk archive.
We can't use the old osl_unmapFile() on such mapped files, as that
would unexpectedly unmap fairly arbitrary pages of the .apk mapping,
wreaking havoc on later use of the same pages.
So, introduce a new osl_unmapMappedFile() function that takes also the
oslFileHandle originally passed to osl_mapFile(). Use this instead in
the few places where the code actually called osl_unmapFile(). Make
sure osl_mapFile() is nonexistent on Android.
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.
It too suffers from the same problem as operator==: Compares name
pointers, not name strings. Thus with two things to patch, had to
refactor it.
(before() doesn't seem to get called when running the bridgetest at
least, though.)
Noticed that there is no need to wrap the replacement asm snippets
with dummy C functions. Just having them at the outermost level in the
source file works as expected.
A compile time check ensures the common case of streaming just a plain
C-style string literal still produces reasonably compact call-site code.
The format-string variants are still available in sal/detail/log.h, but
only to be used in obsolete osl/diagnose.h etc., and going to be removed
again eventually.
* New SAL_INFO..., SAL_WARN... macros.
* New SAL_STREAM supersedes OSL_FORMAT.
* oustringostreaminserter.hxx moved from unotest to rtl (and always UTF-8 now).
* TODO to enable GCC __attribute__((format)) in sal/log.h (requires call-site
cleanup).
* Further functionality in tools/debug.hxx (DBG_MEMTEST, DBG_CTOR, etc.) not yet
addressed.
* Some replacements tools String -> rtl::OUString.
