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>
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>
According to [1], libandroid_support is no longer needed
for API level >= 21. Quoting from the issue:
> Dropping KitKat will have greater benefits than the other API levels
> we've dropped support for over the years (and while not the only reason,
> one motivation for the prior support removals was getting us
> closer to being able to drop 19/20):
>
> 1. libandroid_support will no longer be needed.
> i. libandroid_support
> adds to the APK size for all apps. Even if your minSdkVersion is
> 21+, libc++ is built for the lowest API level supported by the NDK,
> so it includes some pieces of libandroid_support.
> [...]
The LO Android build no longer supports API versions < 21
since:
commit c2fc2c8c7c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Dec 5 09:57:22 2023 +0100
android: Bump minSdkVersion to 21 (Android 5.0)
The linker flag was otherwise now causing linker errors in an NDK 28
build in a WIP branch including a fix for tdf#162769, using
--with-distro=LibreOfficeAndroidX86`
--with-android-sdk=/home/michi/Android/Sdk
--with-android-ndk=/home/michi/Android/Sdk/ndk/28.0.13004108/
Error:
Linking /home/michi/development/git/libreoffice-WORKTREE-android/android/obj/local/x86/liblo-native-code.so
ld.lld: error: unable to find library -landroid_support
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
The linker flag had already been dropped earlier in
commit a7f6338875
Author: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Date: Wed Aug 7 12:06:25 2019 +0200
android: support NDK 19 and above (20 as of this commit)
but was restored in
commit f68a36b62e
Date: Fri Oct 25 07:42:30 2019 +0200
android: Fix problems with unwinding in the Online-based Android app.
This partially reverts a7f6338875. The
problem is that with that approach, the problems with unwinding as
described in 312eeeee42 were plaguing the
Online-based Android app, leading to mysterious crashes with stack
traces like:
#00 pc 0005f2b6 /apex/com.android.runtime/lib/bionic/libc.so (abort+166) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#01 pc 05caaae7 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
...
#06 pc 07452e43 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
#07 pc 0005a37c /apex/com.android.runtime/lib/bionic/libc.so (__restore_rt) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#08 pc 0005f2b2 /apex/com.android.runtime/lib/bionic/libc.so (abort+162) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#09 pc 07565d3b /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
...
#11 pc 07565641 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
#12 pc 0001e394 /apex/com.android.runtime/lib/bionic/libm.so (__gnu_Unwind_RaiseException+108) (BuildId: 0ee3a75927e0da4fa0fe29469ccf8b39)
#13 pc 0001eee8 /apex/com.android.runtime/lib/bionic/libm.so (_Unwind_RaiseException+20) (BuildId: 0ee3a75927e0da4fa0fe29469ccf8b39)
Hopefully whatever was the problem back then is not
retriggered by dropping `-landroid_support` again
these days.
[1] https://github.com/android/ndk/issues/1751
Change-Id: Icd45abee58e13a2fc77d78d12e823a8045272b4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181898
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Port from deprecated Gradle API that is planned to
be removed in Gradle 9.0, as was warned about in the
build output previously:
> Configure project :
Script '/home/michi/development/git/libreoffice-WORKTREE-android/android/source/liboSettings.gradle': line 22
The org.gradle.api.plugins.BasePluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.7/userguide/upgrading_version_8.html#base_convention_deprecation
at liboSettings_bbauwf0uak693a4tmdwwty192$_run_closure3.doCall$original(/home/michi/development/git/libreoffice-WORKTREE-android/android/source/liboSettings.gradle:22)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
at liboSettings_bbauwf0uak693a4tmdwwty192.run(/home/michi/development/git/libreoffice-WORKTREE-android/android/source/liboSettings.gradle:20)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
Script '/home/michi/development/git/libreoffice-WORKTREE-android/android/source/liboSettings.gradle': line 22
The BasePluginExtension.archivesBaseName property has been deprecated. This is scheduled to be removed in Gradle 9.0. Please use the archivesName property instead. For more information, please refer to https://docs.gradle.org/8.7/dsl/org.gradle.api.plugins.BasePluginExtension.html#org.gradle.api.plugins.BasePluginExtension:archivesName in the Gradle documentation.
at liboSettings_bbauwf0uak693a4tmdwwty192$_run_closure3.doCall$original(/home/michi/development/git/libreoffice-WORKTREE-android/android/source/liboSettings.gradle:22)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
As described in the upgrading guide [1], use the "base"
configuration block in build.gradle instead.
[1] https://docs.gradle.org/8.7/userguide/upgrading_version_8.html#base_convention_deprecation
Change-Id: I358569a72b508efd31d2872d5009ac4f060398d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170610
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Addresses this warning shown in Android Studio:
> Do not use assignment with the minSdkVersion property (remove the '=')
Change-Id: I2d9e7037f7fb6e4d1625a8625a1b3820fb6e205f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170607
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Set the `android.ndkVersion` property [1] for
the Android Gradle Plugin, in addition to `android.ndkPath`
that is set there already.
This addresses the warning
> Task :stripStrippedUIEditingDebugDebugSymbols
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
[CXX1100] android.ndkVersion is [26.1.10909125] but android.ndkPath /home/michi/Android/Sdk/ndk/25.1.8937393 refers to a different version [25.1.8937393].
Unable to strip the following libraries, packaging them as they are: libc++_shared.so, libfreebl3.so, liblo-native-code.so, libnspr4.so, libnss3.so, libnssckbi.so, libnssdbm3.so, libnssutil3.so, libplc4.so, libplds4.so, libsmime3.so, libsoftokn3.so, libsqlite3.so, libssl3.so.
that started to show up in a local
`--with-android-ndk=$HOME/Android/Sdk/ndk/25.1.8937393`
Android build after
commit 1610ebc06b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon May 13 10:47:49 2024 +0200
android: Update Android Gradle Plugin to 8.4.0
... and gradle to 8.6, as suggested by Android Studio.
As described at [2], that Android Gradle Plugin defaults to
NDK 26.1.10909125.
[1] https://developer.android.com/studio/projects/install-ndk#apply-specific-version
[2] https://developer.android.com/build/releases/gradle-plugin
Change-Id: Ied81f13f535303f9578177646f177b4ef791eefa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167715
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, the build ID in liboSettings.gradle, and
therefore in the about dialog in Android Viewer
was not reliably updated in incremental builds.
For example, after a full build, then
git commit --allow-empty -m "Dummy"
make
, the build ID would still refer to the commit
from the full build, not the new dummy commit.
Since `instdir/program/versionrc` on Linux
and `instdir/program/version.ini` on Windows
gets updated properly, add an optional make
dependency on these files, using a wildcard.
Change-Id: If3b1d4d811a5e4316a26bb17f246b66858dcf80f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160157
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>
After
commit f9b9e70246
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Nov 15 13:26:38 2023 +0100
android: Add button to open privacy URL
, Android Jenkins builds started to fail intermittently
(e.g. [1]) like this:
> Task :stripStrippedUIEditingDebugDebugSymbols
> Task :compileStrippedUIEditingDebugJavaWithJavac FAILED
/home/tdf/lode/jenkins/workspace/android_x86/android/source/src/java/org/libreoffice/AboutDialogFragment.java:93: error: cannot find symbol
final String privacyUrl = BuildConfig.PRIVACY_POLICY_URL;
^
symbol: variable PRIVACY_POLICY_URL
location: class BuildConfig
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
FAILURE: Build failed with an exception.
This seems due to the pre-existing issue of a missing
dependency of the `liboSettings.gradle` target on
`android/Bootstrap/Makefile.shared`, so a change
to the latter would not have caused the former
to be regenerated and any old one still around
that didn't set the new build config variable
would get used, resulting in the above error.
Issue reproducible locally:
* do a local Android master build
* `git revert f9b9e702465b4de29153b49e077c70a0ad78c89d`
* `rm android/source/liboSettings.gradle`
* `make`
* `git cherry-pick f9b9e702465b4de29153b49e077c70a0ad78c89d`
* `make`
[1] https://ci.libreoffice.org/job/gerrit_android_x86/33773/console
Change-Id: I87275fc71d93f460dfad4d75fc197b8ed8cd9922
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159497
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>
While e.g. NDK 23.0.7599858 has both,
`$HOME/Android/Sdk/ndk/23.0.7599858/sources/cxx-stl/llvm-libc++/libs/x86/libc++_shared.so`
and
`$HOME/Android/Sdk/ndk/23.0.7599858/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/i686-linux-android/libc++_shared.so`
(with the same content), NDK 25.1.8937393 no longer
ships that under the former path scheme, just the latter.
Therefore, use that one when copying the library,
in preparation to add support for NDK 24 and 25.
Change-Id: I20894701f4f436f41781467b57ec4f5311a8317f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146133
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When an Android API level is explicitly set with the
`--with-android-api-level` switch introduced in
commit 4c0bccbb21
Date: Thu Jul 4 09:06:49 2019 +0200
android: Allow specification of the API level.
, use that for the minSdkVersion for the Android Viewer app
and the API level for the NSS build, rather than leaving
that hard-coded at API level 16.
Building with a newer API level means that the
app won't run on devices with older API levels.
With this in place, this will be recognized at
install time (installation will fail: INSTALL_FAILED_OLDER_SDK)
rather than crashing at run time.
Change-Id: Id6047b768d265b965696f3a3161d7828e5f3696e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146127
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Using lld instead of hard-coding ld.gold speeds up
linking liblo-native-code.so from about 40 seconds
to about 10 seconds for my x86 debug Android build with
NDK 23.2.8568313.
lld was added in NDK 21, made default in NDK 22 [1].
lld doesn't know the `--no-keep-files-mapped` option,
so drop that as well.
ld.gold had previously been hard-coded in
commit c6dadf5035
Date: Fri Nov 1 17:57:17 2019 +0100
android: Fix linking of liblo-native-code.so on aarch64.
, but lld wasn't available yet back then.
To make sure that lld is used by default, NDK >= 22
has to be used.
In addition, due to a clang bug in NDK 22.1.7171670 [2]
("Misspelled -fnostack-clash-protection"), building for
aarch64 Android with that NDK version would fail as follows:
clang++: error: unknown argument '-fno-stack-clash-protection'; did you mean '-fnostack-clash-protection'?
clang++ version:
$ /home/michael.weghorn/Android/Sdk/ndk/22.1.7171670//toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --version
Android (7155654, based on r399163b1) clang version 11.0.5 (https://android.googlesource.com/toolchain/llvm-project 87f1315dfbea7c137aa2e6d362dbb457e388158d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/michael.weghorn/Android/Sdk/ndk/22.1.7171670//toolchains/llvm/prebuilt/linux-x86_64/bin
Rather than work around that bug on LO side, require
NDK 23.x right away, since that provides a clang where this is
fixed.
Both, non-debug as well as `--enable-dbgutil` builds
with NDK version 23.2.8568313 were successfully tested
for all 4 supported architectures and these devices:
* aarch64: Fairphone 3 Plus, LineageOS 19 (Android 12), API 31
* arm32: Samsung Galaxy S4 I9505, LineageOS 17.1 (Android 10), API 29
* x86:
* AVD: Nexus 4, API 16
* AVD: Pixel 2, API 30
* x86_64: AVD: Pixel 2, API 33
[1] https://developer.android.com/ndk/downloads/revision_history
[2] https://bugs.llvm.org/show_bug.cgi?id=47139
Change-Id: I9ea714255faf29d50bb5f8e206f13495637da867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146119
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Quoting from
commit 128de1949f
Date: Tue Apr 19 15:18:49 2022 +0200
android: Use property instead of ANDROID_NDK_HOME env var
which ported from an obsolete (no longer supported by
current Gradle versions) way of setting the NDK path to a
deprecated but still supported one as an intermediate step
to allow upgrading Gradle:
> Note however, that with this approach of using the `ndk.dir`
> property instead of the suggested `android.ndkVersion`
> (with the latter having the stricter requirement that
> the `ndk` dir would have to be a subdir of the SDK dir),
> doing the actual upgrade to a newer Gradle (plugin) version
> in follow-up commit
> Change-Id Ia982d72d877e229c3006c6d528b830d16c88481f
> "android: Update Android Gradle Plugin to 7.1.3"
> revealed that the use of the `ndk.dir` property
> is deprecated in newer Gradle (plugin) versions as well,
> resulting in this warning.
>
> > > Task :stripStrippedUIDebugDebugSymbols
> > [CXX5106] NDK was located by using ndk.dir property. This method is
> > deprecated and will be removed in a future release. Please delete
> > ndk.dir from local.properties and set android.ndkVersion to
> > [20.0.5594570] in all native modules in the project.
> > https://developer.android.com/r/studio-ui/ndk-dir
>
> It might make sense to address that in a follow-up step,
> but for now, it's an improvement and keeps it working
> after the upgrade without potentially causing any incompatibility
> problems with existing autogen configurations,
> while support for the `ANDROID_NDK_HOME` env var that was
> used so far seems to have been dropped, [...].
The release notes for Android Gradle Plugin version 4.1.0
mention yet another way of setting an explicit NDK path
instead of just a version and that one is still supported
and not deprecated [1]:
> # Set the NDK path
> You can set the path to your local NDK installation using the
> android.ndkPath property in your module's build.gradle file.
>
> android {
> ndkPath "your-custom-ndk-path"
> }
>
> If you use this property together with the android.ndkVersion property,
> then this path must contain an NDK version that matches
> android.ndkVersion.
Therefore, switch to setting the NDK path using the `android.ndkPath`
property in liboSettings.gradle instead of the deprecated `ndk.dir`
in local.properties.
[1] https://developer.android.com/studio/releases/gradle-plugin?buildsystem=ndk-build#ndk-path
Change-Id: I34690ca8e15ff4742bab9a716a58b9ad85fa86e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133197
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Setting the archive base name in build.gradle using
project.ext.set("archivesBaseName", "LibreOfficeViewer")
no longer worked after
commit 39326bc7d4
Date: Tue Apr 19 15:49:53 2022 +0200
android: Update Android Gradle Plugin to 7.1.3
... and gradle to 7.2, which is what Android Studio suggested
and did automatically when confirming.
As a consequence, the generated .apk or .aar files
would no longer have the app name in them, but be
called e.g. "source-strippedUIEditing-release-unsigned.apk"
instead of
"LibreOfficeViewer-strippedUIEditing-release-unsigned.apk".
Setting `archivesBaseName` in `android.defaultConfig`
in libOSettings.gradle works, so move it there.
Change-Id: Id03cbe10681aca85c35aeef64527bc7707c95736
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133191
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Otherwise, upgrading to Android Gradle Plugin 7.1.3 and
gradle 7.2 (which will be done in a follow-up commit)
would make the build fail like this:
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file '/home/michi/development/git/libreoffice-WORKTREE-for-android-x86/android/source/build.gradle' line: 1
>
> * What went wrong:
> A problem occurred evaluating root project 'source'.
> > Failed to apply plugin 'com.android.internal.application'.
> > ANDROID_SDK_HOME is set to the root of your SDK: /home/michi/Android/Sdk
> ANDROID_SDK_HOME was meant to be the parent path of the preference folder expected by the Android tools.
> It is now deprecated.
>
> To set a custom preference folder location, use ANDROID_USER_HOME.
>
> It should NOT be set to the same directory as the root of your SDK.
> To set a custom SDK location, use ANDROID_HOME.
We don't actually rely on `ANDROID_SDK_HOME` being evaluated
by the Android toolchain, but it used to be set in configure.ac,
and the value was then assigned to the `sdk.dir` property written to
`android/source/local.properties`.
Just use a new variable name `ANDROID_SDK_DIR`
and keep the mechanism otherwise unchanged for now.
Change-Id: I44826621a1342119d40036fb704d8ff1eeed7c77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133178
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Write an `ndk.dir` property with the directory path to
`android/source/local.properties` instead, similar
to how it's done for `sdk.dir`.
Also, rename the `ANDROID_NDK_HOME` variable that's
assigned in configure.ac that holds the corresponding
value to `ANDROID_NDK_DIR`, because the gradle warning
still shows up if that environment variable is set in
addition to having an `ndk.dir` property in `local.properties`.
This makes the following gradle warning disappear:
> > Task :stripStrippedUIDebugDebugSymbols
> WARNING: Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead.
> Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead.
Note however, that with this approach of using the `ndk.dir`
property instead of the suggested `android.ndkVersion`
(with the latter having the stricter requirement that
the `ndk` dir would have to be a subdir of the SDK dir),
doing the actual upgrade to a newer Gradle (plugin) version
in follow-up commit
Change-Id Ia982d72d877e229c3006c6d528b830d16c88481f
"android: Update Android Gradle Plugin to 7.1.3"
revealed that the use of the `ndk.dir` property
is deprecated in newer Gradle (plugin) versions as well,
resulting in this warning.
> > Task :stripStrippedUIDebugDebugSymbols
> [CXX5106] NDK was located by using ndk.dir property. This method is
> deprecated and will be removed in a future release. Please delete
> ndk.dir from local.properties and set android.ndkVersion to
> [20.0.5594570] in all native modules in the project.
> https://developer.android.com/r/studio-ui/ndk-dir
It might make sense to address that in a follow-up step,
but for now, it's an improvement and keeps it working
after the upgrade without potentially causing any incompatibility
problems with existing autogen configurations,
while support for the `ANDROID_NDK_HOME` env var that was
used so far seems to have been dropped, resulting in
> > Task :stripStrippedUIDebugDebugSymbols
> Unable to strip the following libraries, packaging them as they are:
> libc++_shared.so, libfreebl3.so, liblo-native-code.so, libnspr4.so,
> libnss3.so, libnssckbi.so, libnssdbm3.so, libnssutil3.so,
> libplc4.so, libplds4.so, libsmime3.so, libsoftokn3.so,
> libsqlite3.so, libssl3.so.
instead if upgrading gradle without switching to the use of the property.
Change-Id: I4a090e8736dac80777f69b0e12819b9c056f582b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133177
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
...similar to how this is done for the other $(SODEST)/... targets above (and
which has presumably been missing accidentally from
eb050ae015 "tdf#123290 fix android tinderbox
builds/properly package libc++_shared.so".
Saw <https://ci.libreoffice.org/job/gerrit_android_x86/830/> fail once with
> cp: cannot create regular file ‘/home/tdf/lode/jenkins/workspace/android_x86/android/jniLibs/x86/libc++_shared.so’: No such file or directory
> ../Bootstrap/Makefile.shared:75: recipe for target '/home/tdf/lode/jenkins/workspace/android_x86/android/jniLibs/x86/libc++_shared.so' failed
> make[2]: *** [/home/tdf/lode/jenkins/workspace/android_x86/android/jniLibs/x86/libc++_shared.so] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /home/tdf/lode/jenkins/workspace/android_x86/android/CustomTarget_lo_android.mk:17: recipe for target '/home/tdf/lode/jenkins/workspace/android_x86/workdir/CustomTarget/android/source/done' failed
> make[1]: *** [/home/tdf/lode/jenkins/workspace/android_x86/workdir/CustomTarget/android/source/done] Error 2
Change-Id: Ief6b6274ad789d441c2692b941ba0aa8df276e40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106119
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
commit 0dffc65236
Date: Fri Jun 5 08:59:26 2020 -0400
android: fix the build output directory
submitted on 2020-07-07 had changed the output directory
for native libraries, so the directory used by
Android Viewer was empty, and native libs no longer
contained in the package/APK.
Store the actual/new directory in a variable and
use that one in build.gradle to make things work
again.
Change-Id: I5a051342278ab14e71edf47dd93e8dacdb9f3cb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98970
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is similar to commit c6dadf5035
("commit android: Fix linking of liblo-native-code.so on aarch64.").
Build previously failed with
Linking obj/local/x86_64/liblo-native-code.so
.../x86_64-linux-android/bin/ld.gold: error: cannot find -landroid_support
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../Bootstrap/Makefile.shared:62: obj/local/x86_64/liblo-native-code.so] Error 1
make[1]: *** [.../android/CustomTarget_lo_android.mk:18: .../workdir/CustomTarget/android/source/done] Error 2
make: *** [Makefile:282: build] Error 2
I quickly checked that the app actually runs on an x86_64 AVD
and is able to open and display documents after successfully
building with this commit in place.
Change-Id: I92b3759af6a86a6717c287d035b6a1add3a9af7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85204
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Forces gold as the linker; but according to the switches that were used,
I suppose gold was used previously anyway, so hopefully not really a
problem.
Change-Id: I7bc54abf0d3b4b3d86d53e4ea6f01146cf196216
Reviewed-on: https://gerrit.libreoffice.org/81905
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit fa145a035fbab652ec8f3ee870e44e43dd1d770a)
Reviewed-on: https://gerrit.libreoffice.org/81915
While it might not be the original problem, at least that is the current
problem the tinderbox provided builds have and should make it work again
Change-Id: Ifaedb3304622286cfe7a6cb49e862a359b53f892
This partially reverts a7f6338875. The
problem is that with that approach, the problems with unwinding as
described in 312eeeee42 were plaguing the
Online-based Android app, leading to mysterious crashes with stack
traces like:
#00 pc 0005f2b6 /apex/com.android.runtime/lib/bionic/libc.so (abort+166) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#01 pc 05caaae7 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
...
#06 pc 07452e43 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
#07 pc 0005a37c /apex/com.android.runtime/lib/bionic/libc.so (__restore_rt) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#08 pc 0005f2b2 /apex/com.android.runtime/lib/bionic/libc.so (abort+162) (BuildId: 68c87e04526a60689ecb5deb329804a0)
#09 pc 07565d3b /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
...
#11 pc 07565641 /data/app/libreoffice.debug-fBEOIUwPHY3_k3eQid159Q==/lib/arm/liblo-native-code.so (BuildId: 1c3d0e6336ddfc3578e1c186944160252a750b8b)
#12 pc 0001e394 /apex/com.android.runtime/lib/bionic/libm.so (__gnu_Unwind_RaiseException+108) (BuildId: 0ee3a75927e0da4fa0fe29469ccf8b39)
#13 pc 0001eee8 /apex/com.android.runtime/lib/bionic/libm.so (_Unwind_RaiseException+20) (BuildId: 0ee3a75927e0da4fa0fe29469ccf8b39)
Change-Id: Ie4e7b20380c9104770229a8d30036ad76093283d
Reviewed-on: https://gerrit.libreoffice.org/81485
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
support for targeting API 14 and 15 was removed in NDK 18, so set
minimum version to 16
mips support was removed in NDK 17
Clang now takes care about correct linking with libc++ shared or
static, so don't manually specify them anymore.
Same with __ANDROID_API_LEVEL__ define and the sysroot / isystem
handling, that is all covered by a single -target <triple><version>
simplifying things quite a bit.
also align ownloud sdk values with main build.gradle
Change-Id: Ib3ae4484e52214677e826270b731ecf7c5c15445
Reviewed-on: https://gerrit.libreoffice.org/77104
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Useful when you switch sdk to a different location.
Change-Id: I95301cc9adf50a0bbd918cc7562b8871093625b8
Reviewed-on: https://gerrit.libreoffice.org/67873
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
It had been left out in 4082a18406 "android: use
unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately
crashes with llvm-c++, so keep with gnustl for now/fix that later".
Making armeabi-v7a work with libc++ etc. required a number of changes, listed
below, in this commit and in preceding ones. At least 32-bit x86 already worked
with libc++ etc. prior to these changes in view mode, though it crashed in the
experimental editing mode (enabled with strippedUIEditing in
android/soruce/Makefile) as soon as one types in something, But it is not
entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I
saw armeabi-v7a fail. (On 32-bit x86, these changes appear to neither improve
nor worsen the current state, view mode still appears to work fine while editing
still crashes upon typing anything. With these changes, editing mode on
armeabi-v7a appears to work fine. But I tested armeabi-v7a only with a real
device and 32-bit x86 only with an emulator, in case that might make a
difference.)
* Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more
sensible place on the linker command line" plus this change's addition of
-lunwind to the liblo-native-code.so linker command line make sure that
liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of
erroneously picking up the ones from libgcc.a that happen to be included in
NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command
line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in
NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C
library, uses _Unwind_* functions, nor why exception handling in
liblo-native-code.so fails when using _Unwind_* functions from libgcc.a
instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit
x86, but that's what I observed: ModuleManager::identify
(framework/source/services/modulemanager.cxx) throws a
css::lang::IllegalArgumentException, which calls __cxa_throw ->
_Unwind_RaiseException, which ultimately lead to odd misbehavior and
std::abort during stack unwinding when using _Unwind_RaiseException from
libgcc.a instead of from libunwind). (There is no libunwind.* in
android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_*
functions from libgcc.a. It doesn't appear to make a difference if it
indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly
from libgcc.a included in liblo-native-code.so if the
$(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind)
had a ",-lgcc" else branch.)
* Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols
from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions
thrown from the binary UNO bridge can be caught by compiled catch clauses.
Not sure why the corresponding state of
bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same
issue.
* Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm
__cxa_exception to NDK 18 libc++abi" makes sure that our version of
__cxa_exception matches the version from libc++abi. This is clearly not
relevant for 32-bit x86. (The comment there android-ndk-r18b, but the
additional member is already present in
android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.)
The remainder of this change just drops old armeabi-v7a--specific workarounds
that are no longer needed/no longer work.
Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3
Reviewed-on: https://gerrit.libreoffice.org/64973
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
511ae02c64 "Android: Enable HAVE_FEATURE_NSS and
package the NSS libraries with apk" had added them to WHOLELIBS probably just
because that already had the $(addprefix -l,...), even though --whole-archive
doesn't make any sense for shared libraries. Better place them later on the
linker command line (after all our own archives and compiler support libraries),
so that switching armeabi-v7a to libc++/libc++abi/libunwind (coming soon) will
be able to override erroneously picking _Unwind_* symbols from NSSLIBS's nspr4
instead of libunwind.
Change-Id: Ie0c0b7a55da3eabe1bb427232d698b2a4af63e78
Reviewed-on: https://gerrit.libreoffice.org/64964
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79
Reviewed-on: https://gerrit.libreoffice.org/45163
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
packing gdbserver into apk conflicts with extractNativeLibs="false", as
the gradle pugin compresses it (which could be disabled using
aaptOptions), but furthermore it doesn't page-align it, breaking
installation.
So instead let the user manually push the gdbserver tool to device and
remove the hardcoded values that were only there to please the ndk-gdb
scripts.
Using lldb from within Android Studio is more comfortable anyway :-)
Change-Id: I31c3af4847a479c56b3fcd6b5bed114e004bf0d2
Reviewed-on: https://gerrit.libreoffice.org/41950
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This commit enables HAVE_FEATURE_NSS for Android and fixes the svl/ vcl/
and xmlsecurity/ module to use NSS.
xmlsecurity/ wasn't built for Android previously, this commit enables
building xmlsecurity/ for Android and disables the support of gpgme
in the same module(Only for Android).
It also enables the linking of NSS shared libraries with
liblo-native-code.so and adds a rule to package them along with the apk.
Change-Id: I7d0341688ac979ae92e9145c37dd107670417fe1
Reviewed-on: https://gerrit.libreoffice.org/41308
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
and of course also for the Java part
Using build-id linker flag allows lldb to map the installed .so to the
non-stripped version on the buildhost.
Also ndk-gdb supports specifying a different package name on the
commandline, so no need for the error in configure anymore.
Change-Id: If6887a27cc8ab15ee6ab612502cacf0a22ade737
move preparation tasks (creating assets/processing files) from the
makefile into the gradle script
This allows much easier integration into android-studio (just open
android/source with android studio after running make to compile the
native library)
Change-Id: I9a9d6832797c24a7e195a1c7954cd6d20f5a8496
replace with corresponding Math functions and bump android sdk target to
23 to be able to use current appcompat-v7
pre-JIT FloatMath was faster, but since then was wrapper to Math anyway
http://developer.android.com/reference/android/util/FloatMath.html
Change-Id: I19e316fb7d32e616162a70fca8c565fa320a8c1a
Has all been obsoleted by LibreOfficeKit.
Only some MOBILE_* constant #defines are now left in touch.h, but probably
those are used only by dead code.
Change-Id: I646945c4408b4e6cd5510da535cfc12088dd391c
Also, if we are at it:
- clean up 'run' as well: since the doc browser is the default activity,
no need to pass the test doc path anymore
- make 'install' not depend on build: a full build would need a toplevel
'make' anyway
Change-Id: Ia55d52f767ab3e0be02a753a95b2aac02f8491cc
Previously we included the android support library v4 for some
GUI elements like GridView. This commit in addition adds the v7
appcompat library which is needed for the new Lollipop style
Toolbar and many other new GUI elements.
The appcompat v7 library is not distributed as only a jar file
but needs to be build (as it includes additional resources) and
included as a library project. So to do this the content is copied
from SDK and build with the build system. The files also include
the v4 so it doesn't need to be copied from SDK anymore.
The target had to be raised to v21 (Lollipop), however the minimum
SDK version remains unchanged.
Change-Id: I4f1a6ce69e7f6c3f9df784a6835f376a01d4dfdb
Ivan Vladimirovich Kuznetsov