Age | Commit message (Collapse) | Author |
|
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
|
|
Change-Id: I3e3162474db1edef3b92e252b249fe373dedbbfd
|
|
Change-Id: I0da75df61d129aaaf03ac546fcf1e5dbcff9d404
|
|
Does not work, though, we end up with a crash that is hard to debug thanks to
the rubbish tool-chain.
Change-Id: Ie1954e35e649fac8dd106f0ccbc6951c4a6c1c63
|
|
As we call AttachCurrentThread() in the constructor, it seems logical to call
DetachCurrentThread() in the destructor. Some warning messages in the logcat
indicated that DetachCurrentThread() hadn't been called for a thread that
died.
Actually I would prefer to call both AttachCurrentThread() and
DetachCurrentThread() in the actual thread function, instead of somewhat
haphazardly and imlicitly in the AndroidSalInstance constructor and
destructor. Do we know for sure that the lifetime of the AndroidSalInstance
singleton (is is a singleton, right?) is 1:1 coupled to that of the LO "main
thread"?
Change-Id: Ifcc0e0b9af88b19389c416c5646499d44ad0e941
|
|
I assume, for lo_destroy() to be useful at all. Not that I know for sure what
the exact intended semantics of lo_destroy() and lo_initialize() are. But I
assume that the idea is that after lo_destroy() has been called,
lo_initialize() can be called again.
Change-Id: I2dea26db150d19ed438427e1c119a5297b9bc9c3
|
|
It is invalid in case lo_destroy() has been called.
Change-Id: I45533b66d32fc650e48748da8ea1d2f2aaa381e0
|
|
The preferences activity doesn't work, so easiest not to try to use
it until it is properly implemented.
Change-Id: I4b4195f6dcafa3c99dbef1ae3044ea18ab173c21
|
|
(regression from c7c385bb8e42d2051bcf05fd75b2146fe9852317)
Change-Id: I39eca96b45ad974a7e1a6913aa811c6b03ceced7
|
|
Change-Id: I136f844c3823443a8a42eb7a6e41d3805b085bd1
|
|
but not for report components (fdo#53001)
Change-Id: Ie07e1c2993304d4deb2124e72baa7a326b587918
|
|
This reverts commit 1f22e2f954baeec825190ded03510cb6c8069d93.
in preparation for fix for fdo#65163
Conflicts:
extensions/source/propctrlr/formcomponenthandler.cxx
Change-Id: Ifa252ac66724dd3e4b257e3bb6679d9503f8a9db
|
|
Change-Id: Ib24e857b19ceb6ca721b537351e95379a0992640
|
|
...as it needs SalDisplay to be a complete type, but unx/saldisp.hxx depends on
X11 headers and can thus e.g. not be included in generic/gendata.hxx on Android.
Change-Id: Iec5f51408eef0d6eb7e2d04105a7408372b06079
|
|
Change-Id: I4ba8632e8804f7fcc3511d01b28df1728e212ced
|
|
It doesn't build on Windows. Let's exclude it.
Change-Id: I153343e49318ee2ac63f95bbe6a2feeb26a96cff
|
|
Change-Id: I14f3bd9e3abd9562f47f21319da511df475b7fdd
|
|
Change-Id: I6e3c5ac5281052b49c734b152ad4cd83021c6de9
|
|
Change-Id: I77eb186f0048a9bc335408bace96111e6cb2ca53
|
|
Change-Id: Icc47b1ead273ee02e85c35cb7ab0e06b48cc42c2
|
|
Change-Id: I6eb1287a6dcb27b2d29612f8ec71290ace62be32
|
|
Change-Id: I47eb10d425a6997d2bebaa5e56dd90543749c8b7
|
|
Change-Id: I07de79fd793051efef717b7c44c88812cefc59d5
|
|
Change-Id: I8992c9fd853b7b92e328826063b50244f9fa3544
|
|
Change-Id: I30a252d2d518a361e16050f6eeffbe4371a9c982
|
|
Change-Id: I185b03dc8b747178fc442b7748dfe40762b46d32
|
|
Change-Id: Ib64149f49072a51debff5b7c3c874a2b69f7dfc6
|
|
Change-Id: I199ad135fcb217866e8daa0797f4013f8acf4f6a
|