android: the perils of upgrading Qt and rebasing p4a

[SomberNight]

We should rebase our fork of python-for-android. We are stuck on old versions of python (3.10) and openssl (1.1, already EOL). Relatedly, we should also update Qt (from 6.4). And the android NDK (from r23).

But everything is interwoven and tangled together.

Currently our p4a fork is based on the v2023.05.21 tag of upstream. Atm that's 2.5 years old. Though most of what we would want from p4a upstream has not been released yet - they haven't tagged a new release since v2024.01.21. I think that's not a serious problem -- we could just pick a recent commit.

Issues:

• we need to adapt the GUI to styling changes in newer Qt (already in 6.5)

  • we currently use Qt 6.4

• @accumulator says, in QML, assignment of custom property types has issues since Qt>=6.6

  • This would mean at least changing all types in the QML<->QObject boundary to a generic type.
  • see https://www.riverbankcomputing.com/pipermail/pyqt/2024-June/045922.html

    $ pip install --upgrade 'pyqt6==6.10.0' 'pyqt6-qt6==6.10.1'
    $ python3 ./assign-bug.py
    <Unknown File>:13:9: Unable to assign Simple to Simple
    

    $ pip install --upgrade 'pyqt6==6.5.3' 'pyqt6-qt6==6.5.3'
    $ python3 ./assign-bug.py
    // no issue
    

• Qt restricts the android NDK version:

  • Qt 6.4 -> NDK r23
    • https://doc.qt.io/archives/qt-6.4/android.html
  • Qt 6.5 -> NDK r25 or r26 or r27
    • https://doc.qt.io/qt-6.5/android.html
  • Qt 6.8 -> NDK r26 or r27
    • https://doc.qt.io/qt-6.8/android.html

• p4a restricts the NDK version:

  • current min of upstream is r25
  • by default they use r28c
  • so presumably upstream p4a supports at least the 25-28 range

• currently we are using an unreleased google canary build of NDK r23d-canary, as a hack to be able to compile with 16 KB page sizes (Google Play requirement)

  • see https://github.com/spesmilo/electrum/pull/10148
  • note that newer p4a satisfies the 16 KB page size requirement by simply using the MUCH newer NDK r28

• current upstream p4a supports

  • cpython 3.14
    • as opposed to our current 3.10
  • openssl 3.3
    • as opposed to our current 1.1.1w

• we are stuck on cryptography==2.8, as building newer versions requires Rust

  • upstream p4a seems to have a solution
    • though note that just because they have something that builds, it might not be reproducible (we would need to test that)
  • this old version of cryptography is not compatible with OpenSSL 3.0+
  • as workaround, we could switch to using pycryptodomex instead
    • for all our direct cryptography usage, it is almost a drop-in replacement
    • see https://github.com/spesmilo/electrum/pull/10332
    • however note that some hw-wallet libs require cryptography and @accumulator has some branches with experimental hww support on Android

---

I think what we should try to do is:

• step 1. upgrade Qt to 6.5

  • adapt our qml gui to the styling changes
  • upgrade the android NDK to r25
    • r25 is supported by both Qt 6.5 and our current p4a fork
    • there should be an unofficial google canary build of r25 that supports 16 kb page sizes, similar to our current hack for r23

• step 2. rebase our p4a fork on current upstream develop

  • upgrade the android NDK to r27
    • r27 is supported by both Qt 6.5 and p4a upstream
  • due to the rebase, inherit upgrade of python to 3.14 and openssl to 3.3

[accumulator]

Good overview.

I noticed that Qt tends to work with non-supported/near-supported versions of the NDK, however then the risk is obviously larger.

The diff for QML GUI will be huge, I would recommend continuing Electrum 6.5.x on a maintenance branch while porting to Qt6.5+ on (a branch of) master.

The Material styling changes happened mostly on Qt6.5. This version still works with the current NDK we use. We could 2-step the port, first move to Qt6.5 and adapt styling. Then move to recent P4A/NDK and port to current Qt6. The first step could likely be backported on Electrum 6.5.x

[hdatma]

openssl ought to have priority

[SomberNight]

openssl ought to have priority

I have a workaround for that: https://github.com/spesmilo/electrum/pull/10332

EDIT: I added another section to the OP about cryptography==2.8

EDIT2: somewhat off-topic, but note that the AppImage also uses an old openssl: https://github.com/spesmilo/electrum/blob/828fc569c95e8ddcfa12237bf8df44ff1a322fbb/contrib/build-linux/appimage/Dockerfile#L31