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.

I've updated the comment based on the changed approach to use the CIBUILDWHEEL variable.

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'

?

I was following the pattern of the existing branches of the if. I agree all three of them would be simpler as sys.platform, but that would add noise to this PR, so would better be done in a separate one.

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.

I've updated the comment to explain this in more detail. I think it's worth keeping the comment in the generated file to explain the setting to anyone who examines that file without being familiar with meson-python internals.

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?

Without it, the tests fail with this error:

WARNING: Cross file does not specify strip binary, result will not be stripped. ERROR: Fatal warnings enabled, aborting

However, I guess Meson could just as easily do this with any other build tool, so I've updated the tests to include them all. This more closely simulates what cibuildwheel does.

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.

rgommers · 2026-02-09T18:05:38Z

@dnicolodi I think your main review comment above covers the same ground that my comments did? What this implements is the same as for iOS. And yes I already pointed out that regular cross-compiling is a thing and this is cibuildwheel-specific, and hence the code comments need a tweak.

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,

Initial reply from @mhsmith in this comment above. I'd also like a cleaner way to do this. I looked through the cibuildwheel docs again, and it does guarantee that the CIBUILDWHEEL environment variable is set to 1: https://cibuildwheel.pypa.io/en/stable/faq/#optional-extensions. So that may be the cleaner, supported way to implement this?

dnicolodi · 2026-02-09T19:57:31Z

I haven't read the conversation in detail, and my questions are maybe due to my complete ignorance about how you go about compiling something for Android. I saw that you planned to merge this unless someone spoke up, thus I assumed you are happy with the status of the PR. I noticed the disconnect between the commit message (that is the base for our changelog entries, especially when reporting about features not implemented by one of the maintainers) and I thought that some clarification is necessary.

It is fine to merge this to support the cibuildwheel use case. However, it would be nice to make sure that this will not make it harder to build in a different development environment where the Android development tools have been installed. The cibuildwheel documentation that I have seen does not say much about how the cross-compilation is setup and I haven't had time to look at the code. Thus, gating this on the CIBUILDWHEEL env var seems a good idea.

mhsmith · 2026-02-23T15:49:41Z

I'd also like a cleaner way to do this. I looked through the cibuildwheel docs again, and it does guarantee that the CIBUILDWHEEL environment variable is set to 1: https://cibuildwheel.pypa.io/en/stable/faq/#optional-extensions. So that may be the cleaner, supported way to implement this?

My intention was to avoid privileging cibuildwheel over any similar tools, but I guess we are still making some cibuildwheel-specific assumptions, so this makes sense. I'm not aware of any other active Android Python cross-compilation tools, but if they appear in the future, we can revisit this.

mhsmith · 2026-02-23T15:50:26Z

The commit message states that this implements support for Android. However, it seems to implement support for cross-compiling for Android.

I've updated the commit message.

dnicolodi

Thanks for working on this. Just a couple of minor things, mostly to make the whole easier for me to understand when I'll go back to it in the future.

dnicolodi · 2026-02-24T12:41:49Z

mesonpy/__init__.py

+        # that work out of the box.
+        elif sysconfig.get_platform().startswith('android-') and 'CIBUILDWHEEL' in os.environ:
+            cpu = platform.machine()
+            cpu_family = 'arm' if cpu.startswith('arm') else 'x86' if cpu.endswith('86') else cpu


Can we have a comment that explains what this normalization does? I find the 'x86' if cpu.endswith('86') part particularly puzzling. What does platform.machine() return other than x86? Judging from the test, this simply maps i686 to x86. If this is the case, the more explicit 'x86' if cpu == 'i686' would be better.

dnicolodi · 2026-02-24T12:50:40Z

mesonpy/__init__.py

+        # Android may be native-compiled (e.g. with Termux), cross-compiled with manual
+        # Meson arguments, or cross-compiled with cibuildwheel, which uses a similar
+        # approach to crossenv. In the latter case, we synthesize a cross file to make
+        # that work out of the box.


I think

Suggested change

# Android may be native-compiled (e.g. with Termux), cross-compiled with manual

# Meson arguments, or cross-compiled with cibuildwheel, which uses a similar

# approach to crossenv. In the latter case, we synthesize a cross file to make

# that work out of the box.

# Simplify cross-compilation for Android with cibuildwheel: detect the

# cross-compilation environment set up by cibuildwheel and synthesize an

# appropriate cross file.

is more to the point and describes what the following code block is really about.

dnicolodi · 2026-02-24T13:21:01Z

mesonpy/__init__.py

+                # cibuildwheel monkey-patches platform.system and platform.machine to
+                # simulate running on Android, when it's actually running on Linux or
+                # macOS. So the host and build machines will appear to match, but host
+                # binaries cannot actually be run on the build machine. As described at
+                # https://mesonbuild.com/Cross-compilation.html, we indicate this by
+                # setting needs_exe_wrapper = true, but NOT setting exe_wrapper.


Mostly to make things easier for me to understand when I will go back to read this one year from now:

Suggested change

# cibuildwheel monkey-patches platform.system and platform.machine to

# simulate running on Android, when it's actually running on Linux or

# macOS. So the host and build machines will appear to match, but host

# binaries cannot actually be run on the build machine. As described at

# https://mesonbuild.com/Cross-compilation.html, we indicate this by

# setting needs_exe_wrapper = true, but NOT setting exe_wrapper.

# Due to Python lacking proper cross-compilation support, for the build

# to produce the correct wheel tags when cross-compiling for Android,

# cibuildwheel monkey-patches platform.system() and platform.machine()

# to simulate running on Android. This makes Meson believe that host and

# build machines match and thus that host binaries can be run on the build

# machine, when this is not actually the case. Override the auto-detection.

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

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

ENH: Add support for cross-compiling Android with cibuildwheel

84e9f2f

mhsmith force-pushed the android branch from 2d9019d to 84e9f2f Compare February 23, 2026 15:40

mhsmith requested review from dnicolodi and rgommers February 23, 2026 15:51

dnicolodi requested changes Feb 24, 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.

Comments

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dnicolodi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhsmith Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhsmith commented Feb 8, 2026

Uh oh!

rgommers commented Feb 9, 2026

Uh oh!

dnicolodi commented Feb 9, 2026

Uh oh!

mhsmith commented Feb 23, 2026

Uh oh!

mhsmith commented Feb 23, 2026

Uh oh!

dnicolodi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mhsmith commented Dec 10, 2025 •

edited

Loading

mhsmith Feb 23, 2026 •

edited

Loading