Enable support for MIME type
"application/vnd.oasis.opendocument.spreadsheet-flat-xml" in
AndroidManifest, the comment saying it crashes the app
is obsolete.
However, at least on my Android 10 AVD, that MIME type
does not seem to be associated with '*.fods' files, so
they were not offered to be opened. MIME type
"application/octet-stream" was used instead, for which
no support is declared.
For testing, I just disabled the MIME type filter locally and
was then able to open an FODS file just fine:
--- a/android/source/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
+++ b/android/source/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
@@ -266,7 +266,7 @@ public class LibreOfficeUIActivity extends AppCompatActivity implements Settings
}
intent.setType("*/*");
- intent.putExtra(Intent.EXTRA_MIME_TYPES, SUPPORTED_MIME_TYPES);;
+ //intent.putExtra(Intent.EXTRA_MIME_TYPES, SUPPORTED_MIME_TYPES);;
Change-Id: Ibf3f559a313f0b89bc4c25498e3efa0fcbded506
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132263
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Added LOK_CALLBACK_SC_FOLLOW_JUMP: fire this signal to jump to cell
cursor in android viewer. Payload format same as
LOK_CALLBACK_INVALIDATE_TILES.
Change-Id: Ic896baccf1327d6ccdf104811446e3454a42679e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116448
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When closing the software keyboard after typing,
a black area instead of the doc content was shown
in Android Viewer.
This looks related to the fact that a SurfaceView
is involved, s.a. [1] which suggests two potential
solutions to fix the issue, but none of them really
works well. (Setting a transparent background didn't
have any effect when I tried. Using
'android:windowSoftInputMode="adjustPan"' in
AndroidManifest.xml would work in general, but trigger
the problem described in tdf#96789, namely the
software keyboard would be shown on top of the
document and the last part of the document would
not be visible with the software keyboard enabled
any more.)
Rather, make sure an 'LOEvent.SIZE_CHANGED' is
triggered when the software keyboard is enabled or
disabled, in which case 'LayerView#onLayout' is called
with a 'changed=true' parameter.
To avoid resetting zoom and position of the document
for this case, call the 'redraw' function with param
'false' when processing this type of event in
'LOKitThread#processEvent'
(s.a. Change-Id: I8ba6a7cd8d984ad99654e188e00144e1edf407ed,
"android: Don't reset zoom and position on refresh event"
that did a similar thing for 'LOEvent.REFRESH').
This adds a 'force' boolean parameter to
'GeckoLayerClient#sendResizeEventIfNecessary', which
interestingly had been there before commit
43bbf53bba
Date: Tue Jan 27 13:01:53 2015 +0900
android: remove unneded code from GeckoLayerClient
but I didn't further check whether it had been used
in any way that would have been useful for this
scenario back then.
Stackoverflow article [2] was quite helpful.
[1] https://stackoverflow.com/questions/2978290/androids-edittext-is-hidden-when-the-virtual-keyboard-is-shown-and-a-surfacevie
[2] https://stackoverflow.com/questions/52223095/how-to-detect-redraw-of-screen-has-completed-after-soft-keyboard-closes
Change-Id: If3fdd1335468fc50901fc6c1982c1463c7804309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115973
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't call 'zoomAndRepositionTheDocument' for a REFRESH
event. The only two places sending such an event are in
'LibreOfficeMainActivity#onStart' and in
'FormattingControler#sendInsertGraphic'.
I don't see any need to reset the zoom and position in
any of those two cases. Doing so had the effect that any
manual zoom changes would be lost when e.g. switching
between the LibreOffice Viewer app and another one,
after a "Save As" or when inserting a picture.
In my opinion, it's desirable to keep the view
the user had before doing any of those actions and
just rendering the document anew.
To do so, add an extra bool parameter
'resetZoomAndPosition' to the relevant methods
in 'LOKitThread' that says whether a reset
should take place.
Change-Id: I8ba6a7cd8d984ad99654e188e00144e1edf407ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115950
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of just setting LibreOfficeMainActivity's
'pendingInsertGraphic' member when inserting an
image, call the method responsible for asking what
compression to apply, doing the actual compression
and sending the event so the picture is actually
inserted right away.
'LibreOfficeMainActivity#pendingInsertGraphic' is
(by now) only evaluated in 'LOKitTileProvider' when the
document is initially loaded, therefore just setting
it had no effect.
The more complicated handling used previously instead
of just inserting the picture right away was probably
necessary/used because 'LibreOfficeMainActivity#onStart'
used to reload the whole document before
commit 1bc4247220
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Apr 9 13:59:43 2021 +0200
tdf#95517 android: Rework app/doc lifecycle handling
and that was called when returning to the main activity
from the picture chooser. (That is just a guess, I didn't
actually verify this).
While this fix probably doesn't have much to do with what
caused that functionality to not work back in 2018,
when most of the feature was introduced but it did
not yet fully work as mentioned in
commit 8d977511e3
Date: Mon Aug 14 11:41:30 2017 -0500
tdf#106370 Android: add ability to insert pictures
Added ability to insert pictures to Android Viewer.
You can take photo or select photo from device or
the cloud (Google photos, Dropbox). You can also
compress the picture before inserting it with multiple
compress grades. So far, inserting doesn't work for
Writer due LO native library issues (I think).
it still makes inserting pictures "just work" by now.
Change-Id: Idad9dcbba177ea12f056bc31bd6b9c08621062cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115932
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
commit 1bc4247220
Date: Fri Apr 9 13:59:43 2021 +0200
tdf#95517 android: Rework app/doc lifecycle handling
changed activity lifecycle for Android Viewer's
'LibreOfficeMainActivity'. It moved sending an event to
trigger loading of the document from the 'onStart' to the
'onCreate' method and added sending a more lightweight refresh
event the 'onStart' method instead.
However, since a refresh is already done when loading the
document, there's no need to do another refresh when the 'onStart'
method is called right after the 'onCreate' method.
Therefore, set a flag in the 'onCreate' method and use that
to skip sending the extra refresh event for that case. This
not only avoids doing unnecessary work but also avoids that
the two could get into each others way, resulting in Calc
documents sometimes not being rendered on initial load.
Change-Id: I5c47e1b5f7a42a49fb903891aa84585b36994a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115750
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When the "Recent files" list in Android Viewer contained an entry
for an Uri that was no longer pointing to a valid file, a
SecurityException was thrown trying to query the display name
from it.
Catch the SecurityException that is thrown and just return an
empty string, the document is then not displayed in the
"Recent files" list.
One scenario:
1) open file located in the "Download" directory from within the app
2) close the app
3) delete the file
4) open the app again
-> crash, with this backtrace in ADB log:
05-11 08:37:14.230 3892 4707 E DatabaseUtils: java.lang.SecurityException: Permission Denial: reading com.android.providers.downloads.DownloadStorageProvider uri content://com.android.providers.downloads.documents/document/msf%3A1091 from pid=6981, uid=10177 requires that you obtain access using ACTION_OPEN_DOCUMENT or related APIs
05-11 08:37:14.230 3892 4707 E DatabaseUtils: at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:804)
05-11 08:37:14.230 3892 4707 E DatabaseUtils: at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:670)
05-11 08:37:14.230 3892 4707 E DatabaseUtils: at android.content.ContentProvider$Transport.query(ContentProvider.java:238)
05-11 08:37:14.230 3892 4707 E DatabaseUtils: at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:106)
05-11 08:37:14.230 3892 4707 E DatabaseUtils: at android.os.Binder.execTransactInternal(Binder.java:1138)
05-11 08:37:14.230 3892 4707 E DatabaseUtils: at android.os.Binder.execTransact(Binder.java:1102)
05-11 08:37:14.230 6981 6981 D AndroidRuntime: Shutting down VM
05-11 08:37:14.231 6981 6981 E AndroidRuntime: FATAL EXCEPTION: main
05-11 08:37:14.231 6981 6981 E AndroidRuntime: Process: org.libreoffice, PID: 6981
05-11 08:37:14.231 6981 6981 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{org.libreoffice/org.libreoffice.ui.LibreOfficeUIActivity}: java.lang.SecurityException: Permission Denial: reading com.android.providers.downloads.DownloadStorageProvider uri content://com.android.providers.downloads.documents/document/msf%3A1091 from pid=6981, uid=10177 requires that you obtain access using ACTION_OPEN_DOCUMENT or related APIs
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3333)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3477)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2043)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.os.Looper.loop(Looper.java:216)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7464)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:549)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:955)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: Caused by: java.lang.SecurityException: Permission Denial: reading com.android.providers.downloads.DownloadStorageProvider uri content://com.android.providers.downloads.documents/document/msf%3A1091 from pid=6981, uid=10177 requires that you obtain access using ACTION_OPEN_DOCUMENT or related APIs
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.os.Parcel.createExceptionOrNull(Parcel.java:2285)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.os.Parcel.createException(Parcel.java:2269)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.os.Parcel.readException(Parcel.java:2252)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:188)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:140)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.content.ContentProviderProxy.query(ContentProviderNative.java:472)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.content.ContentResolver.query(ContentResolver.java:1112)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at org.libreoffice.ui.FileUtilities.retrieveDisplayNameForDocumentUri(FileUtilities.java:137)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at org.libreoffice.ui.LibreOfficeUIActivity.createUI(LibreOfficeUIActivity.java:206)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at org.libreoffice.ui.LibreOfficeUIActivity.onCreate(LibreOfficeUIActivity.java:147)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.Activity.performCreate(Activity.java:7990)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.Activity.performCreate(Activity.java:7979)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1309)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3308)
05-11 08:37:14.231 6981 6981 E AndroidRuntime: ... 11 more
05-11 08:37:14.233 2293 3174 W ActivityTaskManager: Force finishing activity org.libreoffice/.ui.LibreOfficeUIActivity
Change-Id: I7a8e824e557dba8771cf1f210ae89d6f60498737
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115374
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't delay the call to 'glDeleteTextures' but
always call it immediately via 'TextureReaper.get().reap()'
in 'Subtile#cleanTexture'.
Delaying it appears to sometimes cause it to be called
"at the wrong time", resulting in black areas being
shown instead of properly rendering/displaying the document
content in the corresponding tile.
This fixes the issue also mentioned in commit
1bc4247220
("tdf#95517 android: Rework app/doc lifecycle handling"),
which was present before, though:
> (Well, sometimes there is an issue with
> invalidation/repaint and single tiles remain black,
> but that happened previously - when the whole doc
> was loaded anew - just the same way).
Change-Id: I5f18dbe3133d9d00a76b129fd119c2e80441e531
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115241
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Those were mostly suggested by Android Studio, like:
* mark members static or final
* drop unused variables and members
* avoid unnecessary cast
* simplify condition: '(!cond)' instead of 'cond == false'
* drop unused imports
Change-Id: I252fe836e4a3184e13af59a30202c6daccac1794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114546
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It appears to be unused since
commit f3eccc6553
Date: Tue Feb 3 18:19:32 2015 +0000
tdf#87432: normal icons for folders in android doc browser
Change-Id: I6984ff75392f7f28ba1b2659846d164d25b66f2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114544
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Provide the "Save As..." menu entry in Android
Viewer also if read-only mode is used, either
because the experimental editing mode is disabled
or there is no write access to the document.
This way, a copy of the original document
can be saved elsewhere.
In case experimental mode is enabled, editing
is allowed after saving the document.
Call 'ToolbarController#setEditMode' in
'ToolbarController#switchToEditMode' right away instead
of posting it to the main handler in a Runnable along
with the other commands (that change the UI), so the new state
is already taken into account in
'LibreOfficeMainActivity#onResume' and the toolbar
isn't switched back to view mode there right away.
Change-Id: I321e42d0833463b31c7b39336d66b29bd51d9890
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114539
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When the input document in Android Viewer is a template,
a new doc is created and a plain '.uno:Save'
(which 'LibreOfficeMainActivity#saveDocument' triggers when the
"Save" menu entry is selected) will therefore fail.
A proper URI to save to (rather than overwriting the
template itself) is only known after a "Save As" anyway,
so don't set the 'mDocument' member until then, which leads to
the "Save" menu entry becoming disabled, just as is the
case when explicitly choosing to create a new document in
the start activity.
For now, the check whether the document is a template
checks whether the MIME type detected for the URI
ends with "template", which is the case for ODF and
OOXML types (like
"application/vnd.oasis.opendocument.text-template" or
"application/vnd.openxmlformats-officedocument.wordprocessingml.template").
This can be refined further as needed, e.g. by explicitly
adding more MIME types to check.
(Editing the actual template instead of creating a new doc
from it would be a different use case that remains
unsupported also with this change in place.)
Change-Id: I81ff957de27f620a026dbc01097b8061886293a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114157
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When creating a new document in Android Viewer,
don't show a file picker to choose where to save
the file at once, but create a new document and
only ask where to save the file once "Save As"
has been selected.
The plain "Save" entry is disabled until then,
since no URI to save to is known at this time.
The handling for the temporary local file,
which is used for all of the "actual work"
remains unchanged.
While at it, rename
'ToolbarController#disableMenuItem' to
'ToolbarController#enableMenuItem' and
invert the meaning of the boolean parameter
since I find that more straightforward and it also
better matches the naming of the underlying
'MenuItem' method as well.
Change-Id: I3eefada5531bfb2202aca25f2c9f170a463f87f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114152
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't only enable the "Export To PDF" and "Print" menu
items if the experimental editing mode is enabled, but
always offer them, since they should be sufficiently stable
and don't require any editing of the document.
To do so, move them into a new menu group
"group_misc_actions", and move the entry for sending
UNO commands up, so it remains in the
"group_edit_actions" menu group whose entries are
hidden unless editing mode is enabled.
Change-Id: I425cf6d0a45306ff48b45dad6fd0e804b87a2546
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114147
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In Android Viewer, show a file picker to select
where to save the PDF file on PDF export, rather
than unconditionally trying to save in the
"Documents" directory.
This also means that permission
'android.PERMISSION_WRITE_EXTERNAL_STORAGE' is
now no longer needed for this task, s. commit
message from
commit 7d9db806d6
Date: Fri Apr 9 11:24:16 2021 +0200
android: Request PERMISSION_WRITE_EXTERNAL_STORAGE again
for more details.
Also, adapt the 'TileKitProvider#saveDocumentAs'
methods to return a boolean value indicating
whether the save operation was successful,
and trigger showing the message right into
'LibreOfficeMainActivity#exportToPDF'.
Rename 'LOKitTileProvider#exportToPDF(boolean print)' to
just 'LOKitTileProvider#printDocument()', since the only
remaining use case for which it is used is printing now.
Change-Id: I779d782813ca01640811690a388a4b7fd3db4b2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114143
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This adds a "Save As..." menu entry to Android
Viewer in order to save the currently opened file
to a different location.
Currently, the file is always saved in the corresponding
ODF format, regardless of the original file type,
i.e. that e.g. a DOCX file is saved in ODT format.
(This could be extended to allow a selection of the
target format as needed.)
Like "Save As" (and as compared to "Save a Copy")
in the desktop version, the app remembers the
new document URI and subsequent save operations
will overwrite the newly saved file, not the originally
opened one.
(There is no need to create a new temporary
local file to use, though.)
The directory of the currently used file
is preselected in the file chooser used to
specify where to save the new file.
Make sure to copy the file in a non-main thread,
since the destination URI might be handled
by a DocumentsProvider that does network access.
However, for now the main thread just waits for
the separate thread to finish, just like
commit 7f838b73e8
Date: Fri Mar 19 15:46:36 2021 +0100
tdf#129833 android: Move reading file to separate thread
implemented it for copying from the URI to the
temporary file when opening a file.
This also adds a 'TileProvider#isDrawing' method
(like the already existing 'isTextDocument',
'isSpreadsheet' and 'isPresentation' ones).
Change-Id: I6f56b71763431b89a6c74be35cc1e81fad136cd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114058
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This essentially extracts what
commit 7f838b73e8
Date: Fri Mar 19 15:46:36 2021 +0100
tdf#129833 android: Move reading file to separate thread
introduced into a separate helper method.
Change-Id: Ic70ba9f2e2bc125415ff1b3fa3375c3389181c43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114123
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
LOKitTileProvider has that information, so query it instead
and don't duplicate information in LibreOfficeMainActivity.
Change-Id: I233986d6e94e5676464cb3399303efd545e33d32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114057
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously, the document was always closed in
LibreOfficeMainActivity's 'onStop' and loaded anew in
its 'onStart' method.
In order to not lose user changes, there was also
a caching mechanism in LOKitTileProvider, also triggered
in 'LibreOfficeMainActivity#onStop'.
This means that e.g. each time a switch to another
Activity/app happened, a cache document with the user
modifications in it should have been created for
restoration. That did not really seem to work
particularly well in a few tests, as also described
in tdf#95517 ("changes reset after show Settings").
The documentation aboue Activity lifecycle says [1]
> The entire lifetime of an activity happens between the first call to
> onCreate(Bundle) through to a single final call to onDestroy(). An
> activity will do all setup of "global" state in onCreate(), and release
> all remaining resources in onDestroy(). For example, if it has a thread
> running in the background to download data from the network, it may
> create that thread in onCreate() and then stop the thread in
> onDestroy().
This changes the handling to load the document in the
'onCreate' method and clos it only in 'onDestroy',
i.e. the document remains open while e.g. switching
to another Activity or app, thus making it unnecessary
to try to restore state as good as possible in 'onStart'.
An invalidation of the view (via 'LOEvent.REFRESH')
generally seems to be enough.
(Well, sometimes there is an issue with
invalidation/repaint and single tiles remain black,
but that happened previously - when the whole doc
was loaded anew - just the same way).
This allows dropping some extra handling needed
to try to restore the previous state, along with the
caching mechanism in LOKitTileProvider (that had some
other issues, e.g. it didn't reliably create the cache
file, since the file extension was not always set, and
'LOKitTileProvider#cacheDocument' was relying on that
to derive the document type).
I am not sure whether I missed any aspect that the
previous implementation was trying to solve, but
at least these scenarios I found and tested worked
as expected with the change in place:
* user changes still present after switching between apps
(s. tdf#106648 "Android: save current work when onSaveInstanceState is
called")
* for the Calc case, the sheet that was selected before
switching apps is still selected (s. tdf#101689
"Android Viewer calc returns to first sheet")
* user changes no longer get lost when selecting a menu item
(s. tdf#95517 "changes reset after show Settings")
* case where the user leaves the app by pressing Home, and starts it again
(as described in commit 83386129f5
"android: Fix the application lifecycle.")
[1] https://developer.android.com/reference/android/app/Activity#activity-lifecycle
Change-Id: If59734cbfd62673884786066c94e2c2a1d6a916e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113883
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Always create a local copy of the original document
to work with, rather than doing a different handling
depending on the type of the URI used to specify the
file to load.
This will also simplify adding support for "Save As"
in upcoming commits, where the temporary
file can remain the same and only the URI for the
actual document will need to be changed.
Change-Id: I2587611fa56b76d8a5384ac25c57335e8d12e987
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113882
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Make 'example.odt', 'license.txt' and 'notice.txt'
(which can be opened via the "About" dialog)
resources of the app by copying them to a new directory
'res_generated' instead of into assets, and include
'res_generated' into resources, then use an
'android.resource://' URI instead of a 'file:///assets/'
one in AboutDialogFragment.
The latter does not work with when passed as a parameter
to 'ContentResolver.openInputStream'.
Adapt/Simplify 'LibreOfficeMainActivity#copyFileToTemp' to
make loading those docs using the 'android.resource://'
URI work and use the existing 'copyStream' method for copying from
the input to the output stream.
This is in preparation for upcoming commit with Change-Id
I7731ef81a4242fa0ce3b3fd8ced1683a6a6bee8c,
"android: Always create a temporary local copy of the doc".
Change-Id: I7731ef81a4242fa0ce3b3fd8ced1683a6a6bee8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113881
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop the fallback of opening 'example.odt' when
no file to open was given.
I see no valid way how that fallback should be
reached, so write an error log message instead,
just in case there is still a way to get there.
Change-Id: I8b8040ba0099cba9196f65982f09c67791be01c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113880
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Extract method 'copyStream' used to copy the
temporary file to the actual document URI when
saving.
It will also be used for copying the other way around
when initially opening the document.
Change-Id: I5382f4a7c49b454ff38fb8f95afab3c39145c11f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113879
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a 'mDocumentUri' member in LibreOfficeMainActivity
to store the document URI rather than retrieving it from
the Intent using 'getIntent().getData()' all the time.
This is also in preparation to make it possible to change
the URI later, e.g. when doing a "Save As".
While at it, also switch to readonly mode for the
fallback to 'DEFAULT_DOC_PATH' (though I don't think
this should be relevant anyway).
Change-Id: I629bad1d743e458191dcfa2b1371ea4b280e7b13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113878
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Only try to retrieve the file URI and load the document
if a file was actually selected.
Change-Id: Icd47c197b67d593e74874e8136233b6e41a1a68d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113845
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Requesting the permission on app start had been dropped in
commit a23bd42e9b
Date: Tue Apr 6 14:26:06 2021 +0200
android: Drop custom file abstraction + UI
Since the app now uses the Android Storage Access Framework [1]
in order to open or create files from within the app,
it not longer needs PERMISSION_WRITE_EXTERNAL_STORAGE for this.
However, at least PDF export currently still directly writes
to local storage ("Documents" directory), which fails without
that permission being granted.
In addition, opening files passed with a 'file://' URI
in an 'Intent.ACTION_VIEW' also did not work anymore.
I'm not sure whether this use case is particularly
relevant in practice, though; at least all of the (few)
apps I used during testing passed 'content://' URIs in their
Intent.
In addition, in Android 11 (API level 30) or higher,
PERMISSION_WRITE_EXTERNAL_STORAGE no longer has any effect;
from [2]:
> More recent versions of Android rely more on a file's purpose than its
> location for determining an app's ability to access, and write to, a
> given file. In particular, if your app targets Android 11 (API level 30)
> or higher, the WRITE_EXTERNAL_STORAGE permission doesn't have any
> effect on your app's access to storage. This purpose-based storage
> model improves user privacy because apps are given access only to
> the areas of the device's file system that they actually use.
>
> Android 11 introduces the MANAGE_EXTERNAL_STORAGE permission, which
> provides write access to files outside the app-specific directory and
> MediaStore. To learn more about this permission, and why most apps don't
> need to declare it to fulfill their use cases, see the guide on how to
> manage all files [3] on a storage device.
For now, request the permission again, at least as long
as PDF export doesn't use the storage framework to
ask where to save files.
It certainly makes sense to reconsider this in the future (and decide to either
drop the permission completely or request MANAGE_EXTERNAL_STORAGE for API
level >=30).
[1] https://developer.android.com/training/data-storage/shared/documents-files
[2] https://developer.android.com/training/data-storage#permissions
[3] https://developer.android.com/training/data-storage/manage-all-files
Change-Id: Icc4c9c9b7b315d2a0b6a025439ae7e431cdd5b37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113840
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Move the view that opens the system file picker when tapped
above the "Recent files" view in the Android Viewer start
activity.
Change-Id: I63ee0ea7fb784a3405877fcf5ed587ce06e8e093
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113674
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Android Viewer had its own file abstraction layer.
From the (now deleted) IFile.java:
> An abstraction of the File class, intended to be implemented by different
> Document Providers.
>
> It represents a file or a directory in the context of a certain Document
> Provider. It wraps the file-related operations and provides access to the
> final document as a local File, downloading it if necessary.
However, Android already provides such an abstraction by
what is called "documents provider" there as well, s. [1].
Android Viewer has previously been adapted to
support and make use of that.
Therefore, drop the custom implementation to avoid
duplication and having to reimplement functionality
already provided otherwise.
Also, drop the custom UI elements to display and
select files implemented on top of the custom
file abstraction. Support for using the system file
picker (via the corresponding Intents) has been added
earlier and is now the only available option to open
files from within the app.
[1] https://developer.android.com/training/data-storage/shared/documents-files
Change-Id: Ide529e836a32fd7e880e5a72d971af9f9c7e74bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113667
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously, a set was used to store the recently used files,
meaning the order was lost when restoring from the prefs.
Use a space-delimited string to store the entries in prefs
instead, and convert that into an (ordered) list.
This way, it's possible to always drop the oldest entry
(instead of a random one) when inserting a new one and
the max count has been reached, so the list of
recently used files shows those that are actually the
(up to 4) most recently used ones.
Change the key used for the preference
(variable 'RECENT_DOCUMENTS_KEY') to a different value,
so there is no problem about trying to
read old values stored as a Set<String> as a
plain String.
Change-Id: I95cc3627cd2975f0463f5ecb94292a26fe714066
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113462
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the list of recently used documents in LibreOffice Android
Viewer to show the documents opened using the system file picker
instead of those shown using the custom UI elements for file
selection.
This way, files provided by DocumentsProviders, like Nextcloud,
can also be handled.
As described at [1], this requires persisting permissions
in order to be able to access the files after a device reboot.
The corresponding method to do this,
'ContentResolver#takePersistableUriPermission', is only
available from SDK level 19 on, so drop entries for
older SDK levels (current minSdkVersion is 16).
[1] https://developer.android.com/training/data-storage/shared/documents-files#persist-permissions
Change-Id: Ifbf7148cda687a8a2e3f0c14fe66651509b2f19a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113459
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is unnecessary, since minSdkVersion was bumped to 16
in
commit a7f6338875
Date: Wed Aug 7 12:06:25 2019 +0200
android: support NDK 19 and above (20 as of this commit)
support for targeting API 14 and 15 was removed in NDK 18, so set
minimum version to 16
[...]
Change-Id: I70573f9e5e24b211ee7e84be5824d69e4f2b9f81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113458
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Since input etc. is otherwise ignored in readonly mode,
also don't mark the document as changed on keypress.
This e.g. avoids an unnecessary dialog whether or not to
save the document after opening a document with experimental
editing mode disabled, then pressing a key (on hardware
keyboard, soft keyboard isn't shown in readonly mode)
and then pressing the "Back" button to close the document
again.
Change-Id: I095c79549719d3760666605e1c642c58e6b1bb9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113417
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop the "Press back again to quit" info shown when pressing
"Back" in the file selection dialog in Android Viewer and
just quit the app right away.
It was originally added in
commit d1f671e053
Date: Wed Jun 10 19:04:22 2015 +0200
tdf#87434: android: system back key to go one level up
Added an additional check so back has to be pressed twice on the root
folder to actually leave the application. It's a check seen in many
other apps.
but I don't really see any need to bother the user
about pressing "Back" again. Nothing is lost at
this stage when quitting the app, and I haven't
seen anything similar in many current apps myself
(but have rather seen some extra confirmation dialogs
disappear from desktop applications over the last
years).
The original request in tdf#87434 to go one level up
in the directory hierarchy is unaffected by this,
though this only applies for the custom widgets
to browse the file system, which will potentially be
dropped in the future anyway, now that support
for the system file picker has been added in
commit d678ee309b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Mar 19 14:29:36 2021 +0100
tdf#129833 android: Allow opening files using system file picker
Change-Id: Ib324b7f0b82427b04c7708665ff7492a758eec9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113413
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to the way that existing documents can be
opened from within the Android Viewer app
using the system file picker by using
'Intent.ACTION_OPEN_DOCUMENT', use the system file picker
via 'Intent.ACTION_CREATE_DOCUMENT' to create new docs
as well, instead of providing a custom dialog to
insert a file name.
As described at [1], this allows to save files
in locations supported by any existing
DocumentsProvider (e.g. a Nextcloud share,
if the Nextcloud app is installed and set up),
not just locally.
This also allows to further unify the handling in
LOMainActivity. Just like for the cases where an
existing document is opened using the system file
picker or a document is passed from a third-party app,
the document URI is now set in the Intent, a
temporary file is used and writing back to the
actual URI happens on save.
Drop LibreOfficeMainActivity's method 'showSaveStatusMessage',
which was only meant to be used when a new file was created, but
was called from the more generic 'LOKitTileProvider::saveDocumentAs'.
Change that to show a more general error message when saving fails.
Since the actual file is now created by the DocumentsProvider,
LOKitTileProvider only operates on the temporary copy anyway.
Side note: With this change in place, overwriting
existing files also no longer just happens silently,
as used to be the case when typing the name of an existing
file in the custom dialog for creating new files
earlier.
Since 'Intent.ACTION_OPEN_DOCUMENT' was introduced
in SDK version 19 (Android 4.4), restrict creating
new docs to corresponding devices.
[1] https://developer.android.com/training/data-storage/shared/documents-files
Change-Id: I8932cb892ca8ac97a04d15cbd1540d0ee68350da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113408
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Follow-up for commit a1abf2c865
(tdf#139350 android: Add param to allow a "real" "Save As").
The file path should only be updated when the newly saved
doc is actually used (i.e. 'takeOwnership=true'),
not when just saving a copy or exporting to a different
file format.
Change-Id: Ia3120a94b7fcc79c1a740a10bade8721f6771d78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113404
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Michael Weghorn