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á segmentada para 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 para inhabilitar el formato de borde a borde

Android 15 强制执行全屏显示，以针对 Android 15（API 级别 35）的应用为目标平台，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择停用。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已被弃用并停用，并且您的应用无法选择不采用从边缘到边缘的布局。

• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会继续正常运行。
• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 的使用，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 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 de volver a la pantalla principal.

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

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 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 con pantallas grandes.

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

Si ignoras las restricciones de orientación, cambio de tamaño y relación de aspecto, es posible que se vea afectada 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 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 a la capacidad de cambio de tamaño de la pantalla, android:resizeableActivity="false", android:minAspectRatio y android:maxAspectRatio no tienen ningún efecto.

En el caso de las apps segmentadas para Android 16 (nivel de API 36), se ignoran de forma predeterminada las restricciones de orientación, cambio de tamaño y relación de aspecto en pantallas grandes. 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 el 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

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 segmenten versiones futuras de Android con el nivel de API 37. 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

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用，BODY_SENSORS 权限使用 android.permissions.health 下更精细的权限，健康数据共享也使用这些权限。自 Android 16 起，凡是以前需要 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• 从 Wear OS 上的健康服务中获取 HEART_RATE_BPM
• 来自 Android 传感器管理器的 Sensor.TYPE_HEART_RATE
• 在 Wear OS 上，heartRateAccuracy 和 heartRateBpm 来自 ProtoLayout
• FOREGROUND_SERVICE_TYPE_HEALTH，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 对于使用期间的心率、血氧饱和度或体表温度监测：请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 对于后台传感器访问权限：请求 READ_HEALTH_DATA_IN_BACKGROUND 而不是 BODY_SENSORS_BACKGROUND。

这些权限与用于保护对 健康数据共享（Android 健康、健身和身心状态数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移到使用 READ_HEART_RATE 和其他精细权限的移动应用还必须声明 activity 以显示应用的隐私权政策。此要求与健康数据共享的要求相同。

重要提示： 如果未能提供移动应用使用相关权限的理由，相应权限将被撤消。

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

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 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

“更安全的 intent”功能是一项多阶段安全计划，旨在提高 Android 的 intent 解析机制的安全性。目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的侵害。

在 Android 15 中，该功能侧重于发送应用。现在，在 Android 16 中，控制权转移到了接收应用，开发者可以使用其应用清单选择启用严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器匹配。

2. 没有操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

这种选择启用性质意味着，开发者必须在应用清单中明确启用它，才能使其生效。 因此，此功能的影响将仅限于以下应用：

• 了解“更安全的 intent”功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理实践。

这种选择性采用的方法可最大限度地降低破坏可能依赖于当前不太安全的 intent 解析行为的现有应用的风险。

虽然 Safer Intents 计划在 Android 16 中的初始影响可能有限，但其路线图旨在在未来的 Android 版本中产生更广泛的影响。我们计划最终将严格的意图解析设为默认行为。

通过使恶意应用更难利用 intent 解析机制中的漏洞，“更安全的 intent”功能有望显著提升 Android 生态系统的安全性。

不过，向选择退出和强制执行的过渡必须谨慎管理，以解决现有应用的潜在兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。以下示例展示了如何为整个应用选择启用该功能，但在接收器上停用/选择停用该功能：

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

注意： 该属性也可以在 <application> 标记以及组件标记（例如 <activity>、<activity-alias>、<receiver>、<service>、<provider>）中指定，并且组件中的属性可用于替换 <application> 标记中的属性

有关支持的标志的更多信息：

标志名称	说明
enforceIntentFilter	对传入的 intent 强制执行更严格的匹配
无	针对传入 intent 停用所有特殊匹配规则。指定多个标志时，系统会优先考虑“无”标志，以解决值冲突问题
allowNullAction	放宽匹配规则，以允许匹配没有操作的 intent。此标志应与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

在强制执行处于有效状态时，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息（例如 "Intent does not match component's intent filter:" 和 "Access blocked:"），并带有标记 "PackageManager."。这表示存在可能会影响应用的潜在问题，需要引起注意。

Logcat 过滤条件：

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

Filtrado de llamadas al sistema de la GPU

Para endurecer 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.

Pruebas

Si ves un rechazo de SELinux similar al 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 endurecimiento. 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 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 a 9). No es necesario que los usuarios realicen ninguna acción 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 ser útil para tomar estas decisiones, 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

Cualquier app que tenga el permiso INTERNET puede acceder a los dispositivos de la LAN. Esto facilita que las apps se conecten a dispositivos locales, pero también tiene implicaciones para la privacidad, como la formación de una huella digital del usuario y la posibilidad de ser un proxy de la ubicación.

El proyecto de Protecciones de red local tiene como objetivo proteger la privacidad del usuario limitando el acceso a la red local detrás de un nuevo permiso de tiempo de ejecución.

Plan de lanzamiento

