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 que tienen como objetivo 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 tu 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.

Desaparecerá la opción de inhabilitar el formato de borde a borde

Android 15 aplicó el borde a borde para las apps segmentadas para Android 15 (nivel de API 35), pero tu app podía inhabilitarlo configurando R.attr#windowOptOutEdgeToEdgeEnforcement en true. En el caso de las apps que se segmentan para Android 16 (nivel de API 36), R.attr#windowOptOutEdgeToEdgeEnforcement está obsoleta y se inhabilitó, y tu app no puede rechazar el diseño borde a borde.

• Si tu app se segmenta para Android 16 (nivel de API 36) y se ejecuta en un dispositivo Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement seguirá funcionando.
• Si tu app se segmenta para 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 modo borde a borde y quita cualquier uso de R.attr#windowOptOutEdgeToEdgeEnforcement para que tu app también admita el modo borde a borde en un dispositivo con Android 15. Para admitir el borde a borde, consulta la guía de Compose y Views.

Se requiere la migración o la exclusión para el gesto 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.

La animación predictiva de cambio de actividad.

La animación predictiva entre tareas.

Las APIs de fuentes elegantes dejaron de estar disponibles y se inhabilitaron

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.

Comportamiento de

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.

Comportamiento de

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 con tarifa 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 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 Android 16, se incluyen cambios en la forma en que el sistema administra las restricciones de orientación, cambio de tamaño y relación de aspecto para las apps que segmentan Android 16 (nivel de API 36). En pantallas con un ancho mínimo mayor o igual a 600 dp, las restricciones ya no se aplican. Las apps también 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 pillarboxing.

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, por lo que te recomendamos que hagas que tu app sea adaptable para ofrecer 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

Si ignoras las restricciones de orientación, cambio de tamaño y relación de aspecto, es posible que la IU de tu app se vea afectada 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 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:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

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 de forma explícita el comportamiento predeterminado de la app en la configuración de relación de aspecto del dispositivo
• Pantallas más pequeñas que sw600dp

Cómo 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>

Importante: La inhabilitación es temporal y no se aplicará cuando se segmenta para el nivel de API 37 en una versión futura de Android. Es decir, para las apps que se segmentan para el nivel de API 37, se ignoran las restricciones de orientación, cambio de tamaño y relación de aspecto en pantallas de al menos sw600dp.

Salud y fitness

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

Permisos de salud y estado físico

En el caso de las apps que se segmentan para 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 desde Android Sensor Manager
• heartRateAccuracy y heartRateBpm de ProtoLayout en Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH, donde se necesita el permiso android.permission.health respectivo en lugar de BODY_SENSORS

Si tu app usa estas APIs, debe solicitar los permisos específicos respectivos:

• Para el monitoreo durante el uso de la frecuencia cardíaca, la SpO2 o la temperatura cutánea, solicita el permiso detallado en android.permissions.health, como READ_HEART_RATE en lugar de BODY_SENSORS.
• Para el acceso a sensores 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, actividad física y bienestar.

Apps para dispositivos móviles

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

Importante: Si no proporcionas la justificación para las apps para dispositivos móviles, se revocará el permiso.

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 en la 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:

1. 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.

2. 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 habilitación significa que los desarrolladores deben habilitarlo 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
• Elegir de forma activa incorporar prácticas más estrictas de control de intents en sus apps

Este enfoque de aceptación minimiza el riesgo de interrumpir las 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, eventualmente, hacer que 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>

Nota: El atributo se puede especificar en la etiqueta <application>, así como en las etiquetas de componentes, como <activity>, <activity-alias>, <receiver>, <service> y <provider>, y el atributo del componente se puede usar para anular lo que se encuentra en la etiqueta <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 dándole prioridad a la marca "none".
allowNullAction	Relaja las reglas de coincidencia para permitir que coincidan las intenciones 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 la GPU

Para proteger la superficie de la GPU Mali, se bloquearon en las compilaciones de producción los IOCTL de la GPU Mali que se dejaron de usar o que están destinados únicamente al desarrollo de la GPU. Además, los 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 del SAC para obtener más detalles sobre la política a nivel de la plataforma.

