summaryrefslogtreecommitdiff
path: root/android
AgeCommit message (Collapse)AuthorFilesLines
2021-06-13tdf#142618 android: Don't crash when passed MIME type is nullMichael Weghorn1-1/+1
Change-Id: I5fb532b36fe650596f25a1ba8b7dc56e21292dc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117053 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-05-21tdf#106893 android: Show whole doc when closing soft keyboardMichael Weghorn3-10/+12
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 43bbf53bbad4623355e6344094573f8efca01df2 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>
2021-05-21android: Inline 'LayerView#setViewportSize' to only call siteMichael Weghorn1-5/+1
It doesn't override any parent class methods and was only called from here. Change-Id: Iccfacb42e8d5514994eafac841c0ec55be65b062 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115972 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-05-21android: Don't reset zoom and position on refresh eventMichael Weghorn1-10/+12
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>
2021-05-21tdf#106370 android: Make inserting pictures workMichael Weghorn3-14/+3
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 1bc42472200c32c9a0a10dd1c3cd6c6a8a5d47d2 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 8d977511e3ab755da65d34a0bd618ef3c9db90c7 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>
2021-05-19tdf#142348 android: Avoid extra refresh after loading docMichael Weghorn1-1/+8
commit 1bc42472200c32c9a0a10dd1c3cd6c6a8a5d47d2 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>
2021-05-11android: Don't crash trying to process non-existing file from recentsMichael Weghorn1-0/+3
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>
2021-05-07tdf#142153 android: Delete unused textures immediatelyMichael Weghorn1-8/+6
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>
2021-05-05tdf#135136 Android: Don't hardcode height of TextViewsMichael Weghorn1-2/+2
Otherwise the text gets cut off when using a large system font size. Change-Id: I265d57ae310e39e9e452f6e744f17ed4807a00b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115134 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-23android: Some trivial style improvementsMichael Weghorn15-37/+28
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>
2021-04-23android: Drop unused FileUtilities membersMichael Weghorn1-41/+1
... and make its static 'LOGTAG' member final. Change-Id: I6d16bc76590341a60db9e123d20d81dcd7adba71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114545 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-23android: Drop unused FolderIconView classMichael Weghorn1-204/+0
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>
2021-04-23android: Offer 'Save As' in readonly modeMichael Weghorn6-10/+12
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>
2021-04-16tdf#95615 android: Don't offer "Save" after opening templateMichael Weghorn2-14/+39
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>
2021-04-16android: Show file picker for new docs on "Save As"Michael Weghorn4-76/+32
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>
2021-04-16android: Drop unused 'FileUtilities#doAccept'Michael Weghorn1-17/+0
Change-Id: I8b7f268862c3800012548376b3e60ac1f7dca9e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114151 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-16android: Allow printing and PDF export regardless of modeMichael Weghorn1-3/+8
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>
2021-04-16android: Merge 2 'LOKitTileProvider#printDocument' methodsMichael Weghorn1-14/+11
... and move the check for a new enough SDK version to the beginning. Change-Id: I7f5528985b8c43e218b88899409fdd22b640f72e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114145 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-16android: Ask where to save PDF file on exportMichael Weghorn8-45/+70
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>
2021-04-16android: Add a "Save As..." menu entryMichael Weghorn8-8/+125
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>
2021-04-16android: Extract copying Uri to stream in thread to separate methodMichael Weghorn1-31/+38
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>
2021-04-14android: Don't store whether spreadsheet in LibreOfficeMainActivityMichael Weghorn5-17/+6
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>
2021-04-12android: Drop some unused Turkish translationsMichael Weghorn1-9/+0
Those are leftovers; they're unused since commit a23bd42e9b2f6401c710ac95afcc3aa8f360d65c Date: Tue Apr 6 14:26:06 2021 +0200 android: Drop custom file abstraction + UI Change-Id: I898391cfccd465e4d18d51ee07ee847978872ef1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113885 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-12android: Drop 'LibreOfficeMainActivity#onSaveInstanceState'Michael Weghorn1-5/+0
It just calls the parent class method anyway. Change-Id: I802e75ad650b71d6daa08494ff812985bb844a5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113884 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-12tdf#95517 android: Rework app/doc lifecycle handlingMichael Weghorn5-103/+7
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>
2021-04-12android: Always create a temporary local copy of the docMichael Weghorn1-20/+18
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>
2021-04-12android: Turn 3 "internal" docs into raw resourcesMichael Weghorn4-63/+52
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>
2021-04-12android: Drop fallback of opening default docMichael Weghorn1-8/+2
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>
2021-04-12android: Extract method to copy streamMichael Weghorn1-26/+37
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>
2021-04-12android: Add member for document URIMichael Weghorn1-14/+19
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>
2021-04-09android: Check result for CREATE_NEW_DOCUMENT IntentMichael Weghorn1-1/+1
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>
2021-04-09android: Request PERMISSION_WRITE_EXTERNAL_STORAGE againMichael Weghorn1-0/+18
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>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-119/+105
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>
2021-04-07tdf#141338 android: Make "Select file to open" view smallerMichael Weghorn2-4/+4
Use the same height as is used for the "Recent files" entries. Change-Id: Ia6c1e02507ac12b554eb042d6dd32c0fc78cb578 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113675 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-07android: Move "Recent files" below system file picker viewMichael Weghorn1-19/+19
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>
2021-04-07android: Drop custom file abstraction + UIMichael Weghorn36-3272/+51
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>
2021-04-01android: Actually show recently used in "Recent files" listMichael Weghorn1-19/+18
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>
2021-04-01android: Show files opened using system picker for recently usedMichael Weghorn3-28/+63
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>
2021-04-01android: Drop check for SDK version < 16Michael Weghorn1-14/+5
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>
2021-04-01android: Move code to get doc's display name from URI to static helperMichael Weghorn2-23/+29
Will be used in LibreOfficeUIActivity as well. Change-Id: Ie1b99f0d31dba1be263459d135ee7fcb36613a7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113457 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-04-01android: Extract opening of file to separate method 'openDocument'Michael Weghorn1-9/+12
The method will also be used from elsewhere in a follow-up commit. Change-Id: I94cbdfa9faf54fcb655233f43d13ced8740b88a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113456 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-03-31android: Don't mark doc changed on keypress in readonly modeMichael Weghorn1-2/+2
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>
2021-03-31android: Drop some unused importsMichael Weghorn2-6/+0
Change-Id: If72949f949cba23397d87c8f67b9434861f9bb7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113414 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-03-31android: Don't require that user presses 'Back' twice to exitMichael Weghorn4-21/+1
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>
2021-03-31android: Use system file picker to create new docsMichael Weghorn6-105/+105
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>
2021-03-31android: Only update file path for "real Save As"Michael Weghorn1-1/+3
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>
2021-03-31android: Drop unused 'newDocumentType' memberMichael Weghorn1-1/+0
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>
2021-03-31tdf#139350 android: Fix handling of new docsMichael Weghorn3-26/+19
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>
2021-03-31tdf#139350 android: Add param to allow a "real" "Save As"Michael Weghorn6-18/+40
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>
2021-03-31android: TileKitProvider: Optionally detect file type from documentMichael Weghorn3-10/+23
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 23:26:00 +0000