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)
We had been using an ancient version of "cryptography" so far in our p4a fork,
however it is not compatible with OpenSSL 3.0. (Previously we were building it with OpenSSL 1.1)
Bumping "cryptography" is difficult, as building new versions of it from source requires a full rust toolchain.
Instead, this commit switches to "pycryptodomex", as a replacement, which is much easier to build from source.
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.
from https://stackoverflow.com/a/69088164
I am trying to run the build.sh scripts directly on a cirrus CI runner, and "docker run -it" is erroring due to lack of a tty.
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
Adds a script `make_barcode_scanner.sh` which builds the
`BarcodeScannerView` library and its dependencies, `zxing-cpp` and
`CameraView` from source. Builds `zxing-cpp` architecture dependent
reducing the final apk size.
pins the barcode scanner aar used in the android build and its 2
dependencies to a sha256 hash using a script `fetch_barcode_scanner.sh`
which is called in the process of building the apk by `make_apk.sh`.
It fetches the 3 aar files if not already existing, puts them in
`/contrib/android/aars` and verifies their shasum against the hardcoded
hashes in `fetch_barcode_scanner.sh`.
Replaces the unmaintained and unreliable
`me.dm7.barcodescanner:zxing:1.9.8` qr code scanning library used only
on android with the `com.github.markusfisch:BarcodeScannerView:1.6.0`
(https://github.com/markusfisch/BarcodeScannerView) library which seems
more actively maintained.
The `BarcodeScannerView` library is incredibly fast and scanning qr
codes is now fun again :)
wip: still looking into ways to pin the library.
note: 3.12 just transitioned to security-only status,
so can't bump win/mac binaries without switching to 3.13
(as we don't compile our own cpython for those)
note: some files have two versions in them, e.g.:
```
assert CffiRecipe._version == "1.15.1"
class CffiRecipePinned(util.InheritedRecipeMixin, CffiRecipe):
version = "1.17.1"
```
The assert is left there as I think it might be useful to get a failure if we rebase p4a
and the upstream recipe version changes. There might be substantial changes in the upstream
recipe that we need to adapt to. In the happy case, if we rebase p4a, we just have to manually
update these asserts to the new versions at that time.
- this merges `contrib/deterministic-build/locale` and `electrum/locale`
- it is now once again possible have translations when running from a local git clone
- which was already possible in the past before crowdin removed their unauthenticated APIs
- see https://github.com/spesmilo/electrum/issues/9531
- however, the translations available are the often-old frozen strings from electrum-locale
- while previously one could just download the latest strings from crowdin
- 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
To comply with new google play store requirement:
> Starting August 31 2024:
> - New apps and app updates must target Android 14 (API level 34) or higher to be submitted to Google Play
AFAICS, we do not need to adapt to any of the changes.
https://developer.android.com/about/versions/14/behavior-changes-14
