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

Guido van Rossum guido at python.org
Sun Aug 3 06:41:42 CEST 2014

Well, it really does look like checking for the presence of those ANDROID_*
environment variables it the best way to recognize the Android platform.
Anyone can do that without waiting for a ruling on whether Android is Linux
or not (which would be necessary because the docs for sys.platform are
quite clear about its value on Linux systems). Googling terms like "is
Android Linux" suggests that there is considerable controversy about the
issue, so I suggest you don't wait. :-)

On Sat, Aug 2, 2014 at 3:49 PM, Shiz <hi at shiz.me> wrote:

> 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,
> Shiz
> [1]: http://bugs.python.org/issue1322#msg207427
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> yCexTCEwu1rApjGYWSUw92Ihr9LnWn4aL7tEBqGXHN5pDctw0/FlGH9d0WhpMz/b
> DN0w5ukqx2YyY1EDK7hp1//6eU+tXTGQu890CWgboj5OQF8LXFyN6ReG0ynAKFC7
> gSyYGunqCIInRdnz9IRXWgQ91F/d1D3hZq9ZNffZzacA+PIA1rPdgziUuLdThl14
> P2/o98DzLRa3iTrTeW+x8f7nfbfNFmO8BLJsrce0o50BlD75YsUKVeTlwjU9IuIC
> gbw5Cxo8cfBN9Eg7iLkMgxkwiEVspuLVcVmoNVL4zsuavj41jlmyZFmPvRMO7OK+
> NQMq5vGPub7q4lBtlk7a8gFqDJQad7fcEgsCFTIb0nvckkEi1EeLC9kyzmVEqi3C
> ngiXGVfjM0qpwLKvY+pr5adsoeJSK3dVzIfEXptsvHvOhav6oxG9nCdbe3uW2ROT
> hM444FSqngUabceRe395TXu2XhXcpDNcl8Ye1ADfMZdiWFYRp8/xtNVKoWZ7Ge6D
> Gcx3/QiUtXP7jvykE9GI7QGB6JKCFuBY/RloDS7miteCutl7k0GLcp3+tRmtoypi
> jL3lcCtUSNOMEX4Y5CqfhMcjEVccWvy98oM4Tz7qMdYv5OwASNDAzjRFh3SbRXI+
> WRVqBf5aF13hy37RbkgoweXh1qn2vBO9sUUTJFp5ymlz8WisQFr+KRnt5bcjCKAe
> ycVThHQaLE/j1JOSgOmbD0Xi4hcvfFvlaNEmXTL1TiWRDC0crhM9fqObHHhWlFHv
> +b6AO39vVSfz1nTxTIByr6Z3GHlTFaU6iUx9oixHModEg2ej9iXb1Hq8atMHv/Z1
> thP/sZ7mRRBhakQPoL9i8+5+AIEiFnw5GnW7w74N/cRalF5SB2RpzDAudv2UHMWQ
> jPpVrDbDv9BAUeZKF/hl1xCpbI3xR1zhpLP6d7kH7p9fDAcS07W2hYIkX1LCyTvx
> xn0XHQKEejaAZG1HwYE/0aP1Z39SJhODZx1rFjWtgE3q1akO9hfadpRiRVhozsUT
> r/cXoJN3sakPbctN7B4wMXtSTrVrwqdfPCuua6mG15uTGVbkPFze/vj4yc0b+sql
> GnrxeiWmJXE/DkpyTbEXUPyCm95ggm+TUfUJ/yb/GhdL1yU9xCjVcxuFmAo5s0WH
> k4tra8/vU21V8OzxPmK0eGH9Sl4fUg7JsmAC/Igez+utO7lJLXwfPnUSz+Ls30ao
> Xd28IYMsoQ1LCltmfN/fDl3uWJi2e/kZM9v/KTkj9AncvUsDLIOV80AP+remM9E=
> =Z0j+

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140802/8c9aeafd/attachment-0001.html>

More information about the Python-Dev mailing list