Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Cambios en el comportamiento: apps orientadas a Android 16 o versiones posteriores

Al igual que las versiones anteriores, Android 16 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 16 o versiones posteriores. Si tu app está orientada a Android 16 o versiones posteriores, debes modificarla para que admita estos comportamientos, cuando corresponda.

Asegúrate de revisar también la lista de cambios en el comportamiento que afectan a todas las apps que se ejecutan en Android 16, independientemente de targetSdkVersion de la app.

Experiencia del usuario y la IU del sistema

Android 16 (nivel de API 36) incluye los siguientes cambios que tienen como objetivo crear una experiencia del usuario más coherente e intuitiva.

Se quita la inhabilitación de borde a borde

Android 15 aplicó el diseño de borde a borde para las apps orientadas a Android 15 (nivel de API 35), pero tu app podía inhabilitarlo configurando R.attr#windowOptOutEdgeToEdgeEnforcement como true. En el caso de las apps orientadas a Android 16 (nivel de API 36), R.attr#windowOptOutEdgeToEdgeEnforcement dejó de estar disponible y se inhabilitó, y tu app no puede inhabilitar el diseño de borde a borde.

Si tu app está orientada a Android 16 (nivel de API 36) y se ejecuta en un dispositivo Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement sigue funcionando.
Si tu app está orientada a Android 16 (nivel de API 36) y se ejecuta en un dispositivo Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement está inhabilitado.

Para realizar pruebas en Android 16, asegúrate de que tu app admita el diseño de borde a borde y quita cualquier uso de R.attr#windowOptOutEdgeToEdgeEnforcement para que tu app también admita el diseño de borde a borde en un dispositivo Android 15. Para admitir el diseño de borde a borde, consulta la guía de Compose y Views.

Se requiere migración o inhabilitación para el botón Atrás predictivo

En el caso de las apps que se segmentan para Android 16 (nivel de API 36) o versiones posteriores y que se ejecutan en un dispositivo con Android 16 o una versión posterior, las animaciones del sistema de atrás predictivo (volver a la pantalla principal, entre tareas y entre actividades) están habilitadas de forma predeterminada. Además, no se llama a onBackPressed y ya no se envía KeyEvent.KEYCODE_BACK.

Si tu app intercepta el evento de atrás y aún no migraste al gesto atrás predictivo, actualiza tu app para que use las APIs de navegación hacia atrás compatibles o inhabilita temporalmente la función configurando el atributo android:enableOnBackInvokedCallback como false en la etiqueta <application> o <activity> del archivo AndroidManifest.xml de tu app.

La animación de atrás predictivo para volver a la pantalla principal.

Animación predictiva de cambio de actividad.

La animación predictiva entre tareas.

APIs de fuentes elegantes obsoletas e inhabilitadas

Las apps segmentadas para Android 15 (nivel de API 35) tienen el atributo elegantTextHeight TextView establecido en true de forma predeterminada, lo que reemplaza la fuente compacta por una que es mucho más legible. Puedes anular este comportamiento si estableces el atributo elegantTextHeight en false.

Android 16 dejó de admitir el atributo elegantTextHeight, y se ignorará una vez que tu app se oriente a Android 16. Las "fuentes de IU" controladas por estas APIs se descontinuarán, por lo que debes adaptar los diseños para garantizar una renderización de texto coherente y a prueba de futuro en árabe, laosiano, birmano, tamil, gujarati, kannada, malayalam, odia, telugu o tailandés.

`elegantTextHeight` para las apps que se segmentan para Android 14 (nivel de API 34) y versiones anteriores, o para las apps que se segmentan para Android 15 (nivel de API 35) que anularon el valor predeterminado estableciendo el atributo `elegantTextHeight` en `false`.

`elegantTextHeight` para las apps que se segmentan para Android 16 (nivel de API 36) o para las apps que se segmentan para Android 15 (nivel de API 35) que no anularon el valor predeterminado estableciendo el atributo `elegantTextHeight` en `false`.

Funcionalidad principal

Android 16 (nivel de API 36) incluye los siguientes cambios que modifican o expanden varias capacidades principales del sistema Android.

Optimización de la programación de trabajo de tasa fija

Antes de orientarse a Android 16, cuando scheduleAtFixedRate omitía la ejecución de una tarea debido a que estaba fuera de un ciclo de vida del proceso válido, todas las ejecuciones omitidas se ejecutaban de inmediato cuando la app regresaba a un ciclo de vida válido.

