There is no reason to use a custom project structure. The usual Android
project structure makes the development of new features easier using a
modular approach. Therefore, the logic of gradle files was divided into
different levels, gradle scripts was migrated to kotlin,
dependency definitions was moved into toml file.
No one java or kotlin file has been changed.
These changes based on:
1) Android build structure:
https://developer.android.com/build/android-build-structure
2) Migrate your build to version catalogs:
https://developer.android.com/build/migrate-to-catalogs
3) Migrate your build configuration from Groovy to Kotlin
https://developer.android.com/build/migrate-to-kotlin-dsl
Note: The source module has not been renamed to app (this is the usual
name for a top-level application subproject), because I currently do not
know what other changes will need to be made besides gradle scripts
(maybe in the Makefiles or in other) for a correct build. Additional
analysis required.
Change-Id: Ic11efdb51524e795b8c6e2605b6501d9699c525c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195939
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Aragonese currently translated at 18.1% (21 of 116 strings)
Change-Id: I8b208ee3ca8661c1fc8e1e66dece7161b2c07210
android-viewer translated using Weblate
Aragonese currently translated at 15.5% (18 of 116 strings)
Change-Id: Ie203b67a347628d8242bd9dd1bf41e589ea4df65
android-viewer translated using Weblate
Kazakh currently translated at 29.3% (34 of 116 strings)
Change-Id: Iab1d7ff35baa1bde2af46b69c5172342e9eb6d23
android-viewer translated using Weblate
Kazakh currently translated at 18.9% (22 of 116 strings)
Change-Id: I33ca66d0fcadc46a8909d6c861d9fd8377c50317
android-viewer translated using Weblate
Aragonese currently translated at 3.4% (4 of 116 strings)
Change-Id: I69d66db7d7988181bc464563254222566d3efab2
Added translation for android-viewer using Weblate (Aragonese)
Change-Id: I6e8a4c7916e19b0d8645d34c14a8ff27eaaa371d
android-viewer translated using Weblate
Kazakh currently translated at 12.9% (15 of 116 strings)
Change-Id: I1667da5548709f920b8333a476a0216282385fb0
Co-authored-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Co-authored-by: Baurzhan Muftakhidinov <baurthefirst@gmail.com>
Co-authored-by: Ildar Mustafin <anmitali198@gmail.com>
Co-authored-by: Weblate <noreply@documentfoundation.org>
Translate-URL: https://translations.documentfoundation.org/projects/android-viewer/android-strings/an/
Translate-URL: https://translations.documentfoundation.org/projects/android-viewer/android-strings/kk/
Translation: android-viewer/android-strings
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196339
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
All settings displayed in the SettingsActivity
are related to editing, and only displayed
if the build includes the editing feature.
Therefore, don't show the settings menu item when
using a build config that doesn't include that feature,
i.e. only show the item for the strippedUIEditing
product flavor, but not the strippedUI or quest
ones. For the latter two, an activity only displaying the
"General" heading would be shown, but nothing
else could be done, which was rather confusing.
Change-Id: I2a1a616c1faee18583320ccb16e717dc933d6565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194534
Code-Style: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of having one method that enables/disables a menu
item and one that shows/hides it, let
ToolbarController.setItemVisible take care of both.
Use that method also where ToolbarController.enableMenuItem
was used before and drop that now unused method.
The way that hiding/disabling menu items was and is used
is to do that when they are not applicable, in which case
it seems reasonable to consistently both hide and disable
them at the same time.
Quoting from the MenuItem.setVisible doc [1]:
> Sets the visibility of the menu item. Even if a menu item is not
> visible, it may still be invoked via its shortcut (to completely disable
> an item, set it to invisible and disabled).
[1] https://developer.android.com/reference/android/view/MenuItem#setVisible(boolean)
Change-Id: I5d05f5324a1fb5c69e38302b59b2ad56a45342ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194533
Tested-by: Jenkins
Code-Style: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
For Meta Quest devices running Horizon OS, it is required
that the default activity size is set to 1024x640,
see also [1].
Add a new product flavor "quest" with an additional
AndroidManifest_quest.xml that sets the corresponding
attributes for the 2 main activities.
Due to the manifest merge logic as described at [2],
it is sufficient to only specify those extra
attributes. The rest is taken from the main
AndroidManifest.xml used for all build flavors.
This makes the LibreOffice Viewer app on a Meta Quest 3
VR headset open in the specified size in landscape mode,
while it was previously opening in a smaller window in
portrait mode.
Also, disable the experimental editing mode for that product
flavor, as it seems to be even more experimental when tested
on a Meta Quest than on another Android device.
(Document UI doesn't update while typing.)
The build flavor can either manually be selected in
Android Studio ("Build" -> "Select Build Variant")
or specified for the gradle target, e.g.
./gradlew assembleQuestRelease
[1] https://developers.meta.com/horizon/documentation/android-apps/panel-sizing
[2] https://developer.android.com/build/manage-manifests#merge-manifests
Change-Id: Ia2b234f50694553d2b3458e4c57e8bb1b1a5baa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194532
Code-Style: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's the same for both product flavors, so
define it once for the main one that is the base
for both of them, and all upcoming flavors, too.
Change-Id: I0532332c0780bac5099a2d98601664b3cf709777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194531
Tested-by: Jenkins
Code-Style: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
One issue was addressed in previous commit
Change-Id: Iafb7a32668718afc638b8273a05a9d0618f85550
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 19 16:36:25 2025 +0100
tdf#164082 android: Drop storage permission and support for file:// URIs
Change-Id: I1bd43717e9bd19719cb197d15c431670741d584b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194217
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In the past, LibreOffice Viewer for Android was directly
accessing storage in order to open/save files and when
exporting to PDF.
However, that was switched to using Android's Storage
Access Framework [1], available since Android 4.4
(API level 19), i.e. it is available in all Android
versions supported by the app.
In the past, in order to directly access storage, permission
android.permission.WRITE_EXTERNAL_STORAGE was needed.
That permission no longer has any effect in
Android 11 (API level 30) or higher, quoting 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.
Since PDF export was also switched to use the
Android Storage Framework mechanism in
commit 9ebcb80e2e
Author: Michael Weghorn
Date: Thu Apr 15 11:22:46 2021 +0200
android: Ask where to save PDF file on export
, eventually drop the permission now.
As mentioned in
commit 7d9db806d6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Apr 9 11:24:16 2021 +0200
android: Request PERMISSION_WRITE_EXTERNAL_STORAGE again
which re-requested the permission before PDF export was
ported to use the Android Storage Framework, the case of
applications passing documents via a file:// URI would also
require storage permission in order to access the file.
However, apps that properly pass the file should pass a
content:// URL instead.
Quoting from the Android 7.0 Behavior changes
documentation [4]:
> Passing file:// URIs outside the package domain may leave the receiver
> with an unaccessible path. Therefore, attempts to pass a file:// URI
> trigger a FileUriExposedException. The recommended way to share the
> content of a private file is using the FileProvider.
(Using content:// URIs has been possible long before Android 7.0,
however.)
Therefore, drop support for file:// URIs as well, which
will prevent apps that would otherwise try to pass file://
URIs from trying to do that for Android Viewer.
If this results in any app no longer being able to
open documents in LibreOffice Viewer, that app most
likely needs to be adjusted to pass a content:// URI instead,
which will also make it work for newer Android versions.
(Total Commander is one case that apparently doesn't do
that yet, previously resulting in a crash when storage
permissions were not granted, see tdf#164082. That is
reproducible in an Android 7.0 AVD, while opening
the file fromm other apps, e.g. from Material Files [5],
works perfectly fine, using content:// URIs.)
Eventually dropping the permission makes clear that
the app does not need direct storage access, which is
also relevant for security reviews, and addresses this
lint issue from android/source/lint-baseline.xml:
<issue
id="ScopedStorage"
message="WRITE_EXTERNAL_STORAGE is deprecated (and is not granted) when targeting Android 13+. If you need to write to shared storage, use the `MediaStore.createWriteRequest` intent."
errorLine1=" <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>"
errorLine2=" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~">
<location
file="AndroidManifest.xml"
line="9"
column="36"/>
</issue>
That file will be updated/regenerated in a separate
commit.
[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
[4] https://developer.android.com/about/versions/nougat/android-7.0-changes
[5] https://f-droid.org/en/packages/me.zhanghai.android.files/
Change-Id: Iafb7a32668718afc638b8273a05a9d0618f85550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194215
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This android.hardware.usb.host feature element was added in
commit 5ada20b358
Author: brainbreaker <gautamprajapati06@gmail.com>
Date: Sun Feb 26 02:27:43 2017 +0530
Improve the Document Provider UX
, when it was still used for the file/document access
logic implemented in the app that was also explicitly
handling USB device support.
That one was dropped in
commit a23bd42e9b
Author: Michael Weghorn
Date: Tue Apr 6 14:26:06 2021 +0200
android: Drop custom file abstraction + UI
, so also drop this from the Android manifest.
Change-Id: Icbd8fa86d1a9a4d8dfb8fccd90846a432a329b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194214
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No need to have a member for this, just pass the
param directly to the VelocityBiasStrategy ctor.
Change-Id: If8fa006afbbb082a0885cef371c89721c64eb3c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194195
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Regenerate the file (by removing the old one and
running a build).
This addresses the
> Task :lintReportStrippedUIEditingDebug
Lint found 1 hint (and 199 errors and 2 hints filtered by baseline lint-baseline.xml)
2 errors/warnings were listed in the baseline file (/home/michi/development/git/libreoffice-WORKTREE-android/android/source/lint-baseline.xml) but not found in the project; perhaps they have been fixed?
notice seen without this commit in place.
Change-Id: I000dc86dbf6ee5ce622f6c26fc05ad4f511ec0bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194106
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Stop calling the method RecyclerView.setHasFixedSize
meant to allow optimiziations (see doc at [1]), because
that is not compatible with the size used in the layout
file.
This prepares for upcoming commit
Change-Id: Id22a2130379fb11372d210049b4f02df29ec52d8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Nov 17 12:56:47 2025 +0100
android: Update com.google.android.material:material to 1.13.0
which would otherwise trigger errors like this one:
> Task :lintReportStrippedUIEditingDebug
Wrote HTML report to file:///home/michi/development/git/libreoffice-WORKTREE-android/android/source/build/reports/lint-results-strippedUIEditingDebug.html
Lint found 4 errors, 1 hint (and 199 errors and 2 hints filtered by baseline lint-baseline.xml)
2 errors/warnings were listed in the baseline file (/home/michi/development/git/libreoffice-WORKTREE-android/android/source/lint-baseline.xml) but not found in the project; perhaps they have been fixed?
Lint found 4 errors and 1 hint. First failure:
/home/michi/development/git/libreoffice-WORKTREE-android/android/source/src/java/org/libreoffice/FontController.java:257: Error: When using `setHasFixedSize() in an RecyclerView, wrap_content cannot be used as a value for size in the scrolling direction. [InvalidSetHasFixedSize from androidx.recyclerview.lint.recyclerview]
recyclerView.setHasFixedSize(true);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Task :lintStrippedUIEditingDebug FAILED
[1] https://developer.android.com/reference/androidx/recyclerview/widget/RecyclerView#setHasFixedSize(boolean)
Change-Id: I34b7b88506d549aa38d06e292ce8a6e96057e619
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194105
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
See [1]:
> Currently, there are multiple ways to set a property with Groovy DSL syntax:
>
> ---
> propertyName = value
> setPropertyName(value)
> setPropertyName value
> propertyName(value)
> propertyName value
> ---
>
> The latter one, "space-assignment", is a Gradle-specific feature that is
> not part of the Groovy language. In regular Groovy, this is just a
> method call: propertyName(value), and Gradle generates propertyName
> method in the runtime if this method hasn’t been present already. This
> feature may be a source of confusion (especially for new users) and adds
> an extra layer of complexity for users and the Gradle codebase without
> providing any significant value. Sometimes, classes declare methods with
> the same name, and these may even have semantics that are different from
> a plain assignment.
>
> These generated methods are now deprecated and will be removed in Gradle
> 10.0, and both propertyName value and propertyName(value) will stop
> working unless the explicit method propertyName is defined. Use explicit
> assignment propertyName = value instead.
This addresses warnings seen during the Android Viewer build like:
> Configure project :
Build file '/home/michi/development/git/libreoffice-WORKTREE-android/android/source/build.gradle': line 19
Properties should be assigned using the 'propName = value' syntax. Setting a property via the Gradle-generated 'propName value' or 'propName(value)' syntax in Groovy DSL has been deprecated. This is scheduled to be removed in Gradle 10.0. Use assignment ('url = <value>') instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.13/userguide/upgrading_version_8.html#groovy_space_assignment_syntax
at build_7nyveb4ly8p00ms61u72dhwli$_run_closure1$_closure2$_closure4.doCall$original(/home/michi/development/git/libreoffice-WORKTREE-android/android/source/build.gradle:19)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
at build_7nyveb4ly8p00ms61u72dhwli$_run_closure1$_closure2.doCall$original(/home/michi/development/git/libreoffice-WORKTREE-android/android/source/build.gradle:18)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
[1] https://docs.gradle.org/8.13/userguide/upgrading_version_8.html#groovy_space_assignment_syntax
Change-Id: I963b3a1b38912d134619293cd9197f8545ed5515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194103
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When the size of the app window for LibreOffice Viewer
changes (e.g. because a user manually resized the
window on a desktop device or when rotating a device),
recalculate the document position and zoom factor
to make proper use of the newly available space.
On app window resize/rotation, GeckoLayerClient sends
a LOEvent.SIZE_CHANGED event (see e.g.
GeckoLayerClient.setViewportSize).
In order to achieve the desired result, adjust the
corresponding event handler to call LOKitThread.redraw
with a `resetZoomAndPosition` param of true instead of
false.
Change-Id: I2a088975e6083ce72641c8e2ea9d111015fb50bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193967
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Simplify this further after
Change-Id: Icae6258fa4516348dc2c8978f42024d9884216f7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Nov 13 12:40:50 2025 +0100
android: Skip (not) reading from null map
Change-Id: I1c44456bc6e5a17e2dae0c03d1dfaf54dcbbea09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193963
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The only caller of setPrefs passes a null param.
Therefore, drop the param and the logic that would
only have been relevant for a non-null param.
Change-Id: Icae6258fa4516348dc2c8978f42024d9884216f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193962
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead call the logic to get the main thread directly
in JavaPanZoomController.checkMainThread.
Change-Id: I5fe02ba038b0e4ea954012e2a7296f59113e1eb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193960
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
JavaPanZoomController is the only implementation.
Use that one directly instead, which also removes
the need for some casting in GeckoLayerClient.
Change-Id: Id9c4a8ed154b66ac81274eb1648477163eb546a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193959
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Now with
Change-Id: If1ebe5da94d8193794cce41e052bd401e0c8adbc
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Nov 13 10:59:12 2025 +0100
android: Move GeckoLayerClient.notifyReady logic to ctor
in place, the member is already set to true in the ctor,
so there's no need to check for that anymore.
Change-Id: Idb762da74ed334e9ffb56e709ec92c960bc82113
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193954
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of calling the method after creating the
object, move the logic into the ctor itself.
This also allows to make a few more members final.
Change-Id: If1ebe5da94d8193794cce41e052bd401e0c8adbc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193953
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass the LayerView as a param to the ctor, instead
of calling GeckoLayerView.setView separately afterwards.
This also allows to make two more members final.
Change-Id: Ic3ffcde590a84fec4413ef6225aa8417e3960f84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193950
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's never set, so drop logic only relevant if
it were ever used.
See also previous commit
Change-Id: Ie83eb651500e5beb892492b681e03ce715800069
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 12 23:09:59 2025 +0100
android: Drop JavaPanZoomController.startingNewEventBlock
that dropped dead code that would have set the state if
it had ever been reached.
Somewhat related to this, also drop the mention of
"default-prevented" events from the TouchEventHandler doc, as this
is no longer a thing.
Change-Id: I79e918b659099129f733d4fcc7b92d5d35bb6085
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193928
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... and related logic.
The only (remaining) caller of the method calls it with
a value of false for the `waitingforTouchListeners` param,
in which case the method doesn't do anything.
Also drop documentation related to processing events in
blocks, as that is no longer the case.
TouchEventHandler.isDownEvent is now unused, so
drop it, too.
Change-Id: Ie83eb651500e5beb892492b681e03ce715800069
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193926
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As has become clear with
Change-Id: Iae8392bc6e8edd7cafae0602b94c270c23f1f7bd
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 12 16:41:57 2025 +0100
android: Drop queue logic in TouchEventHandler
, that class doesn't actually do anything useful
anymore at this point in time, so drop and correspoinding
logic altogether.
Change-Id: I4ed7816f3dc1c63a2b6a7974544878c02fa9acfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193923
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Earlier commit
Change-Id: I145531e23f9d076f79bdb6c0d886f33e05d818f9
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 12 16:08:56 2025 +0100
android: Drop two TouchEventHandler members that are always false
dropped the last `mEventQueue.add` call adding something
other than null to the event queue.
Therefore, the queue can by now either be empty or
contain only null values, both of which results in
the processEventBlock() logic not doing anything
relevant.
Therefore, drop the event queue and the
processEventBlock() logic altogether.
Further simplification/cleanup can happen in upcoming commits.
Change-Id: Iae8392bc6e8edd7cafae0602b94c270c23f1f7bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193922
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It gets set to true in the ctor, and since previous
commit
Change-Id: Iaad65954df69b11e1463a54097116001e7048cfa
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 12 16:15:51 2025 +0100
android: Drop always true TouchEventHandler.processEventBlock param
it is also obvious that it never gets set to any
other value.
Therefore, drop that member and all (dead) code that
would only be relevant if it ever had a value of false.
Change-Id: Iaad65954df69b11e1463a54097116001e7048cfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193900
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Ivan Vladimirovich Kuznetsov