Add support for targeting Android by mhsmith · Pull Request #824 · mesonbuild/meson-python

mhsmith · 2025-12-10T16:31:15Z

Using the same approach as on iOS.

Closes Feature Request: Add support for building Android wheels #810

This PR branch is temporarily used by several other PRs: see the cross-references below.

rgommers · 2025-12-10T17:33:34Z

Thanks @mhsmith. Same approach as for iOS seems fine indeed. I added "Closes gh-810" to the PR description.

mhsmith · 2026-01-31T13:37:08Z

@rgommers: This PR is ready for review. Compared to the iOS PR, this one is a bit simpler:

No updates were required to Meson itself.
No special handling was required for Android versions or wheel tags, since this is all done by cibuildwheel.

rgommers

Thanks @mhsmith. The main question I have now is: it looks like you're assuming that only cibuildwheel will be supported, and not regular cross compilation to Android. Is that correct? If so, I'm not sure that's right - and the iOS support doesn't do that as far as I can tell (or it's more hidden and missing code comments?).

Other questions that came up for me, like what platforms Android supports (e.g., armv7) and whether that's supported when using cpu_family = {platform.machine()!r} kinda depend on that first question.

mhsmith · 2026-02-01T17:04:02Z

it looks like you're assuming that only cibuildwheel will be supported, and not regular cross compilation to Android

That's a good point: Android packages could be native-compiled in an environment like Termux. I've changed the code to only use cross-compilation mode when it detects it's running within cibuildwheel.

As far as I know, there's no native compilation option on iOS, because the platform is too restrictive, e.g. apps cannot create subprocesses.

Other questions that came up for me, like what platforms Android supports (e.g., armv7) and whether that's supported when using cpu_family = {platform.machine()!r}

Officially Python only supports Android on aarch64 and x86_64. However, it's used unofficially on other architectures, so I've added coverage for all the known values of platform.machine that Android can return.

eli-schwartz · 2026-02-01T17:34:26Z

That's a good point: Android packages could be native-compiled in an environment like Termux. I've changed the code to only use cross-compilation mode when it detects it's running within cibuildwheel.

Anecdotally, Termux for me shows python 3.12 with a platform value of "Linux". :)

mhsmith · 2026-02-01T18:08:15Z

Yes, that was changed in Python 3.13 when we added official Android support. cibuildwheel will only support Android on Python 3.13 or later, so the cross file should use the new value.

rgommers · 2026-02-02T14:19:13Z

We get the occasional Termux-related bug report in NumPy, so that does appear to be used indeed.

The approach you took now looks better to me. CIBW_HOST_TRIPLET doesn't seem to be a public environment variable for cibuildwheel though (or is it just missing from the docs?), so it might be safer to pick a variable that is public?

mhsmith · 2026-02-04T10:38:57Z

I'm not aware of any public way to detect that a build is running within cibuildwheel. The environment variables in their documentation are all used as configuration inputs to cibuildwheel, rather than outputs that you can rely on being set within the build.

So I've changed it to use sys.cross_compiling instead, which has the advantage of not depending on any particular build tool.

rgommers · 2026-02-06T15:31:13Z

Thanks for the update.

So I've changed it to use sys.cross_compiling instead, which has the advantage of not depending on any particular build tool.

It does depend on tools, right? I guess all we care about here is that cibuildwheel sets that. Proper cross-compiling (i.e., provide a cross file, not with hacks like crossenv) will not have this set, but as long as we document that it's specific to cibuildwheel and crossenv I can live with this code, given that there indeed doesn't appear to be an officially supported way to special-case cibuildwheel.

mhsmith · 2026-02-08T10:13:06Z

Python doesn't really provide any "proper cross-compiling" mechanism, so the crossenv-like approach is the only feasible option for cross-compiling Android and iOS wheels at the moment.

as long as we document that it's specific to cibuildwheel and crossenv I can live with this code

I've mentioned that in the comment on line 749.

rgommers · 2026-02-08T11:05:37Z

Thanks @mhsmith. For context: Python itself doesn't, and probably won't for at least a couple more years, but both Meson and CMake have solid cross-compilation support, and with Meson cross files + PEP 739 (build-details.json) cross compilation can start to look pretty clean. E.g., see this branch for scipy, it comes down to setting up the build and host envs, and then:

