p4a rebase, use ndk28 and qt6.10#10485
Conversation
|
|
accumulator
force-pushed
the
ndk28_qt610_rebase_p4a
branch
7 times, most recently
from
bb0914b to
3ed4382
Compare
|
hey, sorry for lack of feedback. It is most certainly not due to lack of interest! :) Did you close this just to make it clear we should not include it in 4.7.1 (which I agree with - and now 4.7.x is branched off, and a huge change like this I would not want to cherry-pick to 4.7.x), or is it for some other reason? |
|
oops, I don't recall closing this.. reopening |
Yes |
|
When running this as a debug apk on my Pixel 9 (Android 16) i noticed two issues: This The app crashes most of the time when starting it (like 4 out of 5 times), when cancelling the following Biometric authentication it crashes almost certainly. However when i manage to open it it runs reliably and doesn't crash anymore. Seems to be some kind of race during startup? I noticed the following log lines during these crashes: This is the Android crash report: |
Yes I see the same.
I haven't seen this at all. I'm also using debug apk on Pixel 9. I assume you fully cleaned the buildozer build tree first?
This is my log. It has some warnings and errors, but never crashes and seems to run fine: |
|
weird.
yes, i started in a clean repo with fresh container. Also i am using GrapheneOS, but had all optional exploit protections disabled, so this shouldn't be the reason. |
accumulator
force-pushed
the
ndk28_qt610_rebase_p4a
branch
4 times, most recently
from
7c24c22 to
3ebe8e5
Compare
|
The recent changes fixed the crash for me, 3ebe8e5 now works fine. |
p4a rebased on spesmilo/electrum_202602, 375a05de21b538d704174b1efeb3fc85d151f94e
…erties - on the python side, for pyqtProperty's with a setter, the pyqtProperty should be declared as QVariant type - on the qml side, properties should be declared 'var', not the custom type.
…t:support-compat:28.0.0
also allow stackview pages to override navigationbar background color to allow correct color runoff below buttons
… highlight (qml) and upscale qrcode-[_white].png for the same reason and so we don't need to apply scaling
accumulator
force-pushed
the
ndk28_qt610_rebase_p4a
branch
from
3ebe8e5 to
660f2ea
Compare
There was a problem hiding this comment.
None of my other comments are too important, but this one is a blocker.
We must hash pin everything we pull in.
( self-note: reviewed 660f2ea )
| assert PyjniusRecipe._version == "1.7.0" | ||
| assert PyjniusRecipe.depends == [('genericndkbuild', 'sdl2', 'sdl3', 'qt6'), 'six', 'python3'], PyjniusRecipe.depends |
There was a problem hiding this comment.
Something fishy is going on.
New pyjnius requires Cython 3.1.x [ref], but ISTM we only install Cython 0.29 [ref].
Ok, so I believe it is due to the recipe.hostpython_prerequisites introduced in kivy/python-for-android@8110faf.
Uhum... so this is due to this hostpython_prerequisites, installing
https://github.com/spesmilo/python-for-android/blob/ee6886ec3048670b182afb18237e0ae69fde1254/pythonforandroid/recipes/pyjnius/__init__.py#L14
https://github.com/spesmilo/python-for-android/blob/ee6886ec3048670b182afb18237e0ae69fde1254/pythonforandroid/recipes/android/__init__.py#L16
https://github.com/spesmilo/python-for-android/blob/ee6886ec3048670b182afb18237e0ae69fde1254/pythonforandroid/recipes/pyqt6/__init__.py#L18
Looks like all kinds of unpinned packages are getting installed at build-time willy-nilly.
Uhh this install_hostpython_prerequisites is a real can of worms. (esp with force_upgrade=True!)
So it is calling pip with internet and downloading packages without hash-pins from PyPI. Often without even version-pins. We can't have this... everything must be pinned.
Perhaps we should make sure that install_hostpython_prerequisites always gets called with a packages arg that contains hashes. We could patch the pip_options internal var to add --require-hashes, as a final sanity check.
Also, this recipe.hostpython_prerequisites should probably be something we assert/check in our contrib/android/p4a_recipes, similar to depends and python_depends. We really don't want any of these silently changing.
There was a problem hiding this comment.
Yes, hostpython package handling considerably changed in p4a upstream. Pinning will take some work.
There was a problem hiding this comment.
I've added support for hash pinning the
hostpython_prerequisites.
Nice. Thanks a lot!
The
hostpython_prerequisitesare not compiled but pulled binary from pypi.packagingis now not compiled but pulled in as binary instead. If we want to compile it instead this could take some work to accomplish
Ok, I think it's acceptable to pull in some pure-python .wheels from PyPI for a small number of popular packages. As long as everything is hash-pinned.
In general we should make sure everything is hash-pinned and instead of logging warnings or silently ignoring issues, we should add belt-and-suspender sanity-check hard-fails, make sure we don't just accidentally pull in the unpinned current latest of version of something.
pin android and pyjnius recipes Cython version
|
I've added support for hash pinning the
.. and it still sucks |
| class SetuptoolsRecipePinned(SetuptoolsRecipe): | ||
| sha512sum = "5a3572466a68c6f650111448ce3343f64c62044650bb8635edbff97e2bc7b216b8bbe3b4e3bccf34e6887f3bedc911b27ca5f9a515201cae49cf44fbacf03345" | ||
| hostpython_prerequisites = [ | ||
| HashPinnedDependency(package='setuptools==80.9.0', | ||
| hashes=[]), | ||
| ] |
There was a problem hiding this comment.
why is the hash of the host setuptools not pinned?
also, shouldn't PythonRecipe.install_hostpython_prerequisites raise an exception in this case?
I would have expected pip install --require-hashes to error out (?)
There was a problem hiding this comment.
It does not trigger because apparently it isn't used as a compiled dependency..
| # pin deptree build[virtualenv]==1.4.0 | ||
| HashPinnedDependency(package="packaging==26.0", | ||
| hashes=['sha256:b36f1fef9334a5588b4166f8bcd26a14e521f2b55e6b9de3aaa80d3ff7a37529']), | ||
| HashPinnedDependency(package="pyproject_hooks==1.2.0", | ||
| hashes=['sha256:9e5c6bfa8dcc30091c74b0cf803c81fdd29d94f01992a7707bc97babb1141913']), | ||
| HashPinnedDependency(package="virtualenv==21.2.0", | ||
| hashes=['sha256:1bd755b504931164a5a496d217c014d098426cddc79363ad66ac78125f9d908f']), | ||
| HashPinnedDependency(package="distlib==0.4.0", | ||
| hashes=['sha256:9659f7d87e46584a30b5780e43ac7a2143098441670ff0a49d5f9034c54a6c16']), | ||
| HashPinnedDependency(package="filelock==3.25.2", | ||
| hashes=['sha256:ca8afb0da15f229774c9ad1b455ed96e85a81373065fb10446672f64444ddf70']), | ||
| HashPinnedDependency(package="platformdirs==4.9.4", | ||
| hashes=['sha256:68a9a4619a666ea6439f2ff250c12a853cd1cbd5158d258bd824a7df6be2f868']), | ||
| HashPinnedDependency(package="python_discovery==1.1.3", | ||
| hashes=['sha256:90e795f0121bc84572e737c9aa9966311b9fde44ffb88a5953b3ec9b31c6945e']), | ||
| ] |
There was a problem hiding this comment.
packaging[...] is now pulled in as transitive dependency for thebuild[virtualenv]prerequisite forPyProjectReciperecipies. The entire dependency tree forPyProjectRecipeprereqs is hash pinned in thehostpython3recipe.
is virtualenv actually needed? can't we just use stdlib venv?
I see that upstream declared it there but what specifically is needed that venv is missing?
that would rid us of all these transitive deps
| assert PyjniusRecipe._version == "1.7.0" | ||
| assert PyjniusRecipe.depends == [('genericndkbuild', 'sdl2', 'sdl3', 'qt6'), 'six', 'python3'], PyjniusRecipe.depends |
There was a problem hiding this comment.
I've added support for hash pinning the
hostpython_prerequisites.
Nice. Thanks a lot!
The
hostpython_prerequisitesare not compiled but pulled binary from pypi.packagingis now not compiled but pulled in as binary instead. If we want to compile it instead this could take some work to accomplish
Ok, I think it's acceptable to pull in some pure-python .wheels from PyPI for a small number of popular packages. As long as everything is hash-pinned.
In general we should make sure everything is hash-pinned and instead of logging warnings or silently ignoring issues, we should add belt-and-suspender sanity-check hard-fails, make sure we don't just accidentally pull in the unpinned current latest of version of something.
…d[virtualenv]', remove setuptools as its use is now pinned via hostpython_prerequisites where applicable, update depends asserts in pyqt6sip, sip, pyqt_builder
accumulator
force-pushed
the
ndk28_qt610_rebase_p4a
branch
from
5a952dd to
ca5e374
Compare
3 participants
This updates P4A to a much more recent branch point (~2025-10), right before upstream moves to python3.14.
patches dropped:
cffirecipe for Python 3.10 (41fee3e938d13b6701b205da8c17d0d444188e63)patches added:
other changes:
-no-feature-getentropy, this feature requires API28 and has a fallback reading/dev/urandom. (Note: we don't use any cryptographic primitives from Qt, so this should not be potentially problematic)changes in QML GUI:
pyqtPropertyaccessors that also have a setter to passQVariantinstead of the actual type, to work around this PyQt issue.varinstead.QtMultimediaare removed. (QtMultimediais currently not needed on android, but is used for camera/scanning on desktop)