gh-158018: Factor out non-app-specific parts of the Android testbed

[mhsmith]

This is the first step towards splitting the Android testbed into a separate repository. For this PR, all code still remains in the cpython repository, but we create a "lower-level script" as described in the linked issue, which can be used to run Android apps other than the Python testbed.

For example, you can use the script to run one of the test apps from chaquo/chaquopy#1474:

msmith@MacBook-Pro cpython % python Platforms/Android/android_run.py --connected emulator-5554 -P chaquopy.version=3.13 -P chaquopy.packages="brotli murmurhash" ~/git/chaquo/chaquopy/server/pypi/pkgtest
Waiting for app to start - this may take several minutes
PID: 32448
test_basic (chaquopy.test.brotli.TestBrotli.test_basic) ... ok
test_basic (chaquopy.test.murmurhash.TestMurmurhash.test_basic) ... ok
----------------------------------------------------------------------
Ran 2 tests in 0.006s
OK

• Issue: Split Android testbed into a separate package #158018

[freakboy3742]

My initial impression is that it would be worth keeping consistency between platforms here - if android_run.py were moved to testbed/__main__.py, it would keep the same execution surface as iOS - python Platforms/Android/testbed --connected ...; with the added benefit that the testbed directory becomes a self-contained artefact.

IMHO, ideally, it would have the same external command surface as well - the clone subcommand is really handy for ensuring that you have a "clean" original testbed, and per-project working directory that you can run.

If there are opportunities to consolidate other arguments or details of the command surface, that would be an added bonus.

[mhsmith]

I agree that would be a good idea eventually, and I already suggested adding the clone command in the linked issue. However, this PR is actually working at a lower level, creating a script which can be used to test any Android app, even one that has nothing to do with Python. I don't think there's any equivalent to that in the Apple directory.

[freakboy3742]

These changes all look like they make sense; but I'm not sure I'm 100% comfortable merging them without a better picture of what the end state looks like.

I understand there's the pressure to get this into the final 3.13 release; given that has been accelerated to today (+/- timezones), the idea of landing a non-trivial refactor of the Android runner potentially hours before the final release makes me nervous. Whatever the flaws and limitations of the current runner, we know the current state of the Android runner works; if we've missed anything in this refactor, we won't have any opportunity to fix it.

Plus - if the motivation for the backport is that we can't easily update the Android runner for cibuildwheel (et al) purposes, splitting out the runner into a separate repo and including this refactor there seems like the best motivator to drive adoption of that external runner project.

[mhsmith]

Thanks, that makes sense. I wasn't aware that the 3.13 release had been brought forward, but there's no urgency to get this PR into it. As I said in #158018, even if the Python release packages contain an old version of the testbed, cibuildwheel and other external users are still free to get a newer version from somewhere else.