Cuando se orienta a Android 16, se ejecuta de inmediato una ejecución perdida de scheduleAtFixedRate cuando la app vuelve a un ciclo de vida válido. Se espera que este cambio de comportamiento mejore el rendimiento de la app. Prueba este comportamiento en tu app para verificar si se ve afectada. También puedes realizar pruebas con el marco de compatibilidad de apps y habilitar la marca de compatibilidad STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Factores de forma del dispositivo

Android 16 (nivel de API 36) incluye los siguientes cambios para las apps cuando se muestran en dispositivos de pantalla grande.

Diseños adaptables

Ahora que las apps para Android se ejecutan en una variedad de dispositivos (como teléfonos, tablets, plegables, computadoras de escritorio, automóviles y TVs) y modos de ventanas en pantallas grandes (como pantalla dividida y modo de ventanas de escritorio), los desarrolladores deben crear apps para Android que se adapten a cualquier tamaño de pantalla y ventana, independientemente de la orientación del dispositivo. Los paradigmas como la restricción de la orientación y el cambio de tamaño son demasiado restrictivos en el mundo actual de múltiples dispositivos.

Ignora las restricciones de orientación, cambio de tamaño y relación de aspecto

En el caso de las apps que se segmentan para Android 16 (nivel de API 36), las restricciones de orientación, cambio de tamaño y relación de aspecto ya no se aplican en pantallas con un ancho más pequeño >= 600 dp. Las apps ocupan toda la ventana de visualización, independientemente de la relación de aspecto o la orientación preferida del usuario, y no se usa el formato pillarbox.

Este cambio introduce un nuevo comportamiento estándar de la plataforma. Android se está moviendo hacia un modelo en el que se espera que las apps se adapten a varias orientaciones, tamaños de pantalla y relaciones de aspecto. Las restricciones, como la orientación fija o la capacidad de cambio de tamaño limitada, dificultan la adaptabilidad de la app. Haz que tu app sea adaptable para brindar la mejor experiencia del usuario posible.

También puedes probar este comportamiento con el marco de compatibilidad de apps y habilitar la marca de compatibilidad UNIVERSAL_RESIZABLE_BY_DEFAULT.

Cambios rotundos comunes

Ignorar las restricciones de orientación, cambio de tamaño y relación de aspecto podría afectar la IU de tu app en algunos dispositivos, en especial los elementos diseñados para diseños pequeños bloqueados en orientación vertical, por ejemplo, problemas como diseños estirados y animaciones y componentes fuera de la pantalla. Cualquier suposición sobre la relación de aspecto o la orientación puede causar problemas visuales en tu app. Obtén más información para evitarlos y mejorar el comportamiento adaptable de tu app.

Permitir la rotación del dispositivo genera más recreaciones de actividades, lo que puede provocar la pérdida del estado del usuario si no se conserva correctamente. Obtén información para guardar correctamente el estado de la IU en Cómo guardar estados de la IU.

Detalles de la implementación

Los siguientes atributos del manifiesto y APIs de tiempo de ejecución se ignoran en los dispositivos de pantalla grande en los modos de pantalla completa y multiventana:

Se ignoran los siguientes valores de screenOrientation, setRequestedOrientation() y getRequestedOrientation():

portrait
reversePortrait
sensorPortrait
userPortrait
landscape
reverseLandscape
sensorLandscape
userLandscape

En cuanto al cambio de tamaño de la pantalla, android:resizeableActivity="false", android:minAspectRatio y android:maxAspectRatio no tienen efecto.

En el caso de las apps que se segmentan para Android 16 (nivel de API 36), las restricciones de orientación, cambio de tamaño y relación de aspecto de la app se ignoran de forma predeterminada en pantallas grandes, pero todas las apps que no estén completamente listas pueden anular temporalmente este comportamiento inhabilitando la opción (lo que genera el comportamiento anterior de colocarse en modo de compatibilidad).

Excepciones

Las restricciones de orientación, cambio de tamaño y relación de aspecto de Android 16 no se aplican en las siguientes situaciones:

Juegos (según la marca android:appCategory)
Usuarios que habilitan explícitamente el comportamiento predeterminado de la app en la configuración de relación de aspecto del dispositivo
Pantallas más pequeñas que sw600dp

Inhabilitar temporalmente

Para inhabilitar una actividad específica, declara la propiedad del manifiesto PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

