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

Change-Id: I5dd7cf6ede401b0271296d4f76df266ec4680f74

Change-Id: Iffdb3d72b24b44cb895f1729aadbbae1802e80bc

Change-Id: Ibd0cc43ff210ffaae291f4f4467ba8ebe265c446

Change-Id: I73850d2b2ea6ff4376e25e0be39c65c35328a9a6

Change-Id: I533f1177ff7de2409cdca90f35788d057a5fc3e5

Change-Id: If2758fa42b484a5afbe0d358a3d4533c68189697

Change-Id: I8cf382e7f5f5ed9c797be9ec2b42f0d7f9f0b0ce

Change-Id: I0177a0f50ba65553773f43a28e8790f7e1f8de9b

Change-Id: Iaadb8aef9e10b378fca844fa323e0a1ae369d31c

Change-Id: Iff55c88a365859400e87f3333735e54ba59811b6

Again, the motivation is that dumper for something in editeng should be
in that module as well, before home-grown dumpers are invented and
duplicated e.g. in all sw/sc/sd.

Change-Id: Icfeed9549efbd80226ff04e9070766188cc8646e

...looks like loplugin:saloverride has problems detecting missing overrides in
case of covariant return types

Change-Id: I08f2f67a33cd1cfaf9308cd87d7a5f92203980ed

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