After new translations got added in
commit 40f850279d
Author: Weblate <noreply@documentfoundation.org>
Date: Wed Dec 13 15:33:50 2023 +0100
android-viewer translated using Weblate (Welsh)
, the android build started failing like this:
> Task :lintReportStrippedUIEditingDebug
Wrote HTML report to file:///home/michi/development/git/libreoffice-WORKTREE-android/android/source/build/reports/lint-results-strippedUIEditingDebug.html
> Task :lintStrippedUIEditingDebug FAILED
Lint found 3 errors, 0 warnings (232 errors, 3 warnings filtered by baseline lint-baseline.xml). First failure:
/home/michi/development/git/libreoffice-WORKTREE-android/android/source/res/values-hy/strings.xml:36: Error: Replace "..." with ellipsis character (…, …) ? [TypographyEllipsis]
<string name="action_save_as">Պահել որպես...</string>
~~~~~~~~~~~~~~
The full lint text report is located at:
/home/michi/development/git/libreoffice-WORKTREE-android/android/source/build/intermediates/lint_intermediate_text_report/strippedUIEditingDebug/lint-results-strippedUIEditingDebug.txt
FAILURE: Build failed with an exception.
Downgrade that type of lint check to severity informational
to not cause the build to fail.
(Changes to address these will need to be done in Weblate,
which is now the source of truth for translations.)
Change-Id: Ibc82f96d29c8ac76f98db0259e1ee3cae4a986f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160772
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In order to avoid introducing new lint errors,
also run the `lint<buildVariant>` gradle target when building
Android Viewer and set the `warningsAsErrors true`
lint option.
This makes the build fail on (new) lint errors.
See [1] for more details.
Downgrade missing translations and issues that can "suddenly"
appear without any code changes to the app itself to informational,
to prevent (CI) builds from suddenly starting to fail just because
a new Android Gradle Plugin version or external library becomes
available etc.
To be able to avoid introducing new issues without having to address
all existing ones right now, use a baseline file ("lint-baseline.xml")
as described at [2] which lists all existing issues, so they don't
result in a failing build.
Those should still be looked into at some point.
Updating the baseline file can be done by just removing the
existing one and running the build again. (Build will create the
new baseline file and fail on first run after deleting the file,
then find the new file and succeed in subsequent builds.)
[1] https://developer.android.com/studio/write/lint
[2] https://developer.android.com/studio/write/lint#customize-the-baseline
Change-Id: Iddbe432519ab3040c83c0e977a584b51d3ef1e5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160199
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Since these are produced by the build, they should also
be removed in the "clean" target.
Without this, Jenkins CI builds for the upcoming
Change-Id: Iddbe432519ab3040c83c0e977a584b51d3ef1e5b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Dec 8 14:57:14 2023 +0100
android: Make the build fail on new lint warnings
were seen failing, despite the example file no longer being
part of the generated resources since
commit 1d7b1e2d40
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 15 13:16:26 2023 +0100
android: Drop "More Info" item in "About" dialog
, but apparently the file was still lingering around
from previous builds.
Build failure/Lint error from CI build [1]:
> Task :lintReportStrippedUIEditingDebug
Wrote HTML report to file:///home/tdf/lode/jenkins/workspace/android_arm/android/source/build/reports/lint-results-strippedUIEditingDebug.html
> Task :lintStrippedUIEditingDebug FAILED
/home/tdf/lode/jenkins/workspace/android_arm/android/source/lint-baseline.xml: Information: 237 errors and 11 warnings were filtered out because they are listed in the baseline file, lint-baseline.xml
[LintBaseline]
/home/tdf/lode/jenkins/workspace/android_arm/android/source/res_generated/raw/example.odt: Error: The resource R.raw.example appears to be unused [UnusedResources]
Explanation for issues of type "UnusedResources":
Unused resources make applications larger and slow down builds.
The unused resource check can ignore tests. If you want to include
resources that are only referenced from tests, consider packaging them in a
test source set instead.
You can include test sources in the unused resource check by setting the
system property lint.unused-resources.include-tests =true, and to exclude
them (usually for performance reasons), use
lint.unused-resources.exclude-tests =true.
,
1 errors, 0 warnings (237 errors, 11 warnings filtered by baseline lint-baseline.xml)
FAILURE: Build failed with an exception.
This could also be reproduced locally:
After a
$ touch android/source/res_generated/example.odt
, the above error would on build, and neither `make clean`
nor `make android.clean` would remove the file and thus
fix the problem for subsequent builds.
Add removing the directory to the top-level and Android-specific
clean targets, so either of these commands now takes care of this.
[1] https://ci.libreoffice.org/job/gerrit_android_arm/33845/console
Change-Id: I91c83ce4ddb236d87d7c51f4dcce85e99aae0107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160612
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This was accidently added in
commit a21e7a76d7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Nov 9 10:24:13 2023 +0100
android a11y: Add content labels
and now reported by lint:
<issue
id="ExtraText"
message="Unexpected text found in layout file: "/>""
errorLine1=" />"
errorLine2=" ~~">
<location
file="res/layout/toolbar_bottom.xml"
line="481"
column="13"/>
</issue>
Change-Id: If4a17c4cd10450c2f5e13ead88a7511684ab9956
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160469
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`DocumentsContract.EXTRA_INITIAL_URI` was added in API level 26,
so only set it conditionally when that API level is avaible.
Change-Id: I6783e89f50354c017968b74cc45fb1a3b6faab83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160468
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
NDK 26 dropped support for API levels < 21 [1] [2].
Do the same for our Android build, to ease the
maintenance.
Adapt configure.ac accordingly and drop the
now obsolete code paths in Android Viewer
Java code.
This in also means that the same minSdkVersion will
be used for all architectures now, while API level 21
was already used for the 64-bit variants (for which
the minimum supported version was 21 anyway) and
API level 19 was used for x86 and 32-bit ARM when
building with NDK 24/25, API level 16 when building
with NDK 23.
According to [1] and [3], more than 99% of
Android devices have at least Android version 5,
i.e. support API level 21.
[1] https://github.com/android/ndk/issues/1751
[2] https://developer.android.com/ndk/downloads/revision_history
[3] https://apilevels.com/
Change-Id: I875e784dd4e62993f51059ae6a280d425cb49c0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160334
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Configure the gradle build to show detailed warnings
about the use of deprecated API, instead of just
> Task :compileStrippedUIEditingDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
With this in place, 78 specific warnings about the use
of deprecated API are now shown in the build output,
which can be addressed at some point.
Change-Id: I9f3b484b6dfad1fc57895efa7d3426b625030ee7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160198
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, the versionName for the LibreOffice APK/app bundle
included the build ID and vendor, was e.g.
"24.2.0.0.alpha1+/2972af9045a5/The Document Foundation".
That versionName would be split again to extract the build ID
and vendor to display them in the about dialog.
No longer include build ID and vendor in the `versionName`,
but use separate build config variables, similar to what
is done for the privacy policy.
This slightly simplifies the code for the about dialog.
But more importantly, the previous `versionName` scheme
would make it impossible to automate the F-Droid update
of the app, because the scheme is not compatible with
the expectations of F-Droid's update mechanism, see the
F-Droid merge request to update LibreOffice Viewer to 7.6.3 [1]
for more details, in particular the (eventually not merged)
commit [2] mentioning what manual steps would still be needed
when trying to semi-automate the update at least.
[1] https://gitlab.com/fdroid/fdroiddata/-/merge_requests/14080
[2] https://gitlab.com/fdroid/fdroiddata/-/merge_requests/14080/diffs?commit_id=bfc062a358dc574326a29f08e01c0e80cadd80cb
Change-Id: Ibede06d13095d8e83dcc88ee09a8a610d6a9de0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160150
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to
Change-Id: Iaa78f5a6020bea4ed80a1b41d3b23cc8d313813c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Nov 30 12:00:52 2023 +0100
android: Simplify version info handling for about dialog
, also simplify the handling of the vendor info text by
retrieving the text from the string resource right away.
Change-Id: I7d56b1814454be2bc8d13e01265f0a0db6d865be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160147
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
* Don't set and retrieve the placeholder text in/from
the TexView in the about dialog, but use the string
resource directly.
* Add the HTML code directly in the string resource,
rather than having to fiddle with that in the Java
code.
With this in place, only the version name and the
commit hash need to be replaced.
Since there is no placeholder text in the text view,
it's also no longer necessary to explicitly set an
empty string in case of an exception.
Change-Id: Iaa78f5a6020bea4ed80a1b41d3b23cc8d313813c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160146
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add the build dir (`android/source/build`) to the
directories to be removed when cleaning.
Previously, this was't cleaned, which could be seen
e.g. by the fact that a fresh build would result in
this warning being shown
> Task :compileStrippedUIEditingDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
while a
make android.clean
make android
after a full build wouldn't.
Change-Id: I00a4f8b1fda9fbefb3b8f806b1997eceded117fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160145
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is a prerequisite for updating the compile and target
SDK versions to API level 34, which requires and AGP minimum
version of 8.1.1.
Change-Id: I27d12ec3c9bc3dac8a5df18459a57f1a1e990197
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160085
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As described in more detail in
commit 45fbfbfeae
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Mar 27 17:04:37 2020 +0100
tdf#131622 android: Extract native libs again
, extracting native libraries was necessary for the NSS
library to be able to load modules like `libnssckbi.so`
at runtime. Without this, opening password-protected
files would fail.
However, this has in the meanwhile been addressed
differently in the following commit (probably in the
context of the online-based/Collabora Online app), so
extracting libs is no longer needed:
commit 16a7f98f99
Author: Mert Tumer <mert.tumer@collabora.com>
Date: Wed Sep 30 17:14:59 2020 +0300
Fix libnssckbi not found error on Android
This error causes Android App to be unable to
open Password-protected documents.
Change-Id: Iacbacb1c780025752e2447db325b075c58947818
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103658
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Therefore, no longer extract the libraries, which also addresses
addresses this warning shown during the build:
> Task :processStrippedUIEditingDebugMainManifest
.../android/source/AndroidManifest.xml:16:9-41 Warning:
android:extractNativeLibs should not be specified in this source AndroidManifest.xml file. See https://d.android.com/guide/topics/manifest/application-element#extractNativeLibs for more information.
The AGP Upgrade Assistant can remove the attribute from the AndroidManifest.xml file and update the build file accordingly. See https://d.android.com/studio/build/agp-upgrade-assistant for more information.
Change-Id: I867beea0bce8398806375048e87a152e1348d016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160079
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
For the layout containing the Calc address/formula bar,
explicitly set a background color that matches the theme.
Otherwise, those text views would be using white font on
white background when using dark theme, making the text
unreadable.
Change-Id: I5fdf9e04f8bb331ca6a57bf3046a7ebb9ccb0d1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160078
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Using "colorBackgroundFloating" requires API level 23 [1],
but our current minimum API level is 16 (when building with
NDK 23).
Therefore, define an own color `background_floating` instead
and use the correspodning color values from the material theme
(`background_floating_material_{dark,light}` depending on whether
dark/night mode is enabled or not.
This makes the app work again in a quick test with an x86 AVD
with API level 16 instead of crashing on startup.
Change-Id: I7b8378b42e9fc7430ec4ed263d4cb8b42027a930
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160077
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of using a TextView and setting `?attr/colorButtonNormal`
for the background color, just use a button right away, which also
makes sure that the proper button color is used and avoids
using `colorButtonNormal` only available from API level 21 on. [1]
Also drop the extra `LinearLayout` parent that was only containing
this one TextView.
While at it, drop an unused import.
[1] https://developer.android.com/reference/android/R.attr#colorButtonNormal
Change-Id: Ie2f7e2646d20f4051fb2513fb8fd72572ce19217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160076
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to how
Change-Id I2061878067d21dcd743ad6ca8d1018db323755d6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Nov 28 14:22:54 2023 +0100
tdf#124480 android: Use themed color for more icons
did for the icons in the toolbars, use the themed color for
the directory icon in the start activity as well.
While at it, switch to using the same shade of gray that
the toolbar icons also use.
And rename the icon to drop the "_grey" suffix, since this
is now themed and no longer using a hard-coded color.
Change-Id: I9fcf51b712a01aab3b9754bcfbd817c89171a64f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160075
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As already mentioned in
Change-Id I2061878067d21dcd743ad6ca8d1018db323755d6
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Nov 28 14:22:54 2023 +0100
tdf#124480 android: Use themed color for more icons
, do this:
> Given the icons are no longer hard-coded to be black,
> the files with a "_black" suffix will be renamed in
> a follow-up commit. (Separate commit to keep the
> diff clearer.)
Change-Id: Ie2d3433934569dc97530a35d88bda01802af96b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160074
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
These icons used in the toolbars were previously using a
hard-coded fill color.
Most of them were using black, but `ic_line` and `ic_rect`
used in the "Insert" tab of the bottom toolbar, were
previously using a lighter gray than the other items in there
for no apparent reason.
Switch all of them to use the themed `toolbar_foreground`
color that other icons are also using.
Together with
Change-Id Ic699fd1cecc607bd5e748648113336fe045e72b1
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Nov 28 13:13:12 2023 +0100
tdf#124480 android: Override icon color for dark theme
, this makes these icons use a light color when using
the dark system theme.
Given the icons are no longer hard-coded to be black,
the files with a "_black" suffix will be renamed in
a follow-up commit. (Separate commit to keep the
diff clearer.)
Change-Id: I2061878067d21dcd743ad6ca8d1018db323755d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160073
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a `values-night/colors.xml` that can be used to
override the colors specified in `values/colors.xml`
specifically for the dark theme.
Specify a light color for `toolbar_foreground`,
which is the color used for (most) toolbar icons,
both for the top-level as well as the bottom
toolbar.
This makes most icons show up in proper contrast
when using dark mode. Others are not making use of
the color defined here and will have to be looked
into separately.
Change-Id: Ic699fd1cecc607bd5e748648113336fe045e72b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160070
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of hard-coding the background color
for the 2 toolbars shown at the bottom
(`toolbar_bottom` and the color picker), use
"colorPrimary" from the theme.
Stop overriding "colorPrimary" in
`LibreOfficeTheme.Toolbar`, which would otherwise
result in a hard-coded white color being used again.
This makes those toolbars show up in a darker color
when dark theme is enabled.
Stop hard-coding the font color of the items in
the "Style" tab in the bottom toolbar to black, but
use the primary font color instead, so a light color
is automatically used when using the dark theme.
Change-Id: Ib09ca47e8695903cdfa9f4eb100dc88ecae652a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160069
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Support dark theme by inheriting from the
corresponding "AppCompat.DayNight" themes rather than
forcing the use of a light theme by using the
"AppCompat.Light" variants, s.a. [1].
With this in place, the app will automatically use a
dark theme for the Android UI controls when that's
enabled in the Android system settings.
Toolbars and menus mostly look as expected.
The bottom toolbar will be handled separately.
Icons will also have to be adapted in a follow-up
step to provide for better contrast, since they're
currently designed for light mode/white background.
[1] https://developer.android.com/develop/ui/views/theming/darktheme#themes-styles
Change-Id: Ia08edcc9d22b93caa67b146dcf90ee5fd02ee550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160068
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This ensures these 2 toolbars will also use the correct color
in dark mode once support for that is added in a subsequent
commit.
Change-Id: Idcea5096c4e4bdf8ddc6b28df0fc6df05074980b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160066
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to the desktop version, use a light gray background
color for the Calc header cells.
There was already code in place to draw darker gray background
to highlight the header cell when a cell in that row/column is
selected.
(The actually highlighted header cell didn't wasn't always the
correct one in a quick test, but that's independent of this change.)
Adapt that to always fill the rectangle, but use a lighter gray
(lower alpha value) when not selected.
Use a separate `Paint` object for the frame (stroke).
Set the frame color and text color to black instead of gray, for
better contrast to the light gray fill/background.
Change-Id: I0490811e928ebd1b3840242fc1aa4682b2786b00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159989
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Center the header text in the Calc header cell, to
make better use of the space. This is in line with
what the desktop version also does.
Setting the text alignment to `Paint.Align.CENTER`
is sufficient for centering horizontally.
There's no equivalent for centering vertically, so
calculate the position based on the text bounds.
Change-Id: Ia8d5d8434b703cb7daecd34ae70405883f22f0d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159988
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When using the PDF export feature in Android Viewer,
suggest a file name for the PDF file that matches
the current display name (which is usually the
file name, or "untitled" for a newly created doc
that hasn't been saved yet).
This can be achieved by setting `Intent.EXTRA_TITLE`
for the `ACTION_CREATE_DOCUMENT`. [1]
The `DocumentsContract.EXTRA_INITIAL_URI` already
set previously already results in the same
directory as the doc being preselected in the
file chooser:
> Callers can set a document URI through
> DocumentsContract#EXTRA_INITIAL_URI to indicate the initial location of
> documents navigator. System will do its best to launch the navigator in
> the specified document if it's a folder, or the folder that contains the
> specified document if not.
Filling in the current file name was suggested
in a Google Play review comment for the app.
[1] https://developer.android.com/reference/android/content/Intent#ACTION_CREATE_DOCUMENT
Change-Id: Idbd4a89416089f927e0232ce65161b43059ca46d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159959
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
While "Save" (i.e. saving back to the original location)
doesn't make sense when editing is disabled (because the
doc cannot be changed) and the menu entry is therefore
not available when the experimental editing mode is
disabled, "Save As" does make sense, e.g. in order to
save a copy of a file opened from another app.
The menu entry was there, but not working as expected,
a 0-byte file was created.
This is because `LibreOfficeMainActivity#saveFileToOriginalSource`
would return early if experimental mode is disabled.
No longer do that, but save the file as requested.
Change-Id: I5785b6060c4ba9cdf3e9c3591b9f941ab987bf4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159857
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of hard-coding a toolbar height for the
cell address and formula bar in Calc, use
`android:layout_height="wrap_content"`, so the height
is determined based on the font size.
This avoids the text getting cut off when a large
font size has been selected in Android's accessibility
settings.
Change-Id: I9bfbe2b7a1db39ac11d9ed0ab15290f974782489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159809
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Just as
commit 2105f638fa
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Nov 17 09:11:42 2023 +0100
android: Update app icon to new startcenter icon
updated the main icon for the Android app, also update the
MIME type icons that are shown in the "Recent files" section
in LibreOfficeUIActivity to the new ones meant to be used
for Calc/Draw/Impress/Writer since 7.5.
Change-Id: I1d969a290caa3c23589e78151cd5bf70144c3099
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159568
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of duplicating the icon as drawable,
just use the one from the mipmap folder that's
used for the app launcher.
Change-Id: Idd6691c4639fb570357280cec63636d07fe06b20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159553
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop the "More Info" button from the dialog, which
opened a sample document with more information
about LibreOffice.
There's already a link to the website, and the
"neutral" button in that dialog will be reintroduced
to show the privacy policy instead, if set.
(An `AlertDialog` has at most 3 buttons.)
Change-Id: Ib760daba1ed6f8cfc26eefc7412553bf97c77d70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159444
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That member was never assigned a value but only read
from by code claiming to be "used by robocop for testing purposes".
[1] describes Robocop as a UI-level testing framework for Firefox
for Android, which we don't use, so drop the class member and
related test code.
[1] https://wiki.mozilla.org/Auto-tools/Projects/Robocop
Change-Id: I467296874d4295060cc9670d1f1c8b0dfeb77523
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159198
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As the `eglChooseConfig` doc [1] says:
> eglChooseConfig returns in configs a list of all EGL frame buffer
> configurations that match the attributes specified
> [...]
> Attributes are matched in an attribute-specific manner. Some of the
> attributes, such as EGL_LEVEL, must match the specified value exactly.
> Others, such as, EGL_RED_SIZE must meet or exceed the specified minimum
> values.
The config/attribute list used for Android Viewer specifies
EGL_RED_SIZE=5, EGL_GREEN_SIZE=6, and EGL_BLUE_SIZE=5 and so
far, only configs using exactly those bit sizes were accepted,
causing 1 of the 11 devices used in automated tests in Google Play CI
crashing with this stack trace:
Exception org.mozilla.gecko.gfx.GLController$GLControllerException: No suitable EGL configuration found
at org.mozilla.gecko.gfx.GLController.chooseConfig (GLController.java:219)
at org.mozilla.gecko.gfx.GLController.initEGL (GLController.java:172)
at org.mozilla.gecko.gfx.GLController.initEGLContext (GLController.java:176)
at org.mozilla.gecko.gfx.GLController.initGLContext (GLController.java:57)
at org.mozilla.gecko.gfx.RenderControllerThread.doSurfaceCreated (RenderControllerThread.java:132)
at org.mozilla.gecko.gfx.RenderControllerThread.execute (RenderControllerThread.java:52)
at org.mozilla.gecko.gfx.RenderControllerThread.run (RenderControllerThread.java:30)
Since only configs fulfilling the minimium specification
have been returned, I don't see a reason to insist on
having one that uses exactly the specified amount of bits
for the individual color components.
I also didn't see any rendering issues in a quick test (also using
the colorful Calc sheet attachment 188343 from tdf#156182) forcing the
use of a configuration using EGL_RED_SIZE=8, EGL_GREEN_SIZE=8, and
EGL_BLUE_SIZE=8 with an x86_64 AVD and on a Fairphone 3+ (arm64)
using this temporary local change:
diff --git a/android/source/src/java/org/mozilla/gecko/gfx/GLController.java b/android/source/src/java/org/mozilla/gecko/gfx/GLController.java
index 45600e9f1e7c..9e7f348e9e72 100644
--- a/android/source/src/java/org/mozilla/gecko/gfx/GLController.java
+++ b/android/source/src/java/org/mozilla/gecko/gfx/GLController.java
@@ -171,7 +171,7 @@ public class GLController {
mEGL.eglGetConfigAttrib(mEGLDisplay, config, EGL10.EGL_RED_SIZE, red);
mEGL.eglGetConfigAttrib(mEGLDisplay, config, EGL10.EGL_GREEN_SIZE, green);
mEGL.eglGetConfigAttrib(mEGLDisplay, config, EGL10.EGL_BLUE_SIZE, blue);
- if (red[0] == 5 && green[0] == 6 && blue[0] == 5) {
+ if (red[0] == 8 && green[0] == 8 && blue[0] == 8) {
return config;
}
}
Therefore, fall back to using another config that fulfils the
specification.
(Leave the previously required config as preferred one for now,
maybe it still has advantages, e.g. might be more efficient due
to not wasting extra bits for the color components that are
not needed for the rendering in LibreOffice Viewer. (?))
[1] https://registry.khronos.org/EGL/sdk/docs/man/html/eglChooseConfig.xhtml
Change-Id: I953d292248004bc6f7e9384ceef78c8a88c21e9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159204
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