Si demasiadas partes de tu app no están listas para Android 16, puedes inhabilitar la opción por completo aplicando la misma propiedad a nivel de la aplicación:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Salud y fitness

Android 16 (nivel de API 36) incluye los siguientes cambios relacionados con los datos de actividad física.

Permisos de salud y fitness

En el caso de las apps que se orientan a Android 16 (nivel de API 36) o versiones posteriores, los permisos de BODY_SENSORS usan permisos más detallados en android.permissions.health, que también usa Health Connect. A partir de Android 16, cualquier API que antes requería BODY_SENSORS o BODY_SENSORS_BACKGROUND requiere el permiso android.permissions.health correspondiente. Esto afecta los siguientes tipos de datos, APIs y tipos de servicios en primer plano:

HEART_RATE_BPM de los Servicios de salud en Wear OS
Sensor.TYPE_HEART_RATE del Administrador de sensores de Android
heartRateAccuracy y heartRateBpm de ProtoLayout en Wear OS
FOREGROUND_SERVICE_TYPE_HEALTH , en el que se necesita el permiso android.permission.health respectivo en lugar de BODY_SENSORS

Si tu app usa estas APIs, debe solicitar los permisos detallados respectivos:

Para el monitoreo en uso de la frecuencia cardíaca, la SpO2 o la temperatura cutánea, solicita el permiso específico en android.permissions.health, como READ_HEART_RATE en lugar de BODY_SENSORS.
Para el acceso al sensor en segundo plano, solicita READ_HEALTH_DATA_IN_BACKGROUND en lugar de BODY_SENSORS_BACKGROUND.

Estos permisos son los mismos que protegen el acceso a la lectura de datos de Health Connect, el almacén de datos de Android para datos de salud, fitness y bienestar.

Apps para dispositivos móviles

Las apps para dispositivos móviles que migren para usar READ_HEART_RATE y otros permisos específicos también deben declarar una actividad para mostrar la política de privacidad de la app. Este es el mismo requisito que Health Connect.

Conectividad

Android 16 (nivel de API 36) incluye los siguientes cambios en la pila de Bluetooth para mejorar la conectividad con dispositivos periféricos.

Nuevos intents para controlar la pérdida de vinculación y los cambios de encriptación

Como parte de la manejo mejorado de la pérdida de vínculo, Android 16 también presenta 2 intents nuevos para proporcionar a las apps una mayor conciencia de la pérdida de vínculo y los cambios de encriptación.

Las apps orientadas a Android 16 ahora pueden hacer lo siguiente:

Recibir un intent ACTION_KEY_MISSING cuando se detecta la pérdida de la vinculación remota, lo que les permite proporcionar comentarios más informativos a los usuarios y tomar las medidas adecuadas
Recibir un intent ACTION_ENCRYPTION_CHANGE cada vez que cambie el estado de encriptación del vínculo Esto incluye el cambio de estado de encriptación, el cambio de algoritmo de encriptación y el cambio de tamaño de la clave de encriptación. Las apps deben considerar que la vinculación se restableció si el vínculo se encripta correctamente cuando se recibe el intent ACTION_ENCRYPTION_CHANGE más adelante.

Adaptación a diferentes implementaciones de OEM

Si bien Android 16 presenta estos intents nuevos, su implementación y transmisión pueden variar según los diferentes fabricantes de dispositivos (OEM). Para garantizar que tu app proporcione una experiencia coherente y confiable en todos los dispositivos, los desarrolladores deben diseñar su control de pérdida de vínculo para que se adapte de forma fluida a estas posibles variaciones.

Recomendamos los siguientes comportamientos de las apps:

Si se transmite el intent ACTION_KEY_MISSING, sucede lo siguiente:

El sistema desconectará el vínculo de ACL (conexión asíncrona sin conexión), pero se conservará la información de vinculación del dispositivo (como se describe aquí).

Tu app debe usar este intent como el indicador principal para la detección de pérdida de vinculación y guiar al usuario para que confirme que el dispositivo remoto está dentro del alcance antes de iniciar el olvido del dispositivo o la vinculación nuevamente.

Si un dispositivo se desconecta después de recibir ACTION_KEY_MISSING, tu app debe tener cuidado al volver a conectarse, ya que es posible que el dispositivo ya no esté vinculado con el sistema.
Si NO se transmite el intent ACTION_KEY_MISSING, haz lo siguiente:

