When building on debian 12, we were using Java 17.
On debian 13, Java 17 is not packaged anymore, instead there is Java 21 and 25.
Ideally we should upgrade to Java 21 and just install it from apt.
However old Gradle is not compatible with new Java, so we have to upgrade Gradle for that.
- see https://docs.gradle.org/current/userguide/compatibility.html
Old Gradle is giving build errors with Java 21:
```
Could not compile build file '/home/user/wspace/electrum/.buildozer_qml/android/platform/build-arm64-v8a/dists/Electrum/build.gradle'.
> startup failed:
General error during conversion: Unsupported class file major version 65
java.lang.IllegalArgumentException: Unsupported class file major version 65
```
for our p4a fork, I tried to cherry-pick stuff from upstream:
- 17bf532279
- https://github.com/kivy/python-for-android/pull/3172a8f2ca1c5b
- see a01269f779...846a109487
That seems sufficient to upgrade Gradle as far as p4a is concerned.
However that still did not work yet:
- contrib/android/make_barcode_scanner.sh fails, as
markusfisch/zxing-cpp and markusfisch/CameraView
are also using too old gradle versions for Java 21
- it seems they are intentionally doing this to maintain compat with Android 4:
see d98ed5d0be
So for now maybe the path of least resistance is to downgrade to Java 17 :(
Bump the python version used on Android from 3.10 to 3.11.
The substance is the backport of the corresponding commit [0] from upstream p4a.
Tested that apk is still reproducible by doing two full builds.
I also used the apk a bit and it seems to work at runtime. :)
[0]: 78db83223f (which got squashed into 83e74cac0f)
Extend "create new user to avoid using root" copypasta to support being run as root
(ARG UID=0).
When running build.sh directly on a cirrus CI runner, we are running as root.
p4a ref: electrum_20240930_android_16kb_page_alignment
Dockerfile: obtain 16kb aligned NDK r23 from google CI (dl-ndk-ci.sh)
barcode, zxing-cpp: add 16kb align patch
build_tools_util.sh: add function to apply a patch
- fdroid maintainers asked that releases use fixed forks of p4a and buildozer,
so now we use the newly created forks in the spesmilo org. I plan to keep using
my existing contributor-specific repos for development, but whatever we push
to electrum master, should use the new spesmilo/ forks.
see https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15858#note_2136345746
- Also, I added branch protection rules for branches named "electrum_*", so if
we name the branches that are actually used in releases as such, we won't
accidentally force-push them. (ref https://github.com/spesmilo/electrum/issues/8162)
I think we can just create a new branch whenever we would want to force-push
the existing one.
- also factored out some parameters so that it is easier to programmatically
access them from the fdroid build script.
see https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15858#note_2136094409
Use our own logic to go from ELECTRUM_VERSION to numeric android versionCode,
instead of using the default conversion done by python-for-android.
Even before this, we were already patching p4a to modify their logic (see [0]).
This commit changes that logic again, and moves it into a separate script in our repo.
- calculation change is due to the f-droid maintainers asking for the
arch code to be in the least significant digits (instead of most sig digits) (see [1])
I have pushed and changed to a new p4a branch, which is just a copy of the previous one
with 3 commits related to versionCode calc squashed.
[0]: edb7e4fe6d
[1]: https://github.com/spesmilo/electrum/issues/9210#issuecomment-2380559324
Note that 0f541be6f1 added a warning log if asserts are disabled.
It is intentional that these two things are in separate files:
We always want to log that warning, even if someone is using electrum as a library.
However, in that latter case, I think it's fine not to sys.exit(), but leave the decision up to the library user.
Similar thinking when running from source: let's log the warning but don't sys.exit().
reproducibility probably needs a hardcoded userid
Also, move the UID arg later in the dockerfiles, for better caching.
(if local dev build and repro build set different UIDs, the build caches
will diverge at that step)
