Android defines SO_REUSEPORT on android API 21 but setting this option in the asyncio tests raises OSError: [Errno 92] Protocol not available.

The attached patch assumes there is a platform.android_ver() function to detect that this is the android platform. The patch does not take into account the fact that this may be fixed in future versions of android.

Where is the patch that adds android_ver()? At the very least that should be listed as a dependency here.

I don't very much like to have changes to asyncio that can only work in Python 3.6; there's still an upstream version (https://github.com/python/asyncio) that is used to do PyPI releases of asyncio for Python 3.3. I try to keep that in sync with the stdlib on all platforms, otherwise figuring out whether any changes need to be packported is a nightmare.

You might also update the comment somewhere that currently states that reuse_port is not supported on Windows.

PS. It amuses me that each platform apparently has a different way to check (there are three different types of platform checks in the lines you change).

Where is the patch that adds android_ver()?

http://bugs.python.org/issue26855

Xavier de Gaye's implementation is buggy while works for most cases.

The patch was not intended to be proposed as a way to fix this problem, but as an indication of what the problem is. This issue is a dependency of issue bpo-26865: Meta-issue: support of the android platform.

I should have posted instead the result of running 'python -m test -v test_asyncio' on an android emulator running an x86 system image at API level 21, which is:

======================================================================
ERROR: test_create_datagram_endpoint_sockopts (test.test_asyncio.test_base_events.BaseEventLoopWithS
electorTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_base_events.py", line 1506,
 in test_create_datagram_endpoint_sockopts
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.EPollEventLoopTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_events.py", line 830, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_events.py", line 830, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_events.py", line 830, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

Ran 991 tests in 16.528s

FAILED (errors=4, skipped=2)
test test_asyncio failed
1 test failed:
test_asyncio
Total duration: 0:00:18

OK, I'll wait until Android support is closer. Do you have a core dev who's mentoring/reviewing here?

Stefan has already commited and closed some of the issues listed at issue bpo-26865. Martin has closed issue bpo-22359, a blocker for the cross-compilation of python.

I will enter an issue for all the failures listed at https://bitbucket.org/xdegaye/pyona/wiki/testsuite and add them to the list in the android meta-issue.

If there are a lot of Android issue maybe you could get a tracker manager
to add a new keyword or category or whatever?

Running the "Search" button on the tracker with "Components" set as "Cross-Build" lists 42 issues (20 in the last year).

I guess using this existing category is fine if the titles' issues are prefixed with "android:".

Should use boolean 'is_android' being added to module test.support by issue bpo-27027, instead of platform.android_ver()[0].

New patch test.asyncio_2.patch uses test.support.is_android and adds a dependency to issue bpo-27027.

This issue was fixed in bpo-28174.

The changes made in issue bpo-28174 fix the problem for the Android x86 platform and for the armv7 platform at Android API level 24, but the problem is still there on the armv7 platform at Android API level 21.

======================================================================
ERROR: test_create_datagram_endpoint_sockopts (test.test_asyncio.test_base_events.BaseEventLoopWithS
electorTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_asyncio/test_base_events.py", line 1593,
 in test_create_datagram_endpoint_sockopts
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.EPollEventLoopTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_asyncio/test_events.py", line 913, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_asyncio/test_events.py", line 913, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_asyncio/test_events.py", line 913, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

Ran 1476 tests in 382.973s

FAILED (errors=4, skipped=2)
test test_asyncio failed
test_asyncio failed in 7 min 25 sec

1 test failed:
test_asyncio

Total duration: 7 min 27 sec
Tests result: FAILURE

IMHO it's ok to skip a few asyncio tests on Android. It's safe if it doesn't touch the code of asyncio itself.

It don't really care if the Android version is not checked yet. Moreover, if we really want to check the version, we should check the *runtime* verison, not the *build* version of Android. We need the discussed platform.android_ver() function which doesn't exist yet. So it's fine to postpone the version check in asyncio tests.

Skipping those tests on Android has already been proposed with the existing patches in this issue.
The reason why the changes made by bpo-28174 fix only partly the problem should be understood.

The reason why the changes made by bpo-28174 fix only partly the problem should be understood.

The change c1c247cf3488 catchs OSError on sock.setsockopt() in asyncio/base_events.py, whereas the test fails while calling sock.getsockopt() in test_asyncio/tets_events.py. Extract of the test:

    def test_create_server_reuse_port(self):
        proto = MyProto(self.loop)
        f = self.loop.create_server(
            lambda: proto, '0.0.0.0', 0)
        server = self.loop.run_until_complete(f)
        self.assertEqual(len(server.sockets), 1)
        sock = server.sockets[0]
        self.assertFalse(
            sock.getsockopt(
                socket.SOL_SOCKET, socket.SO_REUSEPORT))
        server.close()

The change c1c247cf3488 doesn't touch the code of this unit test.

test_base_events.py also calls directly sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT).

Note that this isn't an android specific issue: See bpo-19901, and 9791c5d55f52 for an appropriate solution patch.

(Renaming title)

Can't you just submit a PR? It's so easy now!

Philip, 9791c5d55f52 was commited in november 2013 and bpo-19901 was closed in december 2013, so how can they be an appropriate solution for a problem reported on 2017-01-13 in msg285392 ?

I assume he means that a similar piece of code should be inserted elsewhere. I am still waiting for Philip's PR though.

This problem does not occur at API 24.

Do we have a function in Python to get the running Android version?

This is bpo-26855.

Closing as android is not supported, if you want to work on this, then create a new issue targeting main branch and the patch would have to be PRs.

So are we now going to close all issues listed in #71052 as “Android not supported”? That seems backwards, since the (laudable) goal is to support Android.

So are we now going to close all issues listed in #71052 as “Android not supported”? That seems backwards, since the (laudable) goal is to support Android.

No atleast I won't, I only close issue which have old patches and no comments in last 2~3 years and patch does not apply cleanly and platform is unsupported. I try patch before closing.

error: patch failed: Lib/test/test_asyncio/test_base_events.py:1505
error: Lib/test/test_asyncio/test_base_events.py: patch does not apply
error: patch failed: Doc/library/asyncio-eventloop.rst:345
error: Doc/library/asyncio-eventloop.rst: patch does not apply

If anyone wants to port CPython to other platforms then IMO they should target main branch and land patches in form of PRs otherwise the old patches would conflicts and get out of date.

Okay, just making clear what you're doing. That sounds like a reasonable process.

Closing dangling issues is really not a problem if at least a specifig tag ( aosp? ) is added to those, so people that may have time to work on can find them easy.
( i think i could but i'm not triager )