El vínculo de ACL permanecerá conectado, y el sistema quitará la información de vinculación del dispositivo, al igual que en Android 15.

En esta situación, tu app debe continuar con sus mecanismos existentes de control de pérdida de vinculación, como en versiones anteriores de Android, para detectar y administrar eventos de pérdida de vinculación.

Nueva forma de quitar la vinculación de Bluetooth

Todas las apps que se orientan a Android 16 ahora pueden desvincular dispositivos Bluetooth con una API pública en CompanionDeviceManager. Si un dispositivo complementario se administra como una asociación de CDM, la app puede activar la eliminación de la vinculación Bluetooth con la nueva API de removeBond(int) en el dispositivo asociado. La app puede supervisar los cambios de estado de vinculación escuchando el evento de transmisión del dispositivo Bluetooth ACTION_BOND_STATE_CHANGED.

Seguridad

Android 16 (nivel de API 36) incluye los siguientes cambios de seguridad.

Bloqueo de la versión de MediaStore

En el caso de las apps orientadas a Android 16 o versiones posteriores, MediaStore#getVersion() ahora será único para cada app. Esto elimina las propiedades de identificación de la cadena de versión para evitar el abuso y el uso de técnicas de creación de huellas digitales. Las apps no deben hacer suposiciones sobre el formato de esta versión. Las apps ya deberían controlar los cambios de versión cuando usan esta API y, en la mayoría de los casos, no deberían necesitar cambiar su comportamiento actual, a menos que el desarrollador haya intentado inferir información adicional que esté más allá del alcance previsto de esta API.

Intents más seguros

La función Safer Intents es una iniciativa de seguridad de varias fases diseñada para mejorar la seguridad del mecanismo de resolución de intents de Android. El objetivo es proteger las apps de acciones maliciosas agregando verificaciones durante el procesamiento de intents y filtrando los intents que no cumplen con criterios específicos.

En Android 15, la función se enfocó en la app de envío. Ahora, con Android 16, el control se traslada a la app de recepción, lo que permite que los desarrolladores habiliten la resolución estricta de intents con el manifiesto de su app.

Se implementarán dos cambios clave:

Los intents explícitos deben coincidir con el filtro de intents del componente de destino: Si un intent segmenta explícitamente un componente, debe coincidir con el filtro de intents de ese componente.
Los intents sin una acción no pueden coincidir con ningún filtro de intents: Los intents que no tienen una acción especificada no deben resolverse en ningún filtro de intents.

Estos cambios solo se aplican cuando hay varias apps involucradas y no afectan el control de intents dentro de una sola app.

Impacto

La naturaleza de la habilitación significa que los desarrolladores deben habilitarla explícitamente en el manifiesto de su app para que surta efecto. Como resultado, el impacto de la función se limitará a las apps cuyos desarrolladores cumplan con los siguientes requisitos:

Conocer la función Safer Intents y sus beneficios
Eligen de forma activa incorporar prácticas más estrictas de control de intents en sus apps.

Este enfoque de habilitación minimiza el riesgo de interrumpir apps existentes que pueden depender del comportamiento actual de resolución de intents menos seguro.

Si bien el impacto inicial en Android 16 puede ser limitado, la iniciativa Safer Intents tiene una hoja de ruta para lograr un impacto más amplio en futuras versiones de Android. El plan es que, con el tiempo, la resolución estricta de la intención sea el comportamiento predeterminado.

La función Safer Intents tiene el potencial de mejorar significativamente la seguridad del ecosistema de Android, ya que dificulta que las apps maliciosas exploten vulnerabilidades en el mecanismo de resolución de intents.

Sin embargo, la transición a la exclusión voluntaria y la aplicación obligatoria deben administrarse con cuidado para abordar posibles problemas de compatibilidad con las apps existentes.

Implementación

Los desarrolladores deben habilitar explícitamente la coincidencia de intents más estricta con el atributo intentMatchingFlags en el manifiesto de su app. Este es un ejemplo en el que la función es opcional para toda la app, pero está inhabilitada o rechazada en un receptor:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

Más información sobre las marcas compatibles:

Nombre de la marca	Descripción
enforceIntentFilter	Aplica una coincidencia más estricta para los intents entrantes
ninguno	Inhabilita todas las reglas especiales de coincidencia para las intents entrantes. Cuando se especifican varias marcas, los valores en conflicto se resuelven dando prioridad a la marca "none".
allowNullAction	Relaja las reglas de coincidencia para permitir que coincidan las intents sin una acción. Esta marca se debe usar junto con "enforceIntentFilter" para lograr un comportamiento específico.

