[Python-Dev] Exposing the Android platform existence to Python modules

Shiz hi at shiz.me
Sun Aug 3 00:49:00 CEST 2014

Hash: SHA512

Guido van Rossum wrote:
> Can you give a few examples of where you'd need to differentiate
> Android from other Linux platforms in otherwise portable code, and
> where testing for the presence or absence of the specific function
> that you'd like to call isn't possible? I know I pretty much never
> test for the difference between OSX and other UNIX variants
> (including Linux) -- the only platform distinction that regularly
> comes up in my own code is Windows vs. the rest. And even there,
> often the right thing to test for is something more specific like
> os.sep.

> What's the specific change in stdlib behavior that you're proposing
> for Android?

The most obvious change would be to subprocess.Popen(). The reason a
generic approach there won't work is also the reason I expect more
changes might be needed: the Android file system doesn't abide by any
POSIX file system standards. Its shell isn't located at /bin/sh, but at
/system/bin/sh. The only directories it provides that are POSIX-standard
are /dev and /etc, to my knowledge. You could check to see if
/system/bin/sh exists and use that first, but that would break the
preferred shell on POSIX systems that happen to have /system for some
reason or another. In short: the preferred shell on POSIX systems is
/bin/sh, but on Android it's /system/bin/sh. Simple existence checking
might break the preferred shell on either. For more specific stdlib
examples I'd have to check the test suite again.

I can see the point of a sys.platform change not necessarily being
needed, but it would nice for user code too to have a sort-of trivial
way to figure out if it's running on Android. While core CPython might
in general care far less, for user applications it's a bigger deal since
they have to draw GUIs and use system services in a way that *is*
usually very different on Android. Again, platform.linux_distribution()
seems more for display purposes than for applications to check their
core logic against.
In addition, apparently platform.linux_distribution() is getting
deprecated in 3.5 and removed in 3.6[1].

I agree that above issue should in fact be solved by the earlier-linked
to os.get_preferred_shell() approach, however.

> However, since it's a stdlib module you could easily rely on a
> private API to detect Android, so this doesn't really force the
> sys.platform issue. (Or you could propose a fix that will work for
> Kivi and SL4A as well, e.g. checking for some system file that is
> documented as unique to Android.)

After checking most of the entire Android file system, I'm not sure if
such a file exists. Sure, a lot of the Android file system hierarchy
isn't really used anywhere else, but I'm not sure a check to see if e.g.
/system exists is really enough to conclude Python is running on Android
on its own. The thing that gets closest (which is the thing my
platform.py patch checks for) is several Android-specific environment
variables being defined (ANDROID_ROOT, ANDROID_DATA,
ANDROID_PROPERTY_WORKSPACE...). Wouldn't it be better to put this in the
standard Python library and expose it somehow, though? It *is* fragile
code, it seems better if applications could 'just rely' on Python to
figure it out, since it's not a trivial check.

Kind regards,

[1]: http://bugs.python.org/issue1322#msg207427
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Python-Dev mailing list