Este cambio se implementará entre dos versiones, 25Q2 y 26Q2, respectivamente. Es fundamental que los desarrolladores sigan esta guía para el 25Q2 y compartan sus comentarios, ya que estas protecciones se aplicarán en una versión posterior de Android. Además, deberán actualizar las situaciones que dependen del acceso implícito a la red local siguiendo las instrucciones que se indican a continuación y prepararse para el rechazo y la revocación del nuevo permiso por parte del usuario.

Impacto

En la etapa actual, la LNP es una función opcional, lo que significa que solo se verán afectadas las apps que la habiliten. El objetivo de la fase de participación es que los desarrolladores de apps comprendan qué partes de sus apps dependen del acceso implícito a la red local para que puedan prepararse para protegerlas con permisos en la próxima versión.

Las apps se verán afectadas si acceden a la red local del usuario con los siguientes métodos:

• Uso directo o de biblioteca de sockets sin procesar en direcciones de red locales (p.ej., protocolo de descubrimiento de servicios mDNS o SSDP)
• Uso de clases a nivel del framework que acceden a la red local (p.ej., NsdManager)

El tráfico hacia y desde una dirección de red local requiere permiso de acceso a la red local. En la siguiente tabla, se enumeran algunos casos comunes:

Operación de red de bajo nivel de la app	Se requiere permiso de red local
Cómo realizar una conexión TCP saliente	sí
Aceptar conexiones TCP entrantes	sí
Envía una transmisión unidifusión, multidifusión o difusión de UDP	sí
Recepción de unidifusión, multidifusión y difusión de UDP entrantes	sí

Estas restricciones se implementan en lo más profundo de la pila de redes y, por lo tanto, se aplican a todas las APIs de redes. Esto incluye los sockets creados en código nativo o administrado, las bibliotecas de redes como Cronet y OkHttp, y cualquier API implementada sobre ellos. Intentar resolver servicios en la red local (es decir, aquellos con un sufijo .local) requerirá permiso de red local.

Nota: El tráfico que se origina en las vistas web de Android que requieren acceso a la red local heredará el estado de permiso de la app host.

Excepciones a las reglas anteriores:

• Si el servidor DNS de un dispositivo está en una red local, el tráfico hacia él o desde él (en el puerto 53) no requiere permiso de acceso a la red local.
• Las aplicaciones que usen el Selector de salida como selector integrado en la app no necesitarán permisos de red local (se publicará más orientación en el 4º trimestre de 2025).

Nota: Muchos casos de uso de transmisión de contenido multimedia dependen del acceso a la red local y se verán afectados por este cambio. Sin embargo, no todas las apps que ofrecen la función de transmisión deberán solicitar el nuevo permiso.

En el cuarto trimestre de 2025, se proporcionarán APIs y orientación futuras para abordar situaciones de transmisión.

Orientación para desarrolladores (opcional)

Para habilitar las restricciones de red local, haz lo siguiente:

1. Escribe en la memoria flash del dispositivo una compilación con la versión beta 3 de 25Q2 o una posterior.
2. Instala la app que se probará.

3. Activa o desactiva la marca de Appcompat en adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reinicia el dispositivo

Ahora, el acceso de tu app a la red local está restringido, y cualquier intento de acceder a la red local generará errores de socket. Si usas APIs que realizan operaciones de red local fuera del proceso de tu app (p. ej., NsdManager), no se verán afectadas durante la fase de habilitación.

Para restablecer el acceso, debes otorgarle permiso a tu app para NEARBY_WIFI_DEVICES.

1. Asegúrate de que la app declare el permiso NEARBY_WIFI_DEVICES en su manifiesto.
2. Ve a Configuración > Apps > [Nombre de la aplicación] > Permisos > Dispositivos cercanos > Permitir.

Nota: En una versión futura de Android, esta función estará protegida por un nuevo permiso en el grupo de permisos de dispositivos cercanos

Ahora se debería restablecer el acceso de tu app a la red local, y todos tus casos de uso deberían funcionar como lo hacían antes de habilitar la app.

Una vez que comience la aplicación de la protección de red local, el tráfico de red de la app se verá afectado de la siguiente manera.

Permiso	Solicitud de LAN saliente	Solicitud de Internet entrante o saliente	Solicitud de LAN entrante
Otorgado	Works	Works	Works
Sin otorgar	Errores	Works	Errores

Usa el siguiente comando para desactivar la marca de App-Compat.

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errores

Los errores que surjan de estas restricciones se devolverán al socket de llamada cada vez que invoque send o una variante de send a una dirección de red local.

Errores de ejemplo:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definición de red local

Una red local en este proyecto hace referencia a una red IP que utiliza una interfaz de red con capacidad de transmisión, como Wi-Fi o Ethernet, pero excluye las conexiones celulares (WWAN) o VPN.

Las siguientes se consideran redes locales:

IPv4:

• 169.254.0.0/16 // Vínculo local
• 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:

• Vínculo local
• Rutas conectadas directamente
• Redes de conexión, como Thread
• Varias subredes (TBD)

Además, tanto las direcciones de multidifusión (224.0.0.0/4, ff00::/8) como la dirección de transmisión IPv4 (255.255.255.255) se clasifican como direcciones de red local.

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.