Pruebas y depuración

Cuando la aplicación de la política esté activa, las apps deberían funcionar correctamente si el llamador del intent completó el intent de forma adecuada. Sin embargo, las intents bloqueadas activarán mensajes de registro de advertencia, como "Intent does not match component's intent filter:" y "Access blocked:", con la etiqueta "PackageManager.". Esto indica un posible problema que podría afectar la app y requiere atención.

Filtro de Logcat:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Filtrado de llamadas al sistema de GPU

Para proteger la superficie de la GPU Mali, se bloquearon en las compilaciones de producción las IOCTL de la GPU Mali que se dejaron de usar o que están destinadas únicamente al desarrollo de la GPU. Además, las IOCTL que se usan para la generación de perfiles de la GPU se restringieron al proceso de shell o a las aplicaciones depurables. Consulta la actualización de SAC para obtener más detalles sobre la política a nivel de la plataforma.

Este cambio se realiza en dispositivos Pixel que usan la GPU Mali (Pixel 6-9). Arm proporcionó la categorización oficial de sus IOCTL en Documentation/ioctl-categories.rst de su versión r54p2. Esta lista se seguirá manteniendo en futuras versiones del controlador.

Este cambio no afecta a las APIs de gráficos compatibles (incluidas Vulkan y OpenGL) y no se espera que afecte a los desarrolladores ni a las aplicaciones existentes. Las herramientas de generación de perfiles de GPU, como Streamline Performance Analyzer y el Inspector de GPU para Android, no se verán afectadas.

Prueba

Si ves una denegación de SELinux similar a la siguiente, es probable que este cambio haya afectado a tu aplicación:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

Si tu aplicación necesita usar IOCTL bloqueadas, informa un error y asígnalo a android-partner-security@google.com.

Preguntas frecuentes

¿Este cambio de política se aplica a todos los OEMs? Este cambio será opcional, pero estará disponible para cualquier OEM que desee usar este método de endurecimiento. Puedes encontrar instrucciones para implementar el cambio en la documentación de implementación.
¿Es obligatorio realizar cambios en la base de código del OEM para implementar esto, o viene con una nueva versión de AOSP de forma predeterminada? El cambio a nivel de la plataforma vendrá con una nueva versión de AOSP de forma predeterminada. Los proveedores pueden habilitar este cambio en su base de código si desean aplicarlo.
¿Son los SoCs responsables de mantener actualizada la lista de IOCTL? Por ejemplo, si mi dispositivo usa una GPU Mali de ARM, ¿debería comunicarme con ARM para realizar alguno de los cambios? Los SoCs individuales deben actualizar sus listas de IOCTL por dispositivo cuando se lance el controlador. Por ejemplo, ARM actualizará su lista de IOCTL publicada cuando se actualicen los controladores. Sin embargo, los OEMs deben asegurarse de incorporar las actualizaciones en su SEPolicy y agregar las IOCTL personalizadas seleccionadas a las listas según sea necesario.
¿Este cambio se aplica automáticamente a todos los dispositivos Pixel disponibles en el mercado, o se requiere una acción del usuario para activar algo y aplicar este cambio? Este cambio se aplica a todos los dispositivos Pixel disponibles en el mercado que usan la GPU Mali (Pixel 6-9). No se requiere ninguna acción del usuario para aplicar este cambio.
¿El uso de esta política afectará el rendimiento del controlador del kernel? Esta política se probó en la GPU Mali con GFXBench y no se observó ningún cambio medible en el rendimiento de la GPU.
¿Es necesario que la lista de IOCTL se alinee con las versiones actuales del espacio de usuario y del controlador del kernel? Sí, la lista de IOCTL permitidas debe sincronizarse con las IOCTL compatibles con el espacio de usuario y los controladores del kernel. Si se actualizan las IOCTL en el espacio de usuario o el controlador del kernel, se debe actualizar la lista de IOCTL de SEPolicy para que coincida.
ARM categorizó las IOCTL como "restringidas" o "instrumentación", pero queremos usar algunas de ellas en casos de uso de producción o denegar otras. Los OEMs o SoCs individuales son responsables de decidir cómo categorizar las IOCTL que usan, según la configuración de sus bibliotecas Mali del espacio de usuario. La lista de ARM se puede usar para ayudar a decidir sobre estas, pero el caso de uso de cada OEM o SoC puede ser diferente.

