PEP 738: Adding Android as a supported platform

PEPs
9

Hi, Kivy Core Dev here!

I’m glad to see that the Python community is already working on the Android counterpart of PEP 730 (that I fanboyed at PyConSE last month :sweat_smile:, like a child that sees the Xmas present he long-awaited).

Back to this PEP, I re-read it twice and there are just a couple of proposals that I feel can be beveled before these changes can potentially impact our fellow Pythonistas that maintain apps Python apps on Android in specific environments, where looking in the long term is a must.

I’m the kind of dev who tries to remove the additional burden when possible, so I would be happy to simplify things, but if I look at the scenario from a user (and management) perspective things change quite fast.

I’m not involved in any of these scenarios (happily), but I’m aware of Kivy users who still have to maintain compatibility on old devices and Android versions. (And the same happens for “native” Android devs)

So …

For Python 3.13 we propose the minimum Android version to be 6.0 (API level 23). This would support 98% of active devices, and would allow us to rely on a number of dynamic linker improvements which simplify the use of dynamic libraries.

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

That’s (almost) true if we talk about phones and tablets that the majority of the population have in their hands, pockets, or backpacks, but that does not apply to Android devices that we use every day without knowing these devices are powered by Android (and Android apps).

As an example:

  • EV charger stations
  • Payment terminals
  • VOIP phones
  • Self-service machines
  • Smart Home screens
  • … and many more

All these devices have a longer lifespan, compared to smartphones and tablets (that we usually change every ~4 years), and when they get provisioned for the first time, the hardware and the Android version are usually already obsolete.

Why? (in order of importance):

  • Availability
  • Costs
  • Bad management decisions

What I’m proposing:

  • For the minimum API version, let’s stick to the one the latest NDK LTS supports. (21 ATM)
  • For the supported platforms, let’s stick to the ones that the latest NDK LTS supports. (arm64-v8a , armeabi-v7a, x86_64, x86)
  • At every Python release, check if a new NDK LTS version has been released, and let’s increase the minimum supported API version, and if needed change the supported platforms accordingly).

How we can test 32-bit variants?

64-bit devices also support their 32-bit variants. Using arm64-v8a devices as an example, the device can also run armeabi and armeabi-v7a code.

So, we can produce armeabi-v7a artifacts, and run them on arm64-v8a, and the same applies to x86 artifacts on x86_64.

In years of maintaining the python-for-android toolchain, I did not see anything blocking maintaining armeabi-v7a and x86 artifacts. Usually, when a recipe is correctly written for arm64-v8a, that also works for the other variants.

3 Likes