I can confirm that the gradle-wrapper.jar matches the one generated by Android Studio Hedgehog from https://developer.android.com/studio/archive -- specifically, “Android Studio Hedgehog | 2023.1.1 Patch 2 January 23, 2024”.

But, one thing that's not clear to me: what is the license for these files?

In the Android Studio repository, I couldn't find any license at all.

The Android Studio download & installer made me agree to a “non-assignable, non-sublicensable” license, which limits what the SDK can be used for, and doesn't cover everything that Python's license allows.

The three files gradlew, gradlew.bat and gradle-wrapper.jar (collectively the "Gradle wrapper"), originate from Gradle, which is used by Android Studio but is an independent project. Like the rest of Gradle, the wrapper is covered by the Apache license, and there's a notice indicating that at the top of the scripts.

Concerns were raised on Discord that the source of the Gradle files wasn't clear enough, so I've updated them from the current version of Gradle (8.7). Here's how to verify them:

• The gradlew and gradlew.bat scripts are from the root of the Gradle repository at https://github.com/gradle/gradle/tree/v8.7.0.

• The gradle-wrapper.jar is from the Gradle release:

  • Go to https://gradle.org/releases/
  • Download the v8.7 "binary-only" package
  • Inside the ZIP, find lib/plugins/gradle-wrapper-8.7.jar
  • Inside the JAR (which is also a ZIP file), find gradle-wrapper.jar, which is the file I've just added to this PR.
  • If you look inside the inner JAR, you'll see that this version also contains a license notice.

Thanks.
I am still worried about distributing compiled artifacts without corresponding source code, and I would prefer to put this in a separate repository, downloaded on demand for Android tests, than to include it in the CPython repo.

The testing instructions added in Android/README.md are rather manual; I don't think an extra git clone would make things much worse for users.

Including the jar means we're trusting a third party -- Gradle -- and their build process. I don't have a reason to trust them, and I don't think that CPython should implicitly vouch for them.
The text files are at least auditable -- though it's tedious. I don't see why we need to set RIGHT_MARGIN to 80, or include a fully commented-out config file example, to run the tests. If we treat these like binary blobs -- output of Android Studio -- they seem fine (and perhaps non-copyrightable); but they should go in e.g. cpython-bin-deps. If we treat them as source code, then I'll review them, and I'll ask you to prune things that are not needed -- but I think that'd just add work for everyone.

If there are any license issues found later, it's much easier to remove things if they're in an isolated repo/branch. (And it's also easier for over-cautious redistributors to not include the testbed.)

Note that I am a Linux distro packager by training, conditioned to include sources and avoid bundling. I might not be representing the CPython project well. I am definitely unfamiliar with mobile development practices. If you think I'm being unreasonable, please do seek other opinions, e.g. on Discourse.

Thanks, that all makes sense.

I am still worried about distributing compiled artifacts without corresponding source code, and I would prefer to put this in a separate repository, downloaded on demand for Android tests, than to include it in the CPython repo.

Even simpler than a separate repository would be to add an option to the android.py script to obtain the Gradle wrapper directly from Gradle – essentially automating the steps listed in my previous comment. This would be no different from downloading compilers from a third party, as we do on every platform.

The text files are at least auditable -- though it's tedious. I don't see why we need to set RIGHT_MARGIN to 80, or include a fully commented-out config file example, to run the tests. [...] If we treat them as source code, then I'll review them, and I'll ask you to prune things that are not needed -- but I think that'd just add work for everyone.

Actually I've got a pretty good idea of what can be pruned. My initial plan was to keep the app as close as possible to Android Studio's new project wizard output, but I guess that does include a lot of noise. Let me see what I can do.

OK, I've removed the Gradle wrapper, added an android.py subcommand to download it, and removed all the unused boilerplate from the app, which should make the PR a lot more manageable.

Thank you! This looks good; I haven't tested it.
I'm not sure if the setup instructions will tleave the user with wget and unzip on all platforms. If not, could you add a note that they're required?
(Using Python instead of shelling out is probably not worth the work.)

I've added a list of the required tools to the README. And I've also switched from wget to curl, because it's included with macOS.

I was able to start the test suite! (There were some errors, and I didn't wait for it to finish on my non-accelerated VM, but that shouldn't block this PR.)

Everything was passing on Android a couple of weeks ago, but unrelated development has introduced a few failures since then. The next priority will be to set up a buildbot so we can find out about such failures more quickly.

Additionally, consider introducing the cross-build term "host" here:

Done.