Este cambio se aplica a los dispositivos Pixel que usan la GPU Mali (Pixel 6 a 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 de controladores.

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 Android GPU Inspector, no se verán afectadas.

Prueba

Si ves una denegación de SELinux similar a la siguiente, es probable que este cambio haya afectado 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 bloqueados, informa un error y asígnale la dirección [e-mail].

Preguntas frecuentes

1. ¿Este cambio en la política se aplica a todos los OEM? Este cambio será opcional, pero estará disponible para todos los OEM que deseen usar este método de refuerzo. Puedes encontrar las instrucciones para implementar el cambio en la documentación de implementación.

2. ¿Es obligatorio realizar cambios en la base de código del OEM para implementar esto, o viene con una nueva versión del AOSP de forma predeterminada? El cambio a nivel de la plataforma se incluirá de forma predeterminada en una nueva versión de AOSP. Los proveedores pueden habilitar este cambio en su base de código si desean aplicarlo.

3. ¿Los SoC son responsables de mantener actualizada la lista de IOCTL? Por ejemplo, si mi dispositivo usa una GPU ARM Mali, ¿debería comunicarme con ARM para realizar alguno de los cambios? Los SoCs individuales deben actualizar sus listas de IOCTL por dispositivo cuando se lanza el controlador. Por ejemplo, ARM actualizará su lista de IOCTL publicadas cuando se actualicen los controladores. Sin embargo, los OEM deben asegurarse de incorporar las actualizaciones en su SEPolicy y agregar los IOCTL personalizados seleccionados a las listas según sea necesario.

4. ¿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 algún parámetro y aplicar este cambio? Este cambio se aplica a todos los dispositivos Pixel disponibles en el mercado que usan la GPU Mali (Pixel 6 a 9). No se requiere ninguna acción del usuario para aplicar este cambio.

5. ¿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.

6. ¿Es necesario que la lista de IOCTL coincida con las versiones actuales del controlador del kernel y del espacio del usuario? Sí, la lista de IOCTL permitidas debe sincronizarse con las IOCTL admitidas por los controladores del espacio del usuario y del kernel. Si se actualizan los IOCTL en el espacio del usuario o en el controlador del kernel, se debe actualizar la lista de IOCTL de SEPolicy para que coincida.

7. ARM clasificó los IOCTL como "restringidos" o "de instrumentación", pero queremos usar algunos de ellos en casos de uso de producción o rechazar otros. Los OEM y los SoC individuales son responsables de decidir cómo categorizar los IOCTL que usan, según la configuración de sus bibliotecas de Mali del espacio del usuario. La lista de ARM puede ayudar a decidir sobre estos, pero el caso de uso de cada OEM o SoC puede ser diferente.

Privacidad

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

Permiso de red local

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

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

发布计划

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

影响

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

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

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

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

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

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

注意： 源自需要本地网络访问权限的 Android WebView 的流量将继承宿主应用的权限状态

上述规则的例外情况：

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

注意： 许多媒体投屏场景都依赖于对本地网络的访问权限，因此会受到此变更的影响。不过，并非所有提供投屏功能的应用都需要请求新权限。我们将在 25Q4 中提供有关处理投屏场景的未来 API 和指南。

开发者指南（选择启用）

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

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

3. 在 adb 中切换 Appcompat 标志：

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. 重新启动设备

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

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

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

注意： 在未来的 Android 版本中，此功能将受“附近的设备”权限组中的新权限保护

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

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

权限	出站 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

Cuando una app orientada al SDK 36 o versiones posteriores en dispositivos con Android 16 o versiones posteriores solicite permisos de fotos y videos, los usuarios que elijan limitar el acceso al contenido multimedia seleccionado verán las fotos que pertenecen a la app preseleccionadas en el selector de fotos. Los usuarios pueden anular la selección de cualquiera de estos elementos preseleccionados, lo que revocará el acceso de la app a esas fotos y videos.