android: add platform.android_ver()

[xdegaye]

BPO	26855
Nosy	@malemburg, @vstinner, @pmp-p, @Fak3, @moreati, @yan12125
Files	platform.patch android_ver.patch android_ver.patch: Patch version 2 android_ver.patch: Patch version 3

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2016-04-26.13:18:31.861>
labels = ['3.7', 'type-feature', 'library', 'build']
title = 'android: add platform.android_ver()'
updated_at = <Date 2019-12-10.08:09:38.614>
user = 'https://github.com/xdegaye'

bugs.python.org fields:

activity = <Date 2019-12-10.08:09:38.614>
actor = 'xdegaye'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'Cross-Build']
creation = <Date 2016-04-26.13:18:31.861>
creator = 'xdegaye'
dependencies = []
files = ['42606', '42721', '42723', '42813']
hgrepos = []
issue_num = 26855
keywords = ['patch']
message_count = 23.0
messages = ['264277', '264317', '264369', '264373', '264374', '264376', '264377', '264852', '264854', '264856', '265145', '265294', '265307', '267409', '267413', '267415', '280147', '280166', '307662', '307667', '307672', '307685', '308040']
nosy_count = 6.0
nosy_names = ['lemburg', 'vstinner', 'pmpp', 'Roman.Evstifeev', 'Alex.Willmer', 'yan12125']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue26855'
versions = ['Python 3.7']

Linked PRs

• gh-71042: Add platform.android_ver #116674

[xdegaye]

The attached patch misses a test case.

Also how can we be sure that the '/system/build.prop' file may be guaranteed to exist on all android devices ?
It is difficult to get a reliable information on the android infrastructure when the information does not relate to the java libraries.

[yan12125]

Also how can we be sure that the '/system/build.prop' file may be guaranteed to exist on all android devices ?

This path is hard-coded in BioniC [1]. Though I can't find a document/relevant source codes to guarantee 'ro.build.version.release' and 'ro.build.version.sdk' is always in /system/build.prop

And the format of build.prop is not exactly INI. It supports 'import' clauses. See [2] and load_properties() function in [3]

Other options include calling getprop via subprocess or using C level function __system_property_get(). The first approach should always work. It's just somewhat tricky on Android 4.1 [4]. For the second option, a bad news is that it's a private API and was just removed from the latest NDK. Chromium has a workaround for that [5] and CPython may use similar approaches.

[1] https://android.googlesource.com/platform/bionic/+/master/libc/include/sys/_system_properties.h
[2] http://forum.xda-developers.com/android/general/explanation-build-prop-values-t3069341
[3] https://android.googlesource.com/platform/system/core/+/master/init/property_service.cpp
[4] rave-engine/python3-android#10 (comment)
[5] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-reviews/keQP6L9aVyU

[xdegaye]

The android/api-level.h header exists at all the android API levels and define __ANDROID_API__ as, for example at level 21:

 #define __ANDROID_API__ 21

So it is possible to get the sdk version from here, and maybe forget about the release version.

[yan12125]

Isn't this macro used in compile time? I thought android_ver() aims to check runtime versions.

[malemburg]

If the file is guaranteed to exist on most modern Android platforms, this sounds like a good approach.

Perhaps you could add support to fallback to running getprop instead, if the file doesn't exist or cannot be parsed ?!

[malemburg]

Some screenshots showing different file contents:

• http://www1-lw.xda-cdn.com/files/2013/12/tweak-your-samsung-galaxy-s3s-performance-with-these-build-prop-android-hacks.w654.jpg
• http://media.apcmag.com/wp-content/uploads/sites/20/2014/04/buildprop-text-file.jpg
• http://i.imgur.com/hZXQaX9.png

I think exposing codename and incremental may also make sense to get a complete picture.

ro.product also has a lot of useful entries which could be used for some of the other platform APIs such as uname().

[yan12125]

I have a WIP patch. [1] It's based on Shiz's patch [2].

[1] https://github.com/yan12125/python3-android/blob/cpython-hg/mk/python/android-misc.patch
[2] https://github.com/rave-engine/python3-android/blob/9bb6420317922c07df405315eea040f9301f7eca/mk/python/3.4.3/python-3.4.3-android-misc.patch

[yan12125]

Several questions on implementation:

1. Should Android 4.1 supported? If not pass_fds and logics for deriving it can be removed.
2. I can't find ro.build.version.full on any device/emulator I have access to. Maybe it should be removed due to low popularity?

Some related Android source codes, as my implementation basis:

1. Android 4.1's ANDROID_PROPERTY_WORKSPACE: https://android.googlesource.com/platform/bionic/+/android-4.1.1_r1/libc/bionic/system_properties.c#55
2. The Android Framework assumes property values to be valid UTF-8: https://android.googlesource.com/platform/frameworks/base/+/android-5.1.1_r37/core/jni/android_os_SystemProperties.cpp#49. In fact if I feed a malformed /system/build.prop to DalvikVM, it crashes [1]
3. Google's Android Compatibility Test Suite (CTS) [2] assumes getprop binary is in $PATH and can be executed: https://android.googlesource.com/platform/cts/+/android-5.1.1_r37/tests/tests/os/src/android/os/cts/BuildTest.java#110

[1] rave-engine/python3-android#10 (comment)
[2] https://source.android.com/compatibility/cts/

[malemburg]

On 04.05.2016 21:47, Chi Hsuan Yen wrote:

1. Should Android 4.1 supported? If not pass_fds and logics for deriving it can be removed.

According to http://www.droid-life.com/tag/distribution/ the Jelly
Bean versions (4.1, 4.2 and 4.3) still have a sizable market
share, so if it's not too much trouble, I think supporting 4.1 would
be a plus.

2. I can't find ro.build.version.full on any device/emulator I have access to. Maybe it should be removed due to low popularity?

Agreed.

[yan12125]

Version 2 attached. Removed ro.build.version.full.

[yan12125]

Android framework provides an SDK_INT field [1], which parses the value of ro.build.version.sdk and defaults to 0 if failed [2]. Should android_ver() return an integer for the sdk field, too? It simplifies the usage in bpo-26935 and similar ones.

[1] https://android.googlesource.com/platform/frameworks/base/+/e8579b12a3c5be5fef25fc5a1c8c2c9d43e49347/core/java/android/os/Build.java#183
[2] https://android.googlesource.com/platform/frameworks/base/+/e8579b12a3c5be5fef25fc5a1c8c2c9d43e49347/core/jni/android_os_SystemProperties.cpp#66

[xdegaye]

IMHO returning an integer for the sdk field would be better. The patch could use shutil.which() to avoid subprocess calls when getprop is not available. It would be better to use a 'try/except ValueError' clause instead of isdigit(). The OSError and UnicodeDecodeError exceptions should not be masked, as well as ValueError if sdk cannot be parsed as an int.