Was a problem introduced by c6f36965cf.
Change-Id: I8fbc722ed73af19a6462c87242d431eea118f1a2
Reviewed-on: https://gerrit.libreoffice.org/85020
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
To have the menu translated.
Change-Id: I8d4d90d260aa3fcd80a8eb68515b22c58c9b3e18
Reviewed-on: https://gerrit.libreoffice.org/84931
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
All these cases should be covered:
* user's explicit save via File -> Save
* autosave
* autosave on exit
Implemented via IntentFilter magic, we can call back from one activity
to the other to perform the actual saving in the shell.
Change-Id: I97d6e94028a9600a71f030af7146ee01163d09b8
Reviewed-on: https://gerrit.libreoffice.org/84872
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
I've just spent many hours debugging why a type is not known to the
cppuhelper and is throwing a "cannot get type description for type ...".
It turned out it was just a stale .rdb on the device that avoided being
updated.
So this change will help developers (much lower risk of stale rdb
files), while not a problem for the releases (each version bump has to
update the rdb's anyway).
Change-Id: Ie73245cfc78da8faf97f08ef52e6358a8e71218d
Reviewed-on: https://gerrit.libreoffice.org/81707
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
This is needed after core.git's
f68a36b62ed327eb67efdfea0ac46645b4d90877, without it the native code
crashes:
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.collabora.libreoffice.debug, PID: 25358
java.lang.UnsatisfiedLinkError: dlopen failed: library "libc++_shared.so" not found
at java.lang.Runtime.loadLibrary0(Runtime.java:1071)
at java.lang.Runtime.loadLibrary0(Runtime.java:1007)
at java.lang.System.loadLibrary(System.java:1667)
at org.libreoffice.androidlib.LOActivity.<clinit>(LOActivity.java:467)
at java.lang.Class.newInstance(Native Method)
at android.app.AppComponentFactory.instantiateActivity(AppComponentFactory.java:95)
...
Change-Id: If0d0f3ade3d2a5a8692dcc3d79edbfb51cd7e2ed
Reviewed-on: https://gerrit.libreoffice.org/81499
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Without this, the first start was failing, there was only a black screen
and the request for permission.
Change-Id: I7929048ca51b044dcb574f48bd2b7bc9a27e0ec8
First of all, we shouldn't destroy the document in onStop(), instead do
that in onDestroy(). onStop() should only (auto-)save the document, but
otherwise keep it open, so that when we return from the file picker
Activity, the caret is at the same position as it was before.
In addition to that, we should close any open document before we try to
open the new one (in createLOOLWSD).
And finally, when closing the document, we should wait until after the
LOOLWSD is completely torn down, so that we avoid the risk that the user
tries to load another document too quickly, and the messages from the JS
go into the old, still running LOOLWSD.
Change-Id: Ib775021bccc5d5bc69aae392a88dc62a7c05a8fa
Sometimes when closing & reloading a document, the JS ended up with:
cmd=/storage/0/...document_name... type=unknown
error. The problem was that the HULLO response came later than the next
message in the queue which was
loolclient 0.1
So LOOLWSd tried to load the document called "loolclient 0.1", which
failed, and then it did not know what to do with the "/storage/0/..."
which it understood as a command.
Seems we don't need to send the stuff from a thread on Android, so let's
avoid that, instead of setting up another sender queue here.
Change-Id: I96b4ad13153f1cad6aeb7fc71efcb402edbdc6d2
This way, it is more naturally visible what is the actuall app (with the
initial recent documents / file picker) and the editing part.
Change-Id: Ia764f2900939e980f703e3da9f9abd6c0aee7cbb