python -m build -wnx -Csetup-args=--cross-file=$PWD/ci/cross_aarch64.ini -Csetup-args=-Dpython.build_config=$HOST_ENV/lib/python3.14/build-details.json

Support in Meson for PEP 739 has landed, and support in meson-python will follow (hopefully soon). All that "support in Python" should then mean is "how do we point at the target interpreter (i.e., $HOST_ENV/lib/python3.14/build-details.json) in a more ergonomic fashion?".

tl;dr we should not build in implicit assumptions around crossenv anywhere in the ecosystem, because that's a pretty bad pile of hacks under the hood, and not supportable properly long-term, or even today by distros.

rgommers · 2026-02-08T11:12:35Z

mesonpy/__init__.py

+        # with cibuildwheel), in which case we should generate a cross file.
+        # sys.cross_compiling isn't an official Python API, but it originated from
+        # crossenv and has been followed by other cross-compiling tools.


Hence I suggest to change the comment along these lines:

Suggested change

# with cibuildwheel), in which case we should generate a cross file.

# sys.cross_compiling isn't an official Python API, but it originated from

# crossenv and has been followed by other cross-compiling tools.

Cross compilation can be done the regular Meson way with separate build and host envs,

or with `cibuildwheel` which is `crossenv`-based. Here we try to detect whether

cibuildwheel/crossenv are used, through the `sys.cross_compiling` variable which they

define, and we synthesize a cross file in that case to make that work out of the box.

I think the idea and code are fine.

dnicolodi

I am not sure I understand what this PR implements. The commit message states that this implements support for Android. However, it seems to implement support for cross-compiling for Android. I think native compilation for Android works already as I don't have evidence of the contrary and this PR does not affect native compilation.

Furthermore, this PR seems to only address the case of a cross compilation environment setup by cibuildwheel. However, the code and the comments therein seem to indicate that this is somehow more generic.

I think that supporting cibuildwheel covers an important use case, thus this PR is good to have. On the other hand, it seems that we are designing support for new systems with the same ugly hacks that were used in the past to work around limitations it the build tools. Concretely, i don't understand why we need to rely on sys.cross_compiling. If this is designed to support only cibuildwheel I am sure we can use some other indicator to detect the cross compilation environment, especially if we already rely on environment variables to setup the compilation environment.

dnicolodi · 2026-02-08T12:12:01Z

mesonpy/__init__.py

+        # sys.cross_compiling isn't an official Python API, but it originated from
+        # crossenv and has been followed by other cross-compiling tools.
+        elif (
+            sysconfig.get_platform().startswith('android-')


Why not simply

Suggested change

sysconfig.get_platform().startswith('android-')

sys.platform == 'android'

?

dnicolodi · 2026-02-08T12:13:07Z

mesonpy/__init__.py

+                # Binaries are controlled by environment variables, so they don't need
+                # to be repeated here.


I don't think there is any value in adding this comment to the generated file.

dnicolodi · 2026-02-08T12:14:42Z

mesonpy/__init__.py

+            cpu_family = (
+                'arm' if cpu.startswith('arm') else 'x86' if cpu.endswith('86') else cpu
+            )


Suggested change

cpu_family = (

'arm' if cpu.startswith('arm') else 'x86' if cpu.endswith('86') else cpu

)

cpu_family = 'arm' if cpu.startswith('arm') else 'x86' if cpu.endswith('86') else cpu

This is ugly, but please don't use the black code uglifier to make it uglier.

dnicolodi · 2026-02-08T12:15:51Z

mesonpy/__init__.py

+        elif (
+            sysconfig.get_platform().startswith('android-')
+            and getattr(sys, 'cross_compiling', False)
+        ):


Suggested change

elif (

sysconfig.get_platform().startswith('android-')

and getattr(sys, 'cross_compiling', False)

):

elif sys.platform == 'android' and getattr(sys, 'cross_compiling', False):

Please don't use the black code uglifier.

dnicolodi · 2026-02-08T12:18:48Z

mesonpy/__init__.py

+                # cibuildwheel's cross virtual environment will make Meson believe it's
+                # running on Android when it's actually running on Linux or macOS.
+                needs_exe_wrapper = true


I don't get how the comment (which I don't think should be in the generated file) goes with the implemented setting. How does cibuildwheel makes Meson believe it is running on Android? And why does it do so? It is clearly not the case. Also, what it the exe wrapper that is needed? This seems incomplete at best.

