Skip to content

Add Android Support #27698

Closed
Closed

Description

@rbebb

Proposed new feature or change:

Now that Android is a supported platform in Python 3.13, it would be great to have numpy support given that it’s the foundation of many other Python libraries. Tools that let you run Python on Android (like Chaquopy) currently have to build packages like numpy manually and create custom patches: https://github.com/chaquo/chaquopy/tree/master/server/pypi/packages/numpy

Activity

  1. mattip commented on Nov 4, 2024

    @mattip
    Member

    I had to dig around a bit for context: it seems Chaquopy is the system used to build some python libraries with c-extensions for beeware, which is the goto authority on packaging python for ios and android. As far as I can tell, those platforms cannot install wheels and are using a different packaging system for NumPy.

    What would android support look like? What do you call "numpy support"? Is there a way to emulate android on github CI so we can test the eventual build?

    It seems the patch you pointed to still uses setuptools, so the Chaquopy build would need to move to meson in order for us to merge the patch. It would be good to add such a build to CI, maybe as an additional job on the wheel build, to make sure we don't break something.

  2. rbebb commented on Nov 4, 2024

    @rbebb
    Author

    As for what support would look like, I believe a wheel with the native components built for Android is all that would be required.

    With regard to using an emulator in GitHub CI, I believe that is possible. I haven't used an emulator in GitHub CI though, and I'm not sure what a test suite would look like.

    @mhsmith, I noticed that Chaquopy hasn't added direct support for Meson yet in Chaquopy's build-wheel tool (per this open issue), but do you have more insight on what that would take? Although, perhaps it's possible to build a wheel using Meson directly without using Chaquopy's build-wheel tool? That being said, I don't have experience with using Meson to build Python wheels for Android.

  3. rgommers commented on Nov 5, 2024

    @rgommers
    Member

    It would be good to add such a build to CI, maybe as an additional job on the wheel build, to make sure we don't break something.

    +1 a CI job would be fine if that seems helpful. It'd have a similar status as for Pyodide.

  4. mhsmith commented on Nov 15, 2024

    @mhsmith
    Contributor

    The Chaquopy build tool does produce wheels – we currently host them here, and they can be built into Android apps using the Chaquopy Gradle plugin, either directly or via Briefcase. The equivalent for iOS is this tool and this repository.

    Now that Android and iOS are officially supported in Python itself, we in the BeeWare project are working on adding support for these platforms to general-purpose packaging tools such as cibuildwheel. The plan is that our existing mobile-specific packaging tools and repositories will eventually become obsolete, and projects will be able to build Android and iOS wheels with their existing workflows, and publish them on PyPI along with all the other platforms.

    Testing on Android and iOS emulators is possible on GitHub Actions, and we're already doing it in the Toga project. To see what this looks like, open one of our recent CI runs and look at the "testbed" jobs.

    @freakboy3742 is leading the work on this. We're not yet ready to recommend it for production use, but we'll post a comment here once that changes.

  5. freakboy3742 commented on Nov 16, 2024

    @freakboy3742
    Contributor

    A quick +1 to everything @mhsmith said here.

    To set expectations - the focus of the work I'm doing is to get the base tooling of the Python ecosystem into a state where iOS and Android are "just another platform".

    The patch for iOS support in pip has already landed in 24.3; iOS support in cibuildwheel is my current project. I've got an initial patch working for simple projects (like lru-dict) that are "pure" binary extension modules with no dependency complications; I'm currently working on getting Pillow building with the same tooling, as it's an example of a package that has complex third-party binary dependencies.

    I don't want to push PRs to cibuildwheel for review until I've got a reasonable degree of confidence that they're "fit for purpose"; the work so far has already highlighted some changes that need to be merged upstream to make that work possible (python-pillow/Pillow#8497, pypa/cibuildwheel#2062 and python/cpython#126169 are three examples; I'm expecting to need some more).

    Numpy and cryptography are two high-priority packages I'm intending to use as additional source of proof of any cibuildwheel patch (as they're both high profile packages with complex build requirements - Numpy with it's Meson build system, and cryptography with Rust tooling).

    Android support is independent of iOS, but there will be a lot of common patterns between the two, so once iOS support is bedded in, the path to adding Android support should be a lot more clear.

    So - this will be a long process... but I'm working on it. If anyone wants to help, let me know - I'd be grateful for the assist.

  6. rgommers commented on Sep 27, 2025

    @rgommers
    Member

    gh-29770 is a PR that attempts to add cibuildwheel config for Android. Expert input/review there would be very welcome.

  7. Manamama commented on Mar 5, 2026

    @Manamama

    FYI, there is a ready apt version in Termux for a while:

    apt list | grep numpy
    
    WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
    
    numpy/termux,now 1.20.3 aarch64 [installed]
    python-numpy-static/stable,now 2.2.5-4 aarch64 [installed]
    python-numpy/stable,now 2.2.5-4 aarch64 [installed,automatic]
    python2-numpy-static/tur-packages 1.16.6-2 aarch64
    python2-numpy/tur-packages 1.16.6-2 aarch64
    

    as of today at least, but if one needs or wants to compile numpy from scratch (other packages love to have a pinned version, or else: some elements or the newest version be needed) there is a way.

    The dreaded Problem encountered: "complex.h" header does not include complex type complex float can be overcome by this:

    CFLAGS="-Wno-c2y-extensions -Wno-unused-variable -Wno-error=c2y-extensions -march=armv8-a -O2 -fPIC -lm"

    so e.g. pipe -i https://pypi.anaconda.org/scientific-python-nightly-wheels/simple numpy -U \ --no-build-isolation \ --config-settings=setup-args="-Dc_args=-Wno-c2y-extensions -Wno-unused-variable -Wno-error=c2y-extensions"

    Here is some Grok AI's theory, feel free to skip:

    Details

    Yes — we now know exactly what to disable, and Meson has a clean, native way to do it without patching files or symlinks.

    The blocker is not the header or the type itself (both glibc and bionic work).
    The blocker is only the combination of:

    • -Wpedantic (triggers the “imaginary constants are a C2y extension” warning on 2.0fi)
    • -Werror (turns that warning into a fatal error)

    Meson (via meson-python in the NumPy sdist) does listen to these two switches that you can pass at meson setup time:

    The meson-friendly command (recommended)

    pipe -i https://pypi.anaconda.org/scientific-python-nightly-wheels/simple numpy -U \
      --no-build-isolation \
      --config-settings=setup-args="-Dc_args=-Wno-c2y-extensions -Wno-unused-variable -Wno-error=c2y-extensions"

    This does exactly what you asked for:

    • -Dc_args=… is passed directly to meson setup
    • It applies to every cc.compiles() test (including the complex-float one)
    • It suppresses the exact two warnings that were killing the build
    • No source patching, no include-path hacks, no CFLAGS guessing

    Even shorter alternatives (if you want to test quickly)

    1. Nuclear but very safe (turns off all pedantic warnings globally):

      --config-settings=setup-args="-Dwarning_level=0"
    2. Disable Werror entirely (Meson respects this):

      --config-settings=setup-args="-Dwerror=false"

    How to run it

    Just replace your normal pipe … numpy -U with one of the above.
    Example with the precise one:

    pipe -i https://pypi.anaconda.org/scientific-python-nightly-wheels/simple numpy -U \
      --no-build-isolation \
      --config-settings=setup-args="-Dc_args=-Wno-c2y-extensions -Wno-unused-variable -Wno-error=c2y-extensions"

    If the build still complains about the same error, add the nuclear option on top:

    --config-settings=setup-args="-Dwarning_level=0 -Dc_args=-Wno-c2y-extensions"

    These are the switches Meson actually listens to (confirmed in NumPy/SciPy build issues and meson-python docs). No more reinventing — this is the official, intended way.

  8. added this to the 2.6.0 Release milestone on Jul 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions