Sync upstream - #6
Merged
Merged
Conversation
Fixes software supply chain safety warnings like at the bottom right of https://github.com/kivy/python-for-android/actions/runs/11425651890 * [Keeping your actions up to date with Dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot) * [Configuration options for the dependabot.yml file - package-ecosystem](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#package-ecosystem)
Remove conditional build argument for Python version >= 11
Reconfigure Docker's data-root to use the LVM volume created by maximize-build-space, fixing recurring "no space left on device" CI failures. Reduce root-reserve-mb from 30 GB to 4 GB since Docker data no longer resides on root filesystem. The relocation step runs after checkout to avoid permission errors during workspace cleanup, and docker-data is excluded from .dockerignore to prevent it being sent as build context.
…ion-ci-fix 👷 Relocate Docker storage to LVM volume in CI
Auto-detect sdl3 bootstrap when any SDL3-related recipe (sdl3, sdl3_image, sdl3_mixer, sdl3_ttf) is in requirements, preventing conflict with hardcoded sdl2 bootstrap in the test app's setup.py. Also remove stale commented-out URL from sdl3_mixer recipe that incorrectly referenced SDL_ttf.
…rap-detection 🐛 Fix sdl2/sdl3 bootstrap conflict in CI
Ensure patches and configure arguments are unique.
* Fixed a bug with Python version selection and library loading. * Fixed Python version support. * Remove conditional build argument for Python version >= 11 * Increased the minimum python version to 3.8 * Ensure patches and configure arguments are unique.
Update README to include PySDL3 support, fixes kivy#3290
Add support for prebuilt wheels
* fix PYTHONPATH hacks * fix android recipe * fix numpy and matplotlib build * no shebang patching required now * fix kivy master build * fix numpy build * more wrappers for meson recipe * flake8 fix * add back pandas host preq * fix bug in logger * add back cython for pandas
Update SDL3_mixer recipe to version 3.2.0, remove libgme patch (not needed as SDL3_mixer disables it by default) and fix compilation crash
🐛 Fix Python module stripping root
Update version to 3.5.1
Use the target C++ compiler with -shared so setuptools does not inherit macOS bundle linker flags during Android cross-compilation. Add recipe environment coverage and a dormant on-device smoke test for loading the native extension and switching greenlets.
🐛 Fix greenlet shared linking
Bumps the github-actions group with 1 update: [actions/setup-java](https://github.com/actions/setup-java). Updates `actions/setup-java` from 5 to 6 - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@v5...v6) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
…ub-actions-31df092e2e Bump actions/setup-java from 5 to 6 in the github-actions group
Set LDCXXSHARED globally from the Android C++ compiler and shared linker flags so setuptools cannot inherit macOS bundle options. Remove the equivalent Greenlet, Kiwisolver, and Material You Color workarounds, and cover both compiler flag modes in architecture tests.
🐛 Fix C++ shared linker configuration, fixes kivy#3363
fix for freetypehost host
av: update version
* fix(ui): fix any keypress on keyboard triggered as back button * fix(ui): adjustResize to keyboard by default
…pplication> (kivy#3377) There's currently no way to add an arbitrary child element (like a <provider>, needed for e.g. a FileProvider) inside <application> in the generated AndroidManifest.xml: - --extra-manifest-xml writes at the <manifest> root, as a sibling of <application> -- a <provider> there is invalid, providers must be nested inside <application>. - --extra-manifest-application-arguments only splices into the <application ...> opening tag's attribute list, so it can't hold a full child element either. This is a real gap: a FileProvider (needed to hand another app, e.g. a camera app, a content:// Uri instead of a file:// one and avoid FileUriExposedException on API 24+) requires exactly this kind of <provider> entry, and there's currently no supported way to add one without patching the rendered manifest after the fact via a p4a.hook. Adds --extra-manifest-application-xml, rendered immediately before </application> in every bootstrap's manifest template, alongside the two existing options. Co-authored-by: Dennis <dennisyliang@gmail.com> Co-authored-by: Mathias Lindström <8863149+kuzeyron@users.noreply.github.com>
`patches` and `configure_args` are deduplicated with `list(set(...))`, whose order depends on PYTHONHASHSEED. The configure arguments end up in the shipped `_sysconfigdata` module (CONFIG_ARGS), so two otherwise identical builds can differ, and the patches are applied in a different order on every run. Use an order-preserving dedup instead to help with reproducible builds. Upstreamed from https://github.com/spesmilo/python-for-android Co-authored-by: Mathias Lindström <8863149+kuzeyron@users.noreply.github.com>
# Conflicts: # pythonforandroid/bootstraps/common/build/templates/gradle.tmpl.properties # pythonforandroid/recipe.py # pythonforandroid/recipes/numpy/__init__.py # pythonforandroid/recipes/vosk/__init__.py
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…g NDK layouts NDK r25b (and possibly other releases) ships the clang toolchain's lib/ directory as lib64/clang/<version>/lib/linux/<arch>/libomp.so rather than lib/clang/<version>/lib/linux/<arch>/libomp.so. The glob pattern only matched the latter, crashing build_arch with IndexError: list index out of range as soon as libthorvg is pulled in (now a direct dependency of the kivy recipe). Glob both layouts and raise a clear BuildInterruptingException instead of an opaque IndexError if neither matches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Upstream's v2.3.0 recipe dropped these from hostpython_prerequisites. MesonRecipe.build_arch only auto-installs meson/ninja, not the mesonpy PEP 517 backend numpy's own pyproject.toml declares as build-backend, so `pip wheel --no-build-isolation` failed with pip._vendor.pyproject_hooks._impl.BackendUnavailable: Cannot import 'mesonpy' as soon as no other previously-built recipe happened to have already installed meson-python into hostpython3's site-packages. Version constraints match numpy v2.3.0's own [build-system].requires. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…uild` Our `pip wheel --no-build-isolation` patch (cfc1bb3) worked around a real bug in `python -m build --no-isolation`'s build-system.requires check via importlib.metadata (blind to `pip --target` installs), but that bug is specific to *disabled* isolation. Upstream's current code never disables isolation at all -- it uses plain `python -m build --wheel`, which creates a real ephemeral venv and lets `build` auto-install `[build-system].requires` (Cython, meson-python, etc.) there via normal PEP 517/518 resolution. That's why upstream's numpy recipe never needed to declare `meson-python` in hostpython_prerequisites, while ours did after inheriting the no-isolation patch -- and why any other PyProjectRecipe/MesonRecipe recipe copied from upstream could hit the same class of bug. Confirmed hostpython3's native-build Python has working venv/pip (virtualenv 21.13.0, build 1.6.1 already present from prior attempts) and upstream's own PR history (kivy#3007, kivy#3301) shows they moved deliberately *toward* full isolation specifically to eliminate "a lot of hacks/setup from the user side (Incompatible Cython versions, etc.)" -- the exact class of problem we just hit twice. Reverted PyProjectRecipe.build_arch to upstream's exact `install_hostpython_prerequisites(["build[virtualenv]", "pip", "setuptools", "patchelf"] + ...)` + `python -m build --wheel` call, and restored numpy's recipe to upstream's version with no explicit hostpython_prerequisites, as a clean test of whether isolation alone now resolves the mesonpy import problem. To be validated by an actual build. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The full-isolation build (previous commit) got numpy meson-configuring and compiling correctly -- confirming that revert fixed the mesonpy problem -- but hit a real, separate numpy bug: src/multiarray/unique.cpp uses std::unordered_map without including <unordered_map>, relying on it being pulled in transitively via <unordered_set>. That happens to work with glibc's libstdc++ but not with NDK r25b's libc++ (clang 14), which fails with "no template named 'unordered_map'". Fixed upstream in numpy v2.3.3 (unique.cpp now includes <unordered_map> directly). Bump to the latest v2.3.x patch release (v2.3.5) to pick up that fix and 2 more patch releases of bugfixes. Also matches the numpy~=2.3.0 pin in Ambience-voice-assistant's pyproject.toml, which already resolves to 2.3.5 for the desktop venv. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cryptography-cffi's build.rs uses the `cc` crate to compile the
cffi-generated _openssl.c. We only set the per-target CARGO_TARGET_*_LINKER
for rustc/cargo itself, not a per-target C compiler for `cc`. Without
CC_<target>, `cc` falls back to the generic CC env var and additionally
appends its own guessed --target= from the Rust triple; for
armv7-linux-androideabi that guess comes out as the invalid
"armv7-none-linux-android" (no API level, wrong vendor component).
That breaks NDK sysroot/header selection, so _openssl.c ends up pulling
in a mismatched <limits.h> and fails CPython's pyport.h LONG_BIT sanity
check ("bad gcc/glibc config?").
Fix: give `cc` the same NDK per-target clang already computed for the
cargo linker via CC_<target>/AR_<target>, so it doesn't need to guess.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…on include dir Root cause of the LONG_BIT error (deeper than the CC_/AR_ fix in the previous commit, which was necessary but not sufficient): cryptography-cffi's build.rs asks the interpreter named by PYO3_PYTHON for its own setuptools build_ext include_dirs to find Python.h. When cross-compiling, PYO3_PYTHON points at hostpython3 (native x86_64), so this returns hostpython3's own native include dir -- not the Android target's. Since that -I is added first (before the correct target include dir that p4a's CFLAGS/INCLUDEPY already provide, which cc-rs appends later), the host's Python.h wins and its baked-in SIZEOF_LONG (for a 64-bit host) doesn't match the 32-bit ARM target's LONG_BIT, triggering CPython's pyport.h sanity check. android-cross-include-dir.patch teaches build.rs to prefer a P4A_PYTHON_INCLUDE_DIR env var over the python-introspection method when it's set; the recipe now sets it to the correct ctx.python_recipe.include_root(arch) (same value already used for INCLUDEPY elsewhere). Verified the patch applies cleanly against the real 46.0.3 release tarball. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
srt (PyPI) only ships an sdist, so p4a's --only-binary=:all: pure-Python install stage always fails on it, aborting the whole APK build during the final "Installing pure Python modules" phase. requests/tqdm/srt/websockets are declared by vosk's own setup.py but only used by its bundled vosk-transcriber CLI (progress bars, subtitle export, websocket streaming server) -- not by the vosk.Model / KaldiRecognizer API actually used here. Consistent with the earlier "remove runtime deps from hostpython_prerequisites" fix, which already established these aren't needed to build/use vosk's core recognition API; that fix just missed python_depends, which drives a separate p4a install stage than hostpython_prerequisites. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
wikipedia~=1.4 (a direct AVA requirement) only ships an sdist on PyPI,
so p4a's bulk pip install of recipe-less requirements fails under
--only-binary=:all: ("Could not find a version that satisfies the
requirement wikipedia~=1.4 (from versions: none)"), aborting the
final "Installing pure Python modules" stage.
wikipedia is pure Python (deps: beautifulsoup4, requests, both already
present), so a minimal PythonRecipe routes it through the normal
setup.py install path instead -- same pattern already used for
lifxlan/pywizlight, which exist for the same reason.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Correcting an earlier mistake (03ac5b9): vosk/__init__.py does `import srt`, `import requests`, `from tqdm import tqdm` unconditionally at module level -- these are not optional vosk-transcriber-CLI-only deps as I assumed. Dropping srt from python_depends let the build succeed but crashed the app at runtime: ModuleNotFoundError: No module named 'srt' (caught via `adb logcat` after installing the APK on-device.) requests/tqdm already install fine (wheels available, and both are separately required elsewhere), so they didn't need fixing. srt has no wheel on PyPI at all, so give it its own recipe (srt/__init__.py, same minimal PythonRecipe pattern as wikipedia) and depend on it as a recipe-to-recipe dependency (`depends`, which resolves through Recipe.get_recipe and actually builds it) rather than python_depends (which always routes straight to the recipe-less bulk pip stage, regardless of whether a matching recipe exists -- see graph.py get_recipe_order_and_bootstrap: python_depends entries are appended to python_modules directly, never re-checked against Recipe.get_recipe). websockets is confirmed NOT imported by vosk/__init__.py itself, so it remains correctly excluded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fixes a second on-device crash (caught via adb logcat) after the srt
fix: vosk/__init__.py's open_dll() only handles sys.platform in
("win32", "linux", "darwin"), raising TypeError("Unsupported
platform") otherwise. CPython's native Android build reports
sys.platform == "android" (a distinct value since CPython 3.13, not
"linux"), so it always hit that branch. libvosk.so is a plain ELF .so
either way (same file the recipe's install_android_libvosk() already
places next to __init__.py), so just accept "android" alongside
"linux" for that code path.
Verified the patch applies cleanly against the real v0.3.45 release
tarball.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause of the patch appearing to have no effect after fdb175c: vosk's own `pip install . --target install_dir` had neither --upgrade nor --ignore-installed/--force-reinstall. When install_dir already contained a same-version vosk from an earlier build, pip reported "Requirement already satisfied" and left the existing (unpatched) files untouched -- even though the source itself was correctly re-patched on each build. This let a stale, pre-patch vosk/__init__.py survive silently across several rebuilds (confirmed by directly inspecting build/python-installs/ava/<arch>/vosk/__init__.py, which still had the pre-patch line 34 raising TypeError). Add --upgrade --force-reinstall so build_arch always overwrites install_dir with the freshly-built (and patched) wheel, regardless of what pip's own "already satisfied" check would otherwise conclude. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.