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
1bc42472200c32c9a0a10dd1c3cd6c6a8a5d47d2
("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 f3eccc655387b47fb0986558b8835588eee2898d
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 7d9db806d65cb814af1e99a1e79c3db5aa7c17d5
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 7f838b73e85eb6f0a1dce4647650a5cf5f34ccd2
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 7f838b73e85eb6f0a1dce4647650a5cf5f34ccd2
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 83386129f5be002f2649db81bba4c468c7f6e4de
"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 a23bd42e9b2f6401c710ac95afcc3aa8f360d65c
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>
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 a7f6338875931d8afff55cb39ead8f6600af04cb
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 d1f671e053864d0bf54d04a855761b43a7f5a9c4
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 d678ee309b02b4cc8af29a097bf5053b8b1b4e06
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 a1abf2c865228e6ed33e99ab73b94357ddbc590f
(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>
It appears to have been unused since it was added
in
commit 78098b8494be7123bc4a8b50faa13445e5afd8ce
Date: Mon Mar 27 22:26:47 2017 +0530
Add BottomSheetBehavior to formatting toolbar
Change-Id: I43cc75e0b7a1bcebd01bd77fc7132a39510c70ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113400
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass param 'takeOwnership=true' to the 'saveDocumentAs'
method when saving a newly created document in Android Viewer
in 'LOKitThread::loadNewDocument', so the newly
written document is used subsequently, rather
than continuing to more or less operate on
"private:factory/swriter" (for the Writer case,
similar for the others).
Extend 'LibreOfficeMainActivity::saveFileToOriginalSource'
to handle this case as well (show a proper message and
reset the modified state after saving).
Drop now unnecessary special handling for the case
of saving new files from the toolbar or the dialog
shown when exiting without having saved previously.
Change-Id: Ief95620e324aa2abc318f1add0b91376ffe669d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113376
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, LOKitTileProvider's 'saveDocumentAs' method
was always saving a copy of the current document
(or doing an export), but was not continuing to use
the newly saved doc afterwards.
Add an additional parameter 'takeOwnership' to the
method to specify whether to do so.
In other words,
* the 'takeOwnership=false' case continues to
do what was done previously, it basically does what
"File" -> "Save a Copy" or "File" -> "Export"
does in the desktop version
* the 'takeOwnership=true' case now basically does the
same as "File" -> "Save As" in the desktop version
(except that the path is already known in the
Android case)
This essentially forwards the "TakeOwnership"
param to LibreOfficeKit, which was originally
added there in
commit a121074cbd07939713e169586469b934aedbe594
Date: Wed Feb 10 13:26:50 2016 +0100
lok: Introduce a "TakeOwnership" filter option for saveAs().
It is consumed by the saveAs() itself, and when provided, the document
identity changes to the provided pUrl - meaning that '.uno:ModifiedStatus' is
triggered as with the "Save As..." in the UI.
This mode must not be used when saving to PNG or PDF.
Change-Id: I11b5aa814476a8dcab9eac5202bd052828ebbd96
This also adds a new 'SAVE_COPY_AS' event type to save a
copy without taking ownership, and switches all uses of the
'SAVE_AS' event to that new one for now. (So the behavior
remains unchanged, but the terminology is hopefully clearer.)
Except for one instance in LOKitTileProver::saveDocument (where
the cached version of the document is written to the original
URI, if present), all other places are left with the previous
behaviour in this commit.
Further changes will be done in follow-up commits.
Change-Id: I11996cd7276a6c6f2774535cd3e53cb997c8cd4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113375
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add an overload for the 'saveDocumentAs' method that takes just one
parameter and auto-detects the file type to use from the document.
Use it when creating new documents.
Change-Id: I0f275ce159176292ffa1e52ed37673a486ab9428
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113374
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The permission was requested since ownCloud support was added
in commit 69773f54bbac08953f0fbce16eecea0816e04338
("Android: initial implementation of ownCloud provider.",
2015-01-21).
Since the custom ownCloud support has been dropped in commit
6012599e17206ee7be9a83477654e7bd194079c3
("tdf#129833 android: Drop non-working ownCloud/nextCloud support"),
there should no longer be any need to require Internet access,
so drop the permission again.
Access to ownCloud and other Internet services providing file
access now goes via DocumentProviders, and the corresponding
apps providing those should take care of
being allowed to access the internet by themselves.
I tested that opening and editing a file located
on a NextCloud share still works OK when the NextCloud
app is installed and set up.
Change-Id: Id8425e7afcd5ecc26d14ba9f42018f536d0a6a6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112879
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Trying to type in a read-only Writer section in Android Viewer
led to a crash due to
'/assets//config/soffice.cfg/modules/swriter/ui/inforeadonlydialog.ui'
not being present.
Include the .ui file to avoid this. (Trying to type now
doesn't do anything, no warning about this being
read-only is shown.)
Change-Id: I616d41c312187fa7855430715a47e80477ef2188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112771
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reading the input file from the main thread is problematic
when that happens over the network.
For example, trying to opening a file in a NextCloud share
using the system file picker from within the LO Android Viewer
app (with NextCloud app 3.15.1 serving as DocumentsProvider
for the NextCloud share in the file chooser) previously
resulted in a crash, with this in ADB log:
I DownloadFileOperation: Download of /Documents/five_pages.odt to /storage/emulated/0/Android/media/com.nextcloud.client/nextcloud/<USERNAME>@demo2.nextcloud.com/Documents/five_pages.odt: Unexpected exception
E DocumentsStorageProvider: RemoteOperationResult(mSuccess=false, mHttpCode=-1, mHttpPhrase=null, mException=android.os.NetworkOnMainThreadException, mCode=HOST_NOT_AVAILABLE, message=null, getLogMessage=Unexpected exception)
Moving this to a separate thread fixes the
NetworkOnMainThreadException and made opening, editing
and saving the modified file back work successfully
for that scenario.
(Using a separate thread when writing back does not
seem to be necessary, but could be added in a similar
way.)
This just moves the IO to a new thread and then waits
for its completion.
For a better user experience in cases where the copy
operation may be slow, providing some additional
feedback in the UI might be useful.
Change-Id: I58e2c4bb1dcd2d59383fba0f216c9614f5d3e3a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112769
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Extend Android Viewer with the possibility to select a file to
open using the "system file picker", which can be opened by
an Intent that has the action 'Intent.ACTION_OPEN_DOCUMENT'
(or 'Intent.ACTION_GET_CONTENT' for API level < 19) set.
This way, all locations supported by currently installed and
set up DocumentsProviders [1] are generally supported.
In a test, opening local files worked just fine, but trying
to open a file located in a NextCloud share failed
(with the corresponding app [2] installed), showing this
in ADB log:
I DownloadFileOperation: Download of /Documents/five_pages.odt to /storage/emulated/0/Android/media/com.nextcloud.client/nextcloud/<USERNAME>@demo2.nextcloud.com/Documents/five_pages.odt: Unexpected exception
E DocumentsStorageProvider: RemoteOperationResult(mSuccess=false, mHttpCode=-1, mHttpPhrase=null, mException=android.os.NetworkOnMainThreadException, mCode=HOST_NOT_AVAILABLE, message=null, getLogMessage=Unexpected exception)
This will be dealt with in a separate commit.
For now, this way to open files (and a corresponding menu
entry) is added in addition to the existing ones, but
since that method should in general be able to cover all of
the other use cases as well, the other options may be
dropped in the future.
[1] https://developer.android.com/reference/android/provider/DocumentsProvider
[2] https://github.com/nextcloud/android
Change-Id: I684a4aa770c0df7cc9fc35ff92445230405885f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112768
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When a document is passed by an Intent in Android
Viewer, allow editing if the Intent has flag
'Intent.FLAG_GRANT_WRITE_URI_PERMISSION' set.
Since LibreOffice operates on a temporary copy
in this case, write the content of the
temporary file back to the original URI
when saving.
This in particular allows editing documents
passed from third-party apps, e.g. opened from
Android's "Files" app or the NextCloud app.
The online-based Android app already does
something similar.
Change-Id: Icf252a95dd9a8089ca8610ccf3edfbeee2682e1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112767
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously when experimental mode was enabled in Android
Viewer, a "This file is read-only, saving is disabled."
info was shown to the user when opening a file read-only,
e.g. when the file was passed from a third-party app.
However, editing the document was still possible, a
dialog asking whether or not to save the modified doc
was shown when existing and only then saving would fail.
Disable editing completely for this case, rather than
having the user lose changes in the end.
Change-Id: Ie523971949d11909223aeac4f99023ecf28cb56c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112693
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
