You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
Reacted by Ralf Gommers, Marten van Kerkwijk and Ryan Bebb
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:
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.
Activity
mattip commentedon Nov 4, 2024
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.
rbebb commentedon Nov 4, 2024
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.
rgommers commentedon Nov 5, 2024
+1 a CI job would be fine if that seems helpful. It'd have a similar status as for Pyodide.
mhsmith commentedon Nov 15, 2024
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.
freakboy3742 commentedon Nov 16, 2024
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
piphas already landed in 24.3; iOS support incibuildwheelis 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.
BLD: cross-compilation for android using cibuildwheel
rgommers commentedon Sep 27, 2025
gh-29770 is a PR that attempts to add
cibuildwheelconfig for Android. Expert input/review there would be very welcome.Manamama commentedon Mar 5, 2026
FYI, there is a ready
aptversion in Termux for a while: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 floatcan 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
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.