General

Android is broadly a POSIX platform, based on a Linux kernel and the ELF binary format. It does not use glibc, instead providing its own C library implementation called Bionic. As a result, it is generally not binary-compatible with any other Linux distribution, even if the architecture matches. It also has its own filesystem layout which doesn’t resemble any other Unix.

However, Android’s source-compatibility with Linux is quite good. In its early years, the C library was very incomplete, but most of the gaps were filled by around 2014. Since then, any C code that compiles for Linux can usually be compiled for Android, unless it involves direct access to hardware devices or operating system services.

This is also true of CPython. Although it has never officially supported Android, recent versions (since 3.6) can already be compiled for Android with minimal patching.

OS versions

Each Android version can be identified in three ways:

• A conventional dotted version number (though recent versions have all used whole numbers)
• A sequential integer “API level” (the most common form in developer documentation)
• An alphabetic confectionery-themed code name (no longer used for marketing, but still appears in developer documentation)

There is no consistent pattern to link one of these to another; they must be looked up in a table.

A new major Android version is released each year, but the updates available to each device are entirely under the control of its manufacturer. Unfortunately many manufacturers stop sending updates to devices long before their users are ready to dispose of them. For example, as of October 2023, the oldest Android version still receiving security updates was API level 30, but according to Google’s own statistics, only 60% of devices were on that version or newer.

For Python 3.13 we therefore propose the minimum Android version to be 5.0 (API level 21), which was released in 2014. According to the statistics above, this would cover 99% of active devices.

Development tools

The Android development tools are equally supported on Linux (x86_64), Windows (x86_64) and macOS (x86_64 and ARM64). For CPython, the most important tools are:

• The NDK (native development kit) contains a C and C++ compiler (clang), linker (lld), and headers for all the system libraries.

  Binary compatibility between libraries compiled with different versions of the NDK is generally very good, but for reproducibility it would be best for each Python version to stick with one NDK version throughout its life. For Python 3.13, this would be the current NDK long-term support version, r26.

  Each NDK version can be set to target any of a wide range of Android versions. For example, NDK r26 supports API levels 21 to 34. However, binaries compiled for an older Android version will usually keep on working indefinitely on newer versions; exceptions to this rule are only made for security reasons.

• Gradle is the tool used to build complete, deployable apps.
• The emulator, based on QEMU, is a simulated Android device running on a development machine. Unlike on iOS, an emulator uses the same ABI as a real device of the same architecture, and can run the same binaries.

These tools may all be used either from the command line, or through the Android Studio IDE, which is based on IntelliJ IDEA.

Architectures

Android currently supports 4 architectures. Their names as used by the Android tools are:

• armeabi-v7a
• arm64-v8a
• x86
• x86_64

Virtually all current physical devices use one of the ARM architectures. x86 and x86_64 are supported for use in the emulator.

For Python 3.13 we propose that Tier 3 support will only cover the 64-bit platforms (arm64-v8a and x86_64):

• x86 has not been supported as a development platform since 2020, and no new emulator images have been released since then.
• armeabi-v7a’s proportion of active devices is now less than 10% and steadily falling.

  It would also be more difficult to cover with a reliable buildbot, since there are no native hosts available for the emulator (ARM64 Macs don’t have hardware support for ARM32 code). Although cross-architecture emulation is possible, it has much worse performance and stability, which is why the armeabi-v7a emulator images have not been updated since 2016.

  However, it continues to be used for watches and ultra-low-cost phones. If this persists, we may need to consider adding it in a future Python version.

Even if 32-bit architectures are not officially supported, no changes should be made which would impede any downstream projects which still wish to build them.

App lifecycle

The primary programming language in Android apps is Java, or its modern descendant Kotlin. As such, an app does not provide its own executable file. Instead, all apps start off as a Java virtual machine running an executable provided by the operating system. The app’s Java code can then add native code to the process by loading dynamic libraries and calling them through JNI.

