New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes Python for Android API 19 #76835
Comments
I'm working on a pull request to make https://github.com/pmp-p/droid-pydk/tree/master/sources.32/cpython-bpo-30386.patchset changes upstream. |
I wrote PR 5305 for Paul Peny who uses cheap devices (less than 50$, maybe less 20$? I'm not sure) for development, but these devices use old Android versions. It seems like some people are exchanging patches, in private or in public, for Android API 19. My intent is to make patches upstream, especially small patches which fix compilation of Python on Android API 19. I'm not sure that we should support API 19. Xavier de Gaye wants to focus on the future, support API 24 and newer: His document gives many good reasons to not support API < 24. My intent is not to "fully support" Python on Android API 19. Just to make sure that we can compile Python and that python3 -c pass doesn't crash :-) So only merge the most critical fixes for API 19. IMHO merging further changes to fix other Python functions should be discussed on a case by base basis. |
Here's another argument for supporting android < 21: according to Google [1], 12.8% devices on the world run android-19. Furthermore, upgrading Android OS for a device is almost impossible for non-hackers unless the manufacturer provides an image for newer Android, and it's common for manufacturers not upgrading a phone soon after its debut. |
I don't think we should be adding this platform-version-specific code unless we are going to fully support that particular platform and version. That means at a minimum adding a buildbot for it and then having a core developer signed up to maintain the platform version. It's not fair to other code developers and to downstream users to falsely imply that we support something that we are not set up to support, especially an already out-of-date version when we don't yet support any version of Android. We will end up with another support headache as has been the case with other non-mainstream (with regard to Python) platforms. |
Thanks ! I tested your PR it just built out of the box with the help of a one line change to Xavier de Gaye's android build support tool ( configure-android script + Android folder from bpo-30386 ). I'll forward to you the result of testsuite on a $10 Arm cortex-a7 board running Android kitkat 4.4.2 ( H3droid ) as soon as it finishes as i run a testbot on it. My point of view is that "out of date" doesn't mean people don't actually *use* it : vstinner is indeed right , vendors provides almost no updates for hardware which actually can live long and have the power of some low power i*&a* cpu but without the actual drawbacks we heard about recently. |
Agree with Ned Deily here. If CPython is going to be support android-19, it's better to fully support it. I'm optimistic here - I believe there won't be many android-19-specific patches beyond locale-related ones. Once android-24 is done, we can revisit this part and see how many patches are needed. |
Ned Deily: "I don't think we should be adding this platform-version-specific code unless we are going to fully support that particular platform and version." I know the theory and I know the practice :-) I started to list platforms that are "supported" by Python, with various support levels: For example, Linux has an excellent support, whereas OpenBSD is more on the "best effort" side. "grep OpenBSD" in CPython shows me at least 51 lines of code, whereas OpenBSD has no buildbot and no dedicated developer to handle OpenBSD specific issues. For example, test_crypt is broken since at least 2 years on OpenBSD, as many test_socket tests. For OpenBSD, IMHO it's ok to have a best effort support, basically apply proposed patches. For Android, the situation is somehow different. There are more and more people working on supporting officially Python on Android, like Xavier de Gaye and me who are core developers. Xavier is working on that for 2 years, and IMHO the port is done at 95%. The last part is just to setup a buildbot for Android API 24. The question is the added maintenance cost of Android API 19 #ifdef code, compared to pain of building Python on Android. Technically, it should be possible to setup a buildbot for Android API 19, but only with a subset of tests. Either explicitly only run a subset of tests on this hypothetic buildbot, or even modify the Python test suite to skip some tests on Android API 19. While I expect a few patches for fix Python compilation on Android API 19, I do expect a lot of @skipIf() in tests, since API 19 has many broken or missing features. The thing is that most people don't care of these missing or broken features, it's not an issue for most applications on Android. Note: Kivy is using Python on Android for years, but they use CrystaX NDK and not Google NDK. This issue is about supporting Google NDK: have the maximum compatibility. |
Another example of platform with best effort support is AIX. Until very recently, ctypes.util.find_library() didn't work on AIX which causes many tests failure. The AIX buildbot is red as far as I can remember. *Many* tests are failing on AIX for various reasons. While a few people sometimes propose fixes, basically the AIX support didn't evolved much last years in AIX... AIX is a platform with a buildbot, but no real dedicated developer to fix all AIX specific issues. |
By the way, I started to take notes on Python on Android, since the topic is wide and complex: |
Here are some ideas after testing:
>>> locale.setlocale(locale.LC_ALL, None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/data/local/tmp/python3/usr/lib/python3.7/locale.py", line 608, in setlocale
return _setlocale(category, locale)
locale.Error: locale query failed
#if defined(__USE_FILE_OFFSET64)
#if __ANDROID_API__ >= 21
ssize_t sendfile(int __out_fd, int __in_fd, off_t* __offset, size_t __count) __RENAME(sendfile64) __INTRODUCED_IN(21);
#endif /* __ANDROID_API__ >= 21 */ #else #if __ANDROID_API__ >= 21
ssize_t sendfile64(int __out_fd, int __in_fd, off64_t* __offset, size_t __count) __INTRODUCED_IN(21);
#endif /* __ANDROID_API__ >= 21 */ __USE_FILE_OFFSET64 is defined as _FILE_OFFSET_BITS is defined to 64 in pyconfig.h. An NDK developer suggest "stop defining _FILE_OFFSET_BITS=64 on 32-bit Android." (android/ndk#536 (comment)) Either disabling large file support on Android or simply don't define _FILE_OFFSET_BITS on Android should work. (Android does not use _LARGEFILE_SOURCE)
|
@yan12125
my thoughts :
unclear if unrelated to this:
Thanks Victor for trying to clean my patchset : i did not realize my embed use of libpython could help official cpython too. Anyway I would be glad to help this way or another. |
Since we won't officially support Android in 3.7, these changes should wait for 3.8 and until there is a PEP for Android support. |
"""
>>> locale.setlocale(locale.LC_ALL, None)
...
locale.Error: locale query failed
""" IMHO the correct fix here is to not define _locale.setlocale() to get the pure Python locale.setlocale() emulation. |
I'm sorry, but I'm not longer interested to work on supporting Android API 19. I close the bug. If someone wants to continue to work on the Android support, it's probably better to first focus on most recent Android versions. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: