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>
It appears to have been unused since it was added
in
commit 78098b8494
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 a121074cbd
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>
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>
Since editing is disabled in Android Viewer for non-experimental
mode anyway, there's no need to tell the user it's not possible
to edit a specific document if it's readonly.
Replace the 'usesTemporaryFile' method with a more explicit
'isReadOnlyMode' method since ToolbarController shouldn't
have to worry about implementation details like whether
temporary files are used and the new method will be reused in other
places in a follow-up commit as well.
Change-Id: Iaccf5b40bd19887b9e76b982ce7252368871c716
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112692
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Don't make the possibility to select and copy text
depending on editing being enabled, i.e. experimental
mode being enabled in Android Viewer.
In a quick test, this worked just fine in read-only mode
as well, so tapping on text in a document now shows two
cursors around the tapped word, and allows adapting the
selection using these and copying to the clipboard
by using the corresponding toolbar entry.
Change-Id: Icbd9d055a6cc700b78711df178f594c7a9c5cfbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112673
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When a temporary file is created in Android Viewer
(e.g. when a file is passed from another app, like
a file explorer or an email app), still show the
original file name in the toolbar, instead of the
name of the temporary file (like
"LibreOffice1588848072959345750.tmp").
Change-Id: I86f5cebfa8e2986fe812ace16c0df324d1420955
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112643
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Without it, Android Viewer crashes in experimental editing
mode when e.g. opening the sample doc and clicking into the
text area.
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: org.libreoffice, PID: 6152
E AndroidRuntime: java.lang.NullPointerException: Attempt to read from field 'float android.graphics.RectF.left' on a null object reference
E AndroidRuntime: at org.mozilla.gecko.gfx.RectUtils.scale(RectUtils.java:45)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlayView.convertToScreen(DocumentOverlayView.java:194)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlayView.repositionWithViewport(DocumentOverlayView.java:184)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlayView.changeGraphicSelection(DocumentOverlayView.java:157)
E AndroidRuntime: at org.libreoffice.overlay.DocumentOverlay$11.run(DocumentOverlay.java:199)
E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:883)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:100)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
Change-Id: Ibff148a5d83413b4eed8a054b0143c9dae4e5537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97632
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Since the 'refresh()' in 'LOKitThread::loadDocument' is
not executed synchronously but posted to the main handler,
this needs to be synchronized to prevent the document from
being deleted while it's being used.
The problem when pressing the "back" button while loading
the document was that LOKitThread::closeDocument would
cause the document to be deleted while it was still
being used, causing a crash on C++ side when using the
dangling pointer to the document in function
'doc_getDocumentType' (desktop/source/lib/init.cxx).
Change-Id: I37da4c4cf8d787327d72c2f449d9cef5d79223c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91460
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
'CALLBACK_DOCUMENT_PASSWORD' needs to be handled
when opening a password-protected file, so don't
ignore it for the plain viewer case.
This makes a password prompt appear as expected
when trying to open a password-protected (encrypted)
file with Android Viewer, regardless of whether the
experimental editing option is enabled or not.
Change-Id: Ib7e969a53a484df3e2c7be1a0df4c81a48668045
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91228
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This also prevents some static analysis tool from
issuing a false positive that "The application uses
implicit intent that may be insecure under certain
conditions".
Change-Id: I1d4198b1c26c764c927d99c9a9e144da96ebc109
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90457
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This fits better than the "File Explorer Settings" one.
The whole "General" section was hidden before when editing
mode was disabled for the build ('!BuildConfig.ALLOW_EDITING').
Since the language setting is unrelated to this, no longer
do so, but explicitly remove the two other entries in this group,
namely "ENABLE_DEVELOPER" and "ENABLE_EXPERIMENTAL".
Change-Id: I64d1abef38d7669fc1072b380f497ca83e23f265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90096
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... in which case the handling of the previous three callbacks makes the
cursor (that can be used to do a manual selection) shown in addition
to the selection rectangle.
As a side note, the cursor previously shown in Calc was incorrect anyway
when doing a search, it was always at the top-left, and spanning nothing
(instead of the actual cell that was highlighted by the "selection rectangle").
In a quick test, this worked as expected in Writer with editing
capability enabled:
* when doing a search, the search result was highlighted, but no cursor
shown
* when long-tapping on a word, that word was highlighted and the cursor
was shown, allowing to adapt text selection as needed (e.g. to do
copy & paste in the next step).
Since the cursor is shown by handling the other callbacks, and it is just hidden
again, the cursor can still show up for a short moment before
being hidden again, but I see no easy way to avoid this, since
there seems to be no easy way to determine in the
'CALLBACK_TEXT_SELECTION{,_START,_END}' handling whether this
was called due to a search or some other event (like long-tapping on
a word in Writer with editing feature enabled).
Change-Id: I0ae85cd10b91582b2bd8ec9891bae5c832161710
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90093
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of "Enter" key that inserted a newline when clicked.
Instead, start a search in downward direction when the search button
is clicked, which makes using the search feature more intuitive.
I quickly tested with both, Writer and Calc.
Change-Id: Iffc9f6115e558721b34d8fb4ae2ed4a36c4a7aa5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90092
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The naming for the directions UP and DOWN were used the wrong way
around, which was also apparent when looking at
'android/source/res/layout/toolbar_bottom.xml', where icon
'"@drawable/ic_search_direction_down"' was assigned to the
button with ID "@+id/button_search_up" (and vice versa).
Adapt the naming to avoid confusion.
Change-Id: I5cf59f1789f2c12651ce6a5638d559658d9d4deb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90091
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
I cannot tell how to reproduce (how to open a file of "invalid type"?),
but had a crash with this stacktrace in adb log at some point
when testing various scenarios with the Android Viewer app.
It shows that no proper value was assigned for the resource ID,
leaving the default 0. Just don't set an icon in this case.
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: org.libreoffice, PID: 8749
E AndroidRuntime: android.content.res.Resources$NotFoundException: Resource ID #0x0
E AndroidRuntime: at android.content.res.ResourcesImpl.getValueForDensity(ResourcesImpl.java:246)
E AndroidRuntime: at android.content.res.Resources.getDrawableForDensity(Resources.java:905)
E AndroidRuntime: at android.content.res.Resources.getDrawable(Resources.java:845)
E AndroidRuntime: at android.content.Context.getDrawable(Context.java:687)
E AndroidRuntime: at android.support.v4.content.ContextCompat.getDrawable(ContextCompat.java:358)
E AndroidRuntime: at org.libreoffice.ui.RecentFilesAdapter.onBindViewHolder(RecentFilesAdapter.java:73)
E AndroidRuntime: at org.libreoffice.ui.RecentFilesAdapter.onBindViewHolder(RecentFilesAdapter.java:25)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Adapter.onBindViewHolder(RecyclerView.java:6673)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:6714)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:5647)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:5913)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5752)
E AndroidRuntime: at android.support.v7.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:5748)
E AndroidRuntime: at android.support.v7.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2232)
E AndroidRuntime: at android.support.v7.widget.GridLayoutManager.layoutChunk(GridLayoutManager.java:556)
E AndroidRuntime: at android.support.v7.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1519)
E AndroidRuntime: at android.support.v7.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager.java:614)
E AndroidRuntime: at android.support.v7.widget.GridLayoutManager.onLayoutChildren(GridLayoutManager.java:170)
E AndroidRuntime: at android.support.v7.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:3812)
E AndroidRuntime: at android.support.v7.widget.RecyclerView.onMeasure(RecyclerView.java:3225)
[...]
Change-Id: I05594c3da26125a18be9226f290430aa9c7fa14c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90090
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This fixes as another crash with Android Viewer that
could (ocassionaly) be observed by
* open some ODT document
* press the "back button" while the document is still
being loaded
* repeat steps 1-2 until the crash occurs
Corresponding 'adb logcat' output:
I LibreOfficeMainActivity: onDestroy..
I LOKitTileProvider: Document destroyed: /storage/emulated/0/Download/simple.odt
D LOKitThread: mTileProvider==null when calling updatePartPageRectangles
D AndroidRuntime: Shutting down VM
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: org.libreoffice, PID: 9190
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke interface method 'boolean org.libreoffice.TileProvider.isSpreadsheet()' on a null object reference
E AndroidRuntime: at org.libreoffice.LOKitThread.refresh(LOKitThread.java:159)
E AndroidRuntime: at org.libreoffice.LOKitThread.access$000(LOKitThread.java:26)
E AndroidRuntime: at org.libreoffice.LOKitThread$1.run(LOKitThread.java:239)
E AndroidRuntime: at android.os.Handler.handleCallback(Handler.java:883)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:100)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
Change-Id: I9787a13b3485a87a133f8b5e4e03bbf3618fb2f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90089
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
'mTileProvider' can be null here, e.g. while loading the document.
This fixes a crash that could be reproduced e.g. by
* open a document
* press the "back button" while the document is still
being loaded
(Most easily reproducibly right after app installation, since
loading the first doc takes a very long time then.)
Relevant log messages from `adb logcat` output:
E AndroidRuntime: java.lang.RuntimeException: Unable to stop activity {org.libreoffice/org.libreoffice.LibreOfficeMainActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'void org.libreoffice.LOKitTileProvider.cacheDocument()' on a null object reference
E AndroidRuntime: at android.app.ActivityThread.callActivityOnStop(ActivityThread.java:4624)
E AndroidRuntime: at android.app.ActivityThread.performStopActivityInner(ActivityThread.java:4594)
E AndroidRuntime: at android.app.ActivityThread.handleStopActivity(ActivityThread.java:4669)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:233)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173)
E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:107)
E AndroidRuntime: at android.os.Looper.loop(Looper.java:214)
E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7356)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
E AndroidRuntime: Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void org.libreoffice.LOKitTileProvider.cacheDocument()' on a null object reference
E AndroidRuntime: at org.libreoffice.LibreOfficeMainActivity.onStop(LibreOfficeMainActivity.java:427)
E AndroidRuntime: at android.app.Instrumentation.callActivityOnStop(Instrumentation.java:1466)
E AndroidRuntime: at android.app.Activity.performStop(Activity.java:8018)
E AndroidRuntime: at android.app.ActivityThread.callActivityOnStop(ActivityThread.java:4616)
E AndroidRuntime: ... 13 more
Change-Id: I9f8a9329801b721dbfbc0a49c150f88ec341059c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90088
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
'mViewportMetrics' can be null here, e.g. while the document is
still being loaded.
This fixes a crash that happened e.g. when tapping on the screen
while document was still being loaded.
Change-Id: Ib3f237ecf64c05a5736d97e00b46d0de2ef051a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90048
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of hard-coding the use of English as default
locale and allowing manually selecting another language,
this now makes the system's default locale to be used
by default in the Android Viewer. It's still possible to
explicitly select another language to override that.
In case there is no localization for the system locale,
an automatic fallback to English happens anyway, so there
should be no need to explicitly set the locale to English
in that case either.
Change-Id: I0b8cfafea6a4659c3657522cfd5895c00f25f054
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85583
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously, the call to 'ColorPaletteAdapter::setColorPalette' from
the 'ColorPickerAdapter' constructur (via 'initializeColorPalette')
would not just set the color palette, but also apply the color at
index (0, 0) to the current selection, since
'ColorPaleteAdapter::setPosition' calls
'colorPaletteListener.applyColor' after setting the position.
This is an undesirable side effect, and led to the situation described
in tdf#115698 that cell A1 would always get black background when
opening a spreadsheet in the Android viewer, since black is the color
at 'color_palette[0][0]' by default and cell A1 is explicitly selected
when Calc first opens, s. the 'CalcHeadersController' constructor.
For Writer, something similar could be reproduced by selecting a
word in a document using long-tap. If experimental editing mode was
enabled, that word got black background (other words selected
later didn't).
To avoid this, make 'ColorPaletteAdapter::setColorPalette' just set
the color palette and set back the values that indicate what is
selected but don't apply any color. (And make 'setColorPalette'
just take the palette as parameter, and set 0 for both start values,
as the only caller was doing as well).
Change-Id: I0fa720ac6550102701a2c82905c9720aab6daab2
Reviewed-on: https://gerrit.libreoffice.org/85044
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
The comment mentioning "Calc has a fixed zoom at 1x
and doesn't allow zooming for now" was there since
support for the Calc UI was added in commit
02f3c4848a ("Calc UI
on Android Viewer") in 2017. That seems no longer to be
the case however, probably since commit
498dceb43f
("sc lok: Implement hi-dpi and zoom for spreadsheets.").
Zooming in and out was working just fine when I tested this
with Android Viewer using a spreadsheet containing some text
and numbers, as well as a chart and an image.
Therefore, allow zooming for Calc as well.
Don't allow to set min zoom below the page width for Calc as
somewhat suggested by the existing comment ("applies to all
types of document; in the future spreadsheets may be
singled out"). I don't see a particular reason for this and
using 0f for minZoom would break double-tap zoom.
Change-Id: Ib08439edbbac59a00005213b533df5792da965ee
Reviewed-on: https://gerrit.libreoffice.org/84421
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
when the user wildly switches documents in fast succession, mDocument
can be null - not creating a cache file definitely is better than a hard
crash....
Also onSaveInstanceState is meant for lightweight operations (e.g.
storing what file was openend and what position it was scrolled to), not
for backend-storing of data, so move creation of cache file to onStop
instead.
Change-Id: I2452ef24e309ea4a9594eb723e893798b9b47d98
Reviewed-on: https://gerrit.libreoffice.org/82774
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
typie is ArrayList<Float> - and code divides by/multiplies by zoom
factor later on, so won't keep whole numbers/changing remaining code to
Long would require rounding or reworking the rest of the code as well...
fallout from https://gerrit.libreoffice.org/#/c/82572/
Change-Id: I3f3c46c59f9a310bf48b8cb8b533fe51c9d6645e
Reviewed-on: https://gerrit.libreoffice.org/82775
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
This simplifies lots of logic in the clients, making it trivial to get
good row/column header alignment at any zoom. Ultimately TWIPS here are
highly misleading print-twips, and in this state are ~impossible to map
to pixels accurately unless all data is present back to the origin
(which is not the current approach).
Change-Id: I6ca30e77865b62e886e23860f7c23350e544c9fc
Reviewed-on: https://gerrit.libreoffice.org/82572
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Typically application should handle key press/release and multiple
actions. The onKeyPreIme may be used to handle some keys early and it's
not needed for writing text. And even if there would be a reason to use
it, then it should return true to notify that the event was handled
(otherwise we will get onKeyDown event for the same key).
Change-Id: I49ce7f411fac92ff86ca042a7f7467e910e46350
Reviewed-on: https://gerrit.libreoffice.org/66708
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
missing break causes bug on buttons on Formatting tab
This patch is sponsored by ULAKBIM/Pardus project.
Signed-off-by: Mert Tumer <merttumer@outlook.com>
Change-Id: I8a20b542aa319591e9dea5591ed554954222d690
Reviewed-on: https://gerrit.libreoffice.org/62756
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.1004@gmail.com>
Michael Weghorn