dnicolodi · 2026-02-08T12:19:44Z

tests/test_project.py

+    monkeypatch.setattr(sysconfig, 'get_platform', Mock(return_value='android-24'))
+    if cross:
+        monkeypatch.setattr(sys, 'cross_compiling', True, raising=False)
+        monkeypatch.setenv('STRIP', '/path/to/strip')


Why is setting this environment variable needed?

mhsmith · 2026-02-08T12:59:08Z

Thanks for the comments. I have some business travel and vacation coming up, so it'll probably take me a couple of weeks to reply.

mhsmith mentioned this pull request Dec 10, 2025

BLD: Add Android support numpy/numpy#30412

Draft

rgommers added the enhancement New feature or request label Dec 10, 2025

mhsmith mentioned this pull request Dec 18, 2025

BLD: Add Android support pandas-dev/pandas#63405

Draft

4 tasks

This was referenced Jan 11, 2026

BLD: Add Android support scipy/scipy#24341

Draft

BLD Add Android support scikit-learn/scikit-learn#33055

Draft

Support meson in build-wheel chaquo/chaquopy#1041

Closed

mhsmith force-pushed the android branch from 301481b to 2cb8080 Compare January 31, 2026 13:29

mhsmith marked this pull request as ready for review January 31, 2026 13:32

mhsmith mentioned this pull request Jan 31, 2026

Document system() == "android" as a fully supported value mesonbuild/meson#15510

Merged

rgommers reviewed Jan 31, 2026

View reviewed changes

mhsmith force-pushed the android branch from 2cb8080 to a64d42c Compare February 1, 2026 16:55

mhsmith requested a review from rgommers February 1, 2026 17:05

ENH: Add support for targeting Android

2d9019d

mhsmith force-pushed the android branch from a64d42c to 2d9019d Compare February 4, 2026 10:32

rgommers reviewed Feb 8, 2026

View reviewed changes

rgommers mentioned this pull request Feb 8, 2026

Feature Request: Add support for building Android wheels #810

Open

rgommers added this to the v0.20.0 milestone Feb 8, 2026

dnicolodi requested changes Feb 8, 2026

View reviewed changes

-        # with cibuildwheel), in which case we should generate a cross file.
-        # sys.cross_compiling isn't an official Python API, but it originated from
-        # crossenv and has been followed by other cross-compiling tools.
+Cross compilation can be done the regular Meson way with separate build and host envs,
+or with `cibuildwheel` which is `crossenv`-based. Here we try to detect whether
+cibuildwheel/crossenv are used, through the `sys.cross_compiling` variable which they
+define, and we synthesize a cross file in that case to make that work out of the box.

	sysconfig.get_platform().startswith('android-')
	sys.platform == 'android'

		# Binaries are controlled by environment variables, so they don't need
		# to be repeated here.

Conversation

mhsmith commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rgommers commented Dec 10, 2025

Uh oh!

mhsmith commented Jan 31, 2026

Uh oh!

rgommers left a comment

Choose a reason for hiding this comment

Uh oh!

mhsmith commented Feb 1, 2026

Uh oh!

eli-schwartz commented Feb 1, 2026

Uh oh!

mhsmith commented Feb 1, 2026

Uh oh!

rgommers commented Feb 2, 2026

Uh oh!

mhsmith commented Feb 4, 2026

Uh oh!

rgommers commented Feb 6, 2026

Uh oh!

mhsmith commented Feb 8, 2026

Uh oh!

rgommers commented Feb 8, 2026

Uh oh!

rgommers Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

dnicolodi left a comment

Choose a reason for hiding this comment

Uh oh!

dnicolodi Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

dnicolodi Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

dnicolodi Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

dnicolodi Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

dnicolodi Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

dnicolodi Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

mhsmith commented Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mhsmith commented Dec 10, 2025 •

edited

Loading