Note that getPackageName() also throws NameNotFoundException, so in the
unlikely situations in case:
- package info (class containing the package version) is not found or
- the package version is not in an "a/b" form
We still just don't show anything.
Also, mark the new TextView as android:textIsSelectable, so it's
possible to copy&paste the version for bugreport purposes.
Change-Id: I63b53cca4126da17bfbda0293d7c98e8524ef41a
Added a message callback interface to Document where the provided
implementation processes the messages from LOK (for now
only the regions that were invalidated)
Change-Id: Ic7fcb0250f87f6c4c28925bf809c4cf3f353d2bb
This adds support to retrieve callbacks from LibreOffice (like
for example that a part of document has been invalidated) to
LibreOfficeKit JNI and Java wrappers.
Change-Id: Ib70187194d002c72b64d58032aab216adc591565
The only use of it is commented out. ThumbnailGenerator used the UNO-based
XToolkitExperimental stuff that I want to get rid of. If/when we want
thumbnails, we should use the existing thumbnails from document formats that
have them, or generate them using LOKit.
Also remove stuff from the Bootstrap class that was only used by
ThumbnailGenerator.
Conflicts:
android/experimental/LOAndroid3/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
Reviewed on:
https://gerrit.libreoffice.org/13503
Change-Id: Ia3a1a7f372a814359c5b496cdb17c35246e34817
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
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
It can happen that this directory doesn't exist and the copy
script fails (especially on a clean install). The script has been
modified to force create this directory before trying to copy
stuff into it.
Change-Id: Iedf3caef07e6896405750aea9e8f211b1e80dc3a
As part of LOK initialisation we now start soffice_main, this
requires TMPDIR access, and will fail if we haven't set TMPDIR
(as by default it attemps to access /tmp which is not allowed on
Android).
Change-Id: I63bd7bce9b52c898c60fda6eea33ee919349a109
...and had started to have different values in instdir (ProductMajor=450, ProductMinor=0)
vs. installation sets (ProductMajor=50, ProductMinor=)
Change-Id: I4db2c07b5f7b011218833fc355a3097eb13d0cd4
+ prevent lokandroid JNI functions to be removed from the library
+ basic use of lok Office / Document in LibreOfficeMainActivity
Change-Id: I7bfe53738cf821b2270ab3e024cc506a7cff42f0
This is so that calls like 'make configmgr android' produce an .apk with
updated code changes from configmgr as expected.
Change-Id: I5f576b01269cf3f559a8a6389af298a3758e7309
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
