Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to rettrieve that.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the file from NDK/sources that it is. "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.
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
A temporary tweak to restore build-ability; the oslDirectory
change needs a little more thought & public exposure, but rsc
no longer crashes during compile ...
Having SvFileStream call the file opening etc functions here, instead
of calling open() directly itself, means we won't have to duplicate
the Android .apk hooks there, too.
* New build prerequisite doxygen (controllable via --with-doxygen).
* Adapted various headers to slightly different doxygen documentation
syntax, but much clean up still remains to be done (i.e., warnings
emitted by doxygen fixed).
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.
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.
So that variables only used within SAL_INFO/WARN do not lead to
unused variable warnings in product builds. Also for OSL_TRACE
(which used to work that way before already); allowing to revert
a recent warning fix.
* 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.
Do the LD_LIBRARY_PATH splitting in Java, much easier, and pass the
split up path to the native setup() method.
Use lo_dlopen() in the osl_loadModuleAscii.
Harcode en-US.UTF-8 as the locale for now.
Cut down on verbose logging of stuff that already works.
Do use NativeActivity and android_native_app_glue after all.
I hope this enables us to have a "message pump" (a loop that typically
would call ALooper_pollAll()) inside the LO "program" being run, as
expected by LO code.
(On Android, a "program", even one mostly implemented in native code,
is actually a shared library loaded by the main Java code of an app.)
The android_native_app_glue code and the android_main() it calls
belongs in the bootstrap library, though. Not in SAL_MAIN_IMPL.
The earlier idea, having a "normal" Java Activity subclass, would mean
events come in as method calls to that class. To then turn those into
something the LO code can "get", we would have effectively had to
re-implement what android_native_app_glue does anyway.
