gh-131531: Add android.py package command

[mhsmith]

This PR makes two changes:

• Move Android's build and prefix directories from cpython/cross-build into cpython/Android.
• Add an android.py package command which creates a tarball from a subset of the Android directory, including all the files useful either for embedding Python in an app, or building third-party packages against it.

The resulting package is about 30 MB. Here's an example artifact (temporary URL).

The package includes a copy of the testbed and the android.py script, which can be used to run the CPython test suite outside of the context of the source tree. A future PR will add the ability to run test suites of third-party packages.

For Python 3.13 and older, we can host these packages in the Chaquopy Maven Central repository for the use of cibuildwheel and Chaquopy itself. From 3.14 onwards, they will hopefully be hosted on python.org.

• Issue: Android cibuildwheel support #131531

---

📚 Documentation preview 📚: https://cpython-previews--131532.org.readthedocs.build/

[freakboy3742]

The mechanics of what is here generally looks good; it's the higher-level design that gives me pause.

In particular, I'm unclear on the motivation behind moving the compilation process - and especially the build target - out of the cross-build folder.

From a purely practical perspective, the build folder can be re-used between emscripten, iOS and Android; so it make some sense to keep it in a common location. This set of changes would mean needing to keep an independent set of builds for Android.

More generally, it's breaking the expectation that a build can be performed "out-of-tree" in a (mostly arbitrary) location.

If the issue is ensuring that the prefix directory is in a known location for testing purposes, would it not be better to keep the Android folder as a source directory, and "package" the distribution artefact using a temporary folder that is a clone of the parts of the Android source folder that are known to be required, plus a copy of the prefix directory in the expected location?

That would also allow the distribution artefact to include files that aren't in the Android folder - for example, license files and the like that may be required for distribution purposes, but won't be duplicated in the Android folder itself because they're common across distribution artefacts on all platforms.

That approach would also be consistent with how the iOS testbed works. The iOS testbed has 2 modes: "clone" and "run". The iOS folder contains the source project; during a test pass, "clone" is used to copy the testbed to a new location, and is provided a path to a compiled iOS Framework as part of that clone process. The test is then run on the cloned version, not the original source location.

The iOS testbed doesn't manage the initial build, or building the final release artefact, but it could - and probably should as part of any move to make an official iOS artefact). However, the general approach of using the iOS/Android folder purely as a source, rather than a working directory, should work for both platforms, and for both testing and distribution packaging. It also allows the distribution process to be "opt in" on what should be distributed, rather than excluding specific artefacts from a complete build (which could easily lead to new files being inadvertently included in a distribution artefact because we forget to exclude them).

[freakboy3742]

This is definitely an eventual goal, but until we can actually offer this, we shouldn't document it as an option.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.