Full disclosure: I’m @mhsmith’s co-worker, so it won’t be surprising when I say I’m fully in favor of this proposal 
.
For some background: BeeWare has supported Android for ~9 years; but that support has been in 4 distinct phases:
- An initial “embedded CPython” approach, many years ago. That was abandoned because of kernel-based JNI limits that existed on Android in the early days (Pre Android 4)
- An approach based on transpiring CPython code to Java byte code. This didn’t embed any C code, but was effectively a from-scratch Python re-implementation. It allowed you to write an Android app in Python, but it didn’t allow interaction with most of the Python ecosystem (essentially anything with a C module, or anything in the standard library that was implemented in C)
- An “embedded CPython” approach that BeeWare maintained. This is part of the the work that the PSF funded in 2019.
- Using Chaquopy’s embedded CPython build and related tooling.
What has been proposed in this PEP is consistent with my experience from those implementations. For the most part, this is really a “can we just run Android in CI and formalise this already?” PEP. Unlike iOS, the number of extra patches needed is relatively small - it’s mostly changes around documentation and CI integration.
However, there are a couple of novel parts in the PEP for which I want to formally voice my support.
Specifically, I’m a strong +1 on the sys.platform = 'android' part of the proposal. Having sys.platform='linux' on Android is a “technically correct is the best kind of correct” answer. Yes, Android is, technically, “a Linux”. In practice, while there is some “Linux compatible” code that will run unmodified on Android, there’s just as much that isn’t. This is because the things that sys.platform is used to gate are, by definition, platform specific. In practice, “Linux” isn’t just a kernel - it’s lots of other device expectations, filesystem expectations, userspace expectations, and more.
At the very least, the build process for C modules is almost always radically different, and there’s plenty of setup.py build configurations that use sys.platform as a way to identify platform-specific compilation flags - which are rarely the same on Android as they would be on a Linux.
As a simple matter of practicality, being able to do dictionary lookups on sys.platform to select Android-specific logic, and use sys_platform=='android' in a requirements specifier are two basic UX affordances that are worth their weight in gold. The price we pay for this affordance is that code that would run unmodified will require a patch to read if sys.platform in {'linux', 'android'}. For me, this is a throughly acceptable and reasonable price to ask.
I’m also in favor of the changes to platform that expose more “as experienced by the user” values to uname(), etc. However, I suspect these will be less controversial.