Privacidad

Android 16 (nivel de API 36) incluye los siguientes cambios de privacidad.

Permiso de red local

具有 INTERNET 权限的任何应用都可以访问局域网中的设备。这使得应用可以轻松连接到本地设备，但也存在隐私方面的影响，例如形成用户指纹，以及成为位置信息的代理。

本地网络保护项目旨在通过在新的运行时权限后限制对本地网络的访问，来保护用户的隐私。

发布计划

这项变更将分别在 25Q2 和 26Q2 这两个版本之间部署。开发者必须遵循 25Q2 的相关指南并分享反馈，因为这些保护措施将在后续 Android 版本中强制执行。此外，他们还需要按照以下指南更新依赖于隐式本地网络访问权限的场景，并为用户拒绝和撤消新权限做好准备。

影响

在当前阶段，LNP 是一项选择启用功能，这意味着只有选择启用的应用会受到影响。选择启用阶段的目标是让应用开发者了解应用的哪些部分依赖于隐式本地网络访问权限，以便他们为下一个版本做好权限保护准备。

如果应用使用以下方式访问用户的本地网络，则会受到影响：

直接或通过库使用本地网络地址（例如 mDNS 或 SSDP 服务发现协议）上的原始套接字
使用可访问本地网络的框架级类（例如 NsdManager）

向本地网络地址发送流量和从本地网络地址接收流量需要本地网络访问权限。下表列出了一些常见情况：

应用低级层网络操作	需要本地网络权限
建立出站 TCP 连接	是
接受传入的 TCP 连接	是
发送 UDP 单播、多播、广播	是
接收传入的 UDP 单播、多播、广播	是

这些限制是在网络堆栈深处实现的，因此适用于所有网络 API。这包括在原生代码或受管理代码中创建的套接字、Cronet 和 OkHttp 等网络库，以及基于这些库实现的任何 API。尝试解析本地网络上的服务（即带有 .local 后缀的服务）将需要本地网络权限。

上述规则的例外情况：

如果设备的 DNS 服务器位于本地网络上，则进出该服务器（位于端口 53）的流量不需要本地网络访问权限。
使用输出切换器作为其应用内选择器的应用将不需要本地网络权限（更多指南将在 2025 年第 4 季度发布）。

开发者指南（选择启用）

如需选择启用本地网络限制，请执行以下操作：

将设备刷写到 25Q2 Beta 3 或更高版本的 build。
安装要测试的应用。

在 adb 中切换 Appcompat 标志：

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

重启设备

现在，您的应用对本地网络的访问受到限制，任何访问本地网络的尝试都会导致套接字错误。如果您使用的 API 在应用进程之外执行本地网络操作（例如：NsdManager），在选择启用阶段，这些 API 不会受到影响。

如需恢复访问权限，您必须向应用授予 NEARBY_WIFI_DEVICES 权限。

确保应用在其清单中声明了 NEARBY_WIFI_DEVICES 权限。
依次前往设置 > 应用 > [应用名称] > 权限 > 附近的设备 > 允许。

现在，应用对本地网络的访问权限应该已恢复，并且所有场景都应像选择启用应用之前一样正常运行。

本地网络保护功能开始强制执行后，应用的网络流量将受到以下影响。

权限	出站 LAN 请求	出站/入站互联网请求	入站 LAN 请求
已授予	Works	Works	Works
未授予	最差排行榜	Works	最差排行榜

使用以下命令关闭应用兼容性标志

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

错误

每当调用套接字调用 send 或 send 变体向本地网络地址发送数据时，系统都会向该套接字返回因这些限制而产生的错误。

错误示例：

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

本地网络定义

此项目中的本地网络是指使用支持广播的网络接口（例如 Wi-Fi 或以太网）的 IP 网络，但不包括移动网络 (WWAN) 或 VPN 连接。

以下网络被视为本地网络：

IPv4：

169.254.0.0/16 // 链路本地
100.64.0.0/10 // CGNAT
10.0.0.0/8 // RFC1918
172.16.0.0/12 // RFC1918
192.168.0.0/16 // RFC1918

IPv6：

链路本地
直接连接的路线
Thread 等桩网络
多子网（待定）

此外，多播地址 (224.0.0.0/4、ff00::/8) 和 IPv4 广播地址 (255.255.255.255) 也被归类为本地网络地址。

Fotos propiedad de la app

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.