Unlike iOS, creating subprocesses is supported on Android. However apps may only run executables in certain locations, none of which are writable at runtime. Long-running subprocesses are officially discouraged, and are not guaranteed to be supported in future Android versions.

Android does provide a command-line shell, but this is intended only for use by developers, and is not available to the typical end user.

For these reasons, the recommended way of running Python on Android will be by loading libpython3.x.so into the main app process. A python3.x executable will not be officially supported on this platform.

Scope of work

The focus of this work will be to produce an Android equivalent to the existing Windows embeddable package, i.e. a set of compiled libraries which developers can add to their apps. No installer will be required.

Adding Android as a Tier 3 platform only requires adding support for compiling an Android-compatible build from the unpatched CPython source code. It does not necessarily require there to be any officially distributed Android artifacts on python.org, although these could be added in the future.

Android will be built using the same configure and Makefile system as other POSIX platforms, and must therefore be built on a POSIX platform. Both Linux and macOS will be supported.

A Gradle project will be provided for the purpose of running the CPython test suite. Tooling will be provided to automate the process of building the test suite app, starting the emulator, installing the test suite, and executing it.

Linkage

For the reasons discussed in App lifecycle, Python will be included in the app as a dynamic libpython3.x.so library which can be loaded into an app using dlopen.

Unlike Linux, Android does not implicitly use a dlopened library to resolve relocations in subsequently-loaded libraries, even if RTLD_GLOBAL is used. All Python extension modules must therefore be explicitly linked against libpython3.x.so when building for Android.

An extension module linked against libpython3.x.so cannot be loaded by an executable that has been statically linked against libpython3.x.a. Therefore, a static libpython3.x.a library will not be supported on Android. This is the same pattern used by CPython on Windows.

This approach also allows using the -Wl,--no-undefined option to detect missing symbols at build time, which can be a significant time-saver.

Unlike iOS, Android allows dynamic libraries to be loaded from any location, so a directory tree containing co-located .py, .pyc and .so files can be handled by Python’s standard importer.

Standard library

CI resources

Since Android emulators and physical devices use the same ABI, and come with identical or very similar operating system binaries, testing on emulators will be adequate. x86_64 emulators can be run on Linux, macOS or Windows, but ARM64 emulators are only supported on ARM64 Macs.

Anaconda has offered to provide physical hardware to run Android buildbots. These will include both Linux x86_64 and macOS ARM64 machines, which would cover both supported runtime architectures and both supported build platforms.

CPython does not currently test Tier 3 platforms on GitHub Actions, but if this ever changes, their Linux and macOS runners are also able to host Android emulators. macOS ARM64 runners have been free to all public repositories since January 2024.

Packaging

Android wheels will use tags in the format android_<api-level>_<abi>. For example:

• android_21_arm64_v8a
• android_21_x86_64

For the meaning of <api-level>, see OS versions. In the context of the wheel tag, it indicates the minimum Android version that was selected when the wheel was compiled. Installation tools such as pip should interpret this in a similar way to the existing macOS tags, i.e. an app with a minimum API level of N can incorporate wheels tagged with API level N or older.

This format originates from the Chaquopy project, which currently maintains a wheel repository with tags varying between API levels 16 and 21.

However, relying on a small group of Android enthusiasts to build the whole Python ecosystem is not a scalable solution. Until prominent libraries routinely release their own Android wheels, the ability of the community to adopt Python on Android will be limited.

Therefore, it will be necessary to clearly document how projects can add Android builds to their CI and release tooling. Adding Android support to tools like crossenv and cibuildwheel may be one way to achieve this.

The Android wheel tag format should also be added to the list of tags accepted by PyPI.

PEP 11 Update

PEP 11 will be updated to include the two supported Android ABIs. Autoconf already identifies them with the following triplets:

• aarch64-linux-android
• x86_64-linux-android

Petr Viktorin will serve as the initial core team contact for these ABIs.