@@ -58,7 +58,7 @@ Notes on availability
5858 operating system.
5959
6060* If not separately noted, all functions that claim "Availability: Unix" are
61- supported on macOS and iOS, both of which build on a Unix core.
61+ supported on macOS, iOS and Android, all of which build on a Unix core.
6262
6363* If an availability note contains both a minimum Kernel version and a minimum
6464 libc version, then both conditions must hold. For example a feature with note
@@ -120,43 +120,57 @@ DOM APIs as well as limited networking capabilities with JavaScript's
120120.. _Pyodide : https://pyodide.org/
121121.. _PyScript : https://pyscript.net/
122122
123+ .. _mobile-availability :
123124.. _iOS-availability :
124125
125- iOS
126- ---
126+ Mobile platforms
127+ ----------------
127128
128- iOS is , in most respects, a POSIX operating system . File I/O, socket handling,
129+ Android and iOS are , in most respects, POSIX operating systems . File I/O, socket handling,
129130and threading all behave as they would on any POSIX operating system. However,
130- there are several major differences between iOS and other POSIX systems.
131-
132- * iOS can only use Python in "embedded" mode. There is no Python REPL, and no
133- ability to execute binaries that are part of the normal Python developer
134- experience, such as :program: `pip `. To add Python code to your iOS app, you must use
135- the :ref: `Python embedding API <embedding >` to add a Python interpreter to an
136- iOS app created with Xcode. See the :ref: `iOS usage guide <using-ios >` for
137- more details.
138-
139- * An iOS app cannot use any form of subprocessing, background processing, or
140- inter-process communication. If an iOS app attempts to create a subprocess,
141- the process creating the subprocess will either lock up, or crash. An iOS app
142- has no visibility of other applications that are running, nor any ability to
143- communicate with other running applications, outside of the iOS-specific APIs
144- that exist for this purpose.
145-
146- * iOS apps have limited access to modify system resources (such as the system
131+ there are several major differences:
132+
133+ * Mobile platforms can only use Python in "embedded" mode. There is no Python
134+ REPL, and no ability to use separate executables such as :program: `python ` or
135+ :program: `pip `. To add Python code to your mobile app, you must use
136+ the :ref: `Python embedding API <embedding >`. For more details, see
137+ :ref: `using-android ` and :ref: `using-ios `.
138+
139+ * Subprocesses:
140+
141+ * On Android, creating subprocesses is possible but `officially unsupported
142+ <https://issuetracker.google.com/issues/128554619#comment4> `__.
143+ In particular, Android does not support any part of the System V IPC API,
144+ so :mod: `multiprocessing ` is not available.
145+
146+ * An iOS app cannot use any form of subprocessing, multiprocessing, or
147+ inter-process communication. If an iOS app attempts to create a subprocess,
148+ the process creating the subprocess will either lock up, or crash. An iOS app
149+ has no visibility of other applications that are running, nor any ability to
150+ communicate with other running applications, outside of the iOS-specific APIs
151+ that exist for this purpose.
152+
153+ * Mobile apps have limited access to modify system resources (such as the system
147154 clock). These resources will often be *readable *, but attempts to modify
148155 those resources will usually fail.
149156
150- * iOS apps have a limited concept of console input and output. ``stdout `` and
151- ``stderr `` *exist *, and content written to ``stdout `` and ``stderr `` will be
152- visible in logs when running in Xcode, but this content *won't * be recorded
153- in the system log. If a user who has installed your app provides their app
154- logs as a diagnostic aid, they will not include any detail written to
155- ``stdout `` or ``stderr ``.
157+ * Console input and output:
158+
159+ * On Android, the native ``stdout `` and ``stderr `` are not connected to
160+ anything, so Python installs its own streams which redirect messages to the
161+ system log. These can be seen under the tags ``python.stdout `` and
162+ ``python.stderr `` respectively.
163+
164+ * iOS apps have a limited concept of console output. ``stdout `` and
165+ ``stderr `` *exist *, and content written to ``stdout `` and ``stderr `` will be
166+ visible in logs when running in Xcode, but this content *won't * be recorded
167+ in the system log. If a user who has installed your app provides their app
168+ logs as a diagnostic aid, they will not include any detail written to
169+ ``stdout `` or ``stderr ``.
156170
157- iOS apps have no concept of ``stdin `` at all. While iOS apps can have a
158- keyboard, this is a software feature, not something that is attached to
159- ``stdin ``.
171+ * Mobile apps have no usable ``stdin `` at all. While apps can display an on-screen
172+ keyboard, this is a software feature, not something that is attached to
173+ ``stdin ``.
160174
161- As a result, Python library that involve console manipulation (such as
162- :mod: `curses ` and :mod: `readline `) are not available on iOS .
175+ As a result, Python modules that involve console manipulation (such as
176+ :mod: `curses ` and :mod: `readline `) are not available on mobile platforms .
0 commit comments