For Rust projects built with Maturin, it currently does not work. Maturin has some cross-compilation issues on Android that still need to be fixed.

For details, please see PyO3/maturin#2810

This looks nice and neat! Is there an example of it working in a real project that you've been testing it with?

I want to test， but I did not know how to run this without the github action，if you know how to do, you can tell me，and I will test it.

This commit is a modification I made based on the actual missing environment configuration built on Android using cbuildwheel.

Of course, I manually configured it externally in a non-isolated environment, and after the configuration, I built the wheel correctly and it can run on Android

You can test a project using something like this in a github workflow-

      - name: Build wheels
        uses: ririv/cibuildwheel@main

Thanks, I have tested it, and made some new commits. Now, it works.

• The CARGO_TARGET_<triple>_LINKER must be set. Otherwise, it will use the host's linker cc, which will result in an error.
• The PYO3_CROSS_LIB_DIR must be set to link against libpython3.x.so explicitly.
  See: https://peps.python.org/pep-0738/#linkage and https://pyo3.rs/v0.27.1/building-and-distribution.html#cross-compiling

The PYO3_CROSS_LIB_DIR environment variable should be set here rather than requiring users to specify it manually, for the following reasons:

• PYO3 has become the de facto standard for Python extension modules built with Rust. Both setuptools-rust and maturin are tools developed by the PYO3 team specifically to serve PYO3.
• The value set for PYO3_CROSS_LIB_DIR requires the directory path of target_python. This path is already configured within cbuildwheel's android.py but cannot be directly accessed externally. External configuration would necessitate manually constructing the path.
• PYO3's documentation for Android cross-compilation is insufficiently detailed. If users attempt to set this variable manually, they are likely to become confused and unsure how to proceed.

https://github.com/ririv/android-wheels/blob/main/.github/workflows/cbuildweel-repair-test.yml
This is the workflow file. It performed some conversions.
For the maturin project, it was converted to a setuptools-rust project. This is because maturin has some bugs in Android cross-compilation. I've submitted a PR to fix it, but the maturin maintainer hasn't responded yet.

Here are some logs:

• pydantic-core | maturin convert to setuptools-rust
  https://github.com/ririv/android-wheels/actions/runs/19223626338/job/54946144941
• tiktoken | based on setuptools-rust
  https://github.com/ririv/android-wheels/actions/runs/19223649349/job/54946212372

Looks good to me! @mhsmith what do you think?

Sorry for the delay, I'll look at this as soon as I can.

Thanks for the suggestions. I've updated the PR to address the feedback:

• Lazy Rust Setup: I implemented the shim/wrapper approach for cargo and rustup as suggested. This ensures zero overhead for non-Rust projects, as the Android target is only installed when a Rust command is actually triggered. I used absolute paths in the shims to avoid recursion.
• Platform Alignment: Cleaned up the redundant log.notice calls and removed the defensive CC check to follow the android-env.sh contract.
• New Integration Test: Added test_setuptools_rust to test_android.py. It builds a minimal Rust extension and runs it on the emulator to verify the whole flow.

Since PyO3/maturin#2825 has been merged into main, we can now use cibuildwheel to test Rust projects built with maturin. However, as a new version hasn't been released yet, we have to build maturin from source for now.

This is the GItHub Action script:

https://github.com/ririv/android-wheels/blob/main/.github/workflows/test-cbuildwheel-repair-maturin-source.yml

This is the logs:

• zstandard | non-Rust project
  https://github.com/ririv/android-wheels/actions/runs/20427696018
• tiktoken | based on setuptools-rust
  https://github.com/ririv/android-wheels/actions/runs/20427678027

Sorry, there are still some issues with the maturin integration: it's building for Linux instead of Android. This might be a problem with the build module; I will investigate and fix it.

• pydantic_core | based on maturin
  https://github.com/ririv/android-wheels/actions/runs/20427674411

However, we can still use a conversion tool to transform maturin projects into setuptools-rust projects and successfully build Android wheels.

• pydantic_core | maturin convert to setuptools-rust
  https://github.com/ririv/android-wheels/actions/runs/20429779899

I have investigated the issue with the wheel generated by maturin. It actually produced the correct wheel, but the tag was incorrect.
This occurred because maturin does not yet support Android platform tags, causing it to mistakenly identify Android as Linux and generate an incorrect tag.
I have submitted a PR to maturin to fix this. Details can be found at PyO3/maturin#2900

This issue is unrelated to the current PR. So, no modification is necessary.
Please review, thanks. @mhsmith

Thanks; I'm on vacation at the moment, but I'll look at this in the new year.

Key Changes:

1. Resource-based Shim Script:

   • Moved the inline shim script from android.py to a standalone static resource file: cibuildwheel/resources/_rust_shim.py.
   • The shim logic is now consistent with _cross_venv.py. It dynamically detects the real rustup/cargo in $PATH and reads the target triplet from the CIBW_HOST_TRIPLET environment variable at runtime.

2. Simplified android.py Logic:

   • Removed the conditional check for rustup existence in setup_rust.
   • The setup_rust function now unconditionally installs the shim scripts into the virtual environment's bin directory and sets the necessary environment variables (CARGO_BUILD_TARGET, PYO3_CROSS_LIB_DIR, linkers, etc.).
   • This ensures a lazy setup: rustup target add is only triggered if and when the build process actually calls cargo.
   • Rename: python_configuration -> config

3. Expanded Test Coverage:

   • Added test_maturin integration test: Since the relevant PR has been merged into maturin (now requiring maturin >= 1.11.0), I've added a new test in test/test_android.py to verify this path.

Ready for re-review. Thanks! @mhsmith

Here is how the Rust shim script integrates into the build process:

1. Deployment (The "Trap"):
   During environment setup (setup_android_env), cibuildwheel copies _rust_shim.py into the virtual environment's binary directory (venv/bin/), renaming it to cargo and rustup. Since venv/bin/ is prepended to the system PATH, these shims effectively shadow the system's real Rust binaries.

2. Interception & Setup (Lazy Execution):
   When the build frontend (e.g., pip or build) invokes cargo, the OS executes our shim script first (via the #!/usr/bin/env python3 shebang). The script reads the target architecture from the CIBW_HOST_TRIPLET environment variable and, if the required Android target is missing, silently executes rustup target add <target> to install it on demand.

3. Handoff (Transparency):
   Once the environment is ready, the shim locates the real cargo executable in the remaining PATH. It then replaces the current process with the real cargo (using os.execv), passing along all original CLI arguments. This ensures the build continues seamlessly with the correct cross-compilation environment now in place.