Needed when we use the liblo-native-code as a library.

Change-Id: Ia4d1d72f2203a96d1196d015b521201919bbb165
Reviewed-on: https://gerrit.libreoffice.org/67965
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it

arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later

Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79
Reviewed-on: https://gerrit.libreoffice.org/45163Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

using AssetsManager in both java as well as native parts allows to
handle files both with and without compression transparently

Change-Id: If02f1159c498be7ea965fd9c217410722f2dca1f

Change-Id: Id1e58547cf2b0786d7a2ca29eae8bbcdd644fdd5

Fix fallout from fe480d81.

Change-Id: I36807f0e43311e66f4ccd3542a4c064d5ccd7430

found with some minor modifications to find/find-unused-defines.sh

Change-Id: I18cc479adedc7a0dada68a4aeef08300e62631dd
Reviewed-on: https://gerrit.libreoffice.org/14194Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Id9fae6561268bb7e5a465c19bdb80124f94f4939

Change-Id: I310abed7e86f8b7153817be5ae03cc3c8fec3c50

The build does not get far before it runs into trouble in the GNU libstdc++
headers, though:

android-ndk-r10/sources/cxx-stl/gnu-libstdc++/4.9/libs/x86/include/bits/opt_random.h:33:23:
fatal error: x86intrin.h: No such file or directory

Change-Id: I9d459c64980091ba8bf5b3d631d47342625f6be9

We need to have the files extracted before we attempt to initialize
LibreOfficeKit (call libreofficekit_hook), otherwise the .rdb's are not there.

Change-Id: Ib49db7e945a709d18a063eb488a27df18fef542b

Now the LibreOfficeKit is used to actually attempt to bootstrap LibreOffice;
at the moment fails to do that.

Change-Id: I91220dbff783213bf7702e7213a5646859db4581

Change-Id: I5e1758c15684b06ab6809f62f4da6d5f50c071a9

Change-Id: I8c37b9ec45836f9c0e2dc0cf232f96f23c7c36d3

Change-Id: I318bb78b148564f64373dcb87bfb458c10f87489

Change-Id: I3c64ed78577988767a7da859e68a7f63f890f7dc

Change-Id: Ia61efc5d5ee65178fd7d868cb57eed9ba3c0519e

Leave the NativeActivity-related code in androidinst.cxx for reference for
now.

Change-Id: I760c02ea361361be2d2b69c4cad1e38311f51247

Change-Id: I37ff2164b1f0fcdc4f3fad41f344b0d73105a2c1

This reverts commit cecc9260.

Conflicts:
	sal/android/lo-bootstrap.c
	sal/inc/osl/detail/android-bootstrap.h

Change-Id: I13ab54ce5c6d67f1623b7f1923678091660d202d

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

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

Change-Id: Id9c452d9c1034f2e7969a9eae7588f2eb81a8813

Change-Id: I593e94e90971b6be681de48dce74f7df2293c10e

Change-Id: I6fa2b9a50c525fb2d8666a144409eb9a3ad2698a

Render directly to a direct ByteBuffer allocated on the Java side.

Change-Id: I2d66e4146df77e92260918a78ef22cd9b8c95384

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

Change-Id: Iafa2c1805eea2f521479dc97d5668d82b1c91bef

Change-Id: I8f99399faa3b0762bdea2aac09f1b849639cd191

Change-Id: I293fa84452f00a41f4a33d4a45eee6d1a32ff761

On a (non-rooted) device it is not possible to set the
log.redirect-stdio property so that it would be effective (i.e. read
by the Zygote process when it starts). Such redirection has to be done
in-process.

Add a (JNI-callable) method to set it up: Point file descriptors 1 and
2 at pipes that are read by a thread that logs each line through the
Android logging API. Code based on Android's own logwrapper.c.

Change-Id: Id5308293595096a44a2ffed2dbc0c252be109de7