Change-Id: I8ce6621ad9e1971a0d586e324d49e9a209857057
Reviewed-on: https://gerrit.libreoffice.org/13307Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I747d3e9d86f1a50b8e951c0feb351072d432cda0

Change-Id: I33b639b3505d5db2ea8b708d80e68e576ec53308

Change-Id: Ie370161e51ff83cb605bc57d317ff945404e5611

Also hide copy ctor and assignment operator of all derived classes, to
ensure that Clone() is the only method to make copies of them.

Change-Id: Icb3b50c63b086abe8c9add32e3041fe19692d20b

Change-Id: I87e63008fe7c6db62c18bf461dc4dcda733393ac

Change-Id: I510e0d601e293ed8e013a0273d5ae0f9be078d8a

Change-Id: I00f3ed059bd633e662e5bee09703ca505bf3b9a5

Change-Id: I277fbf522b16d9b479260df8372a5ee160adcc37

Change-Id: I924a212210703b0f6136ddefacd77d98dc89f42d

Change-Id: I6b4a7f8053adea6d86ee625201eeead188bbadcc

Change-Id: I6a6e702e243b389f1c487b6b5390f28a4292cc74

Change-Id: Ic020d9604814213e13c339b07b6e74de77a9f400

Change-Id: I2f7967ee20ad71b58e2b0dc7f182769499910373

Change-Id: Ia2ed94dbbb43d2e768da5af5ca7a51f5cda5bae0

Using direct ByteBuffer is much nicer option to store or send
pointers between C(++) code and Java via JNI as it handles endiness
and pointer size for us. Using "long" type can have unexpected
results in 32-bit architectures (mostly Android). This was causing
grief especially when Android introduced support for 64-bit
architectures starting with SDK 19.

Change-Id: Ie92d0f913b668e1724e846d70d1820445d9cb086

Change-Id: I7688968e92ae4b3d6fef19c4544ae91bdcd8b1b9

Change-Id: Ib003da5c7fec7fc3783f01a33a63deb384c7e770

Change-Id: Ifc7b18e173b0c91c24a53fad9c35ac3a34a4b33e

Change-Id: Id90680d3b207973b55927add1c91111268bb2a48

Change-Id: Iefab77e543606cfad937a79743fb3b9a68a0f2a2

Change-Id: Ia8516da556b3736f34b366e2eb89ad8bbd7bafc1

DirectBufferAllocator is responsible to allocate buffer. We used
Fennec JNI based allocation (and freeing) because of overallocation
bug in some Android versions. With this the VM based allocator
implementation is added and used by default because of bugs that
happen in newer Android versions (specifically when ART is used
as the Android VM).

Change-Id: I07eb364fd1647b3a09d1568d4fef82398a02dfeb

Change-Id: Ied2687d334f7d1ff9ff2f3cb6664848d50814b7c

Change-Id: Ie172f60a7134173462ff9711a40dc74c94ad8206

Change-Id: If85c6a86434c0aa32d188a0f128f6b6cd613bbb5

Change-Id: I1b1891f0d7d7b8aa407e7da346ff5f8e3cbe8657

It apparently contains color schemes and stuff that the code wants access to
here and there.

Change-Id: Ie3f0de5e3846df99a02a2693156679cc6c010d10

Change-Id: I9e5bff735b0035c147e10ae066da3a4873d66749

We are experimenting with a pruned configuration database in the desktop case,
and letting the exception propagate here killed the document loading.

Change-Id: I59e5d016617c17c2bc36de2fd69c6691bfa6b135

Change-Id: Ib9cf1a47eb20bd28d954ddcded89f67cf6865f1c

Change-Id: I379601099bda928b9eeeaeb29030bc009e3cbbf2

Change-Id: I83a395c628b00b6ca96c93d5d5362ea750e57b2b

Change-Id: I290e2c84b17b9b5063139c6027b72f6cd3a78a99

Change-Id: I1e71b8a6348301cd5b3fed0ae8b3346ae3e07d8e

Change-Id: Ie6347ed6b9c1b8bee7a08950d5c67d4a2039fba5

Change-Id: I4d819f59ecb2462aee5998628ad034657bf3b0f9

Change-Id: I43c7725b88c9326e269abc277f42e47c08acefb5

Change-Id: Iaada020e85a8d2557e270f7d1514f2260ffb2af0

The "bootstrap" errors tend to end up being displayed in some error dialog
attempt which of course does nothing on mobile platforms, and that crack seems
to crash on Android even, so this should give us some chance to get some idea
at least what the code thinks is wrong...

Change-Id: I070b017baf042ff692766d1efd1511e1addb6ecf