Has all been obsoleted by LibreOfficeKit.
Only some MOBILE_* constant #defines are now left in touch.h, but probably
those are used only by dead code.
Change-Id: I646945c4408b4e6cd5510da535cfc12088dd391c
Also, if we are at it:
- clean up 'run' as well: since the doc browser is the default activity,
no need to pass the test doc path anymore
- make 'install' not depend on build: a full build would need a toplevel
'make' anyway
Change-Id: Ia55d52f767ab3e0be02a753a95b2aac02f8491cc
Previously we included the android support library v4 for some
GUI elements like GridView. This commit in addition adds the v7
appcompat library which is needed for the new Lollipop style
Toolbar and many other new GUI elements.
The appcompat v7 library is not distributed as only a jar file
but needs to be build (as it includes additional resources) and
included as a library project. So to do this the content is copied
from SDK and build with the build system. The files also include
the v4 so it doesn't need to be copied from SDK anymore.
The target had to be raised to v21 (Lollipop), however the minimum
SDK version remains unchanged.
Change-Id: I4f1a6ce69e7f6c3f9df784a6835f376a01d4dfdb
The implementation still sends them to the currently active VCL frame,
not to the given document, though.
Change-Id: I6fa2decdea3f949c55287e802cb3373c85664207
Otherwise FSStorageFactory::createInstanceWithArguments() would throw,
resulting in a css::configuration::CorruptedConfigurationException
later, that makes LO throw up its hands in Desktop::Main() and say that
the instset is simply corrupted, there is no point in continuing
further.
Change-Id: I3a401ee77f4fbf1a42a09c5fedd7681b4f32e952
This now also allows to specify the version number; now you want to use:
cd android/
make versionCode=<previous_version_num+1> key=<key_name> release-apk
Change-Id: I078e8dbbe671969fc3b228ac987cdb9a4a53b281
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
