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 quitará la opción para inhabilitar el diseño de borde a borde

Android 15 aplicó el modo 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 que se orientan a Android 16 (nivel de API 36), R.attr#windowOptOutEdgeToEdgeEnforcement está obsoleto y se inhabilita, y tu app no puede inhabilitar la opción de ir de borde a borde.

• Si tu app se orienta a Android 16 (nivel de API 36) y se ejecuta en un dispositivo con Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement seguirá funcionando.
• Si tu app se orienta a Android 16 (nivel de API 36) y se ejecuta en un dispositivo con Android 16, se inhabilita R.attr#windowOptOutEdgeToEdgeEnforcement.

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

Se requiere la migración o la inhabilitación para el gesto atrás predictivo

En el caso de las apps que se orientan a Android 16 (nivel de API 36) o versiones posteriores y que se ejecutan en un dispositivo con Android 16 o versiones posteriores, 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, ya no se llama a onBackPressed ni se envía KeyEvent.KEYCODE_BACK.

Si tu app intercepta el evento atrás y aún no migraste al gesto atrás predictivo, actualiza tu app para usar 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 a la pantalla principal.

Es la animación predictiva de cambio de actividad.

La animación predictiva entre tareas.

Se inhabilitaron y dejaron de estar disponibles las APIs de fuentes elegantes

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 funciones 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 de los dispositivos

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

Diseños adaptables

Android 应用现在可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并支持大屏设备上的各种窗口模式（例如分屏和窗口化模式），因此开发者应构建能够适应任何屏幕和窗口大小的 Android 应用，无论设备屏幕方向如何。在当今的多设备世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸调整和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，屏幕方向、尺寸调整和宽高比限制不再适用于最小宽度 >= 600dp 的显示屏。应用会填满整个显示窗口，无论宽高比或用户首选屏幕方向如何，并且不使用邮筒模式。

此项变更引入了新的标准平台行为。Android 正在转向一种模式，其中应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或尺寸调整受限等限制会阻碍应用自适应。使您的应用具有自适应性，以提供最佳用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见破坏性更改

忽略屏幕方向、尺寸调整和宽高比限制可能会影响应用在某些设备上的界面，尤其是针对锁定为纵向的小布局设计的元素：例如，布局拉伸以及动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在大屏设备上，在全屏模式和多窗口模式下，系统会忽略以下清单属性和运行时 API：

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

系统会忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的以下值：

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

对于显示屏大小可调整性，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 不会产生任何影响。

对于以 Android 16（API 级别 36）为目标平台的应用，默认情况下，大屏设备会忽略应用对于屏幕方向、尺寸调整和宽高比的限制。每个尚未完全准备就绪的应用都可以通过选择停用此行为来暂时替换此行为，从而恢复到之前的行为，即置于兼容模式。

例外情况

Android 16 的屏幕方向、尺寸可调整性和宽高比限制不适用于以下情况：

• 游戏（基于 android:appCategory 标志）
• 用户在设备的宽高比设置中明确选择启用应用的默认行为
• 小于 sw600dp 的屏幕

暂时停用

如需停用特定 activity，请声明 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 清单属性：

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

如果您的应用有太多部分尚未准备好支持 Android 16，您可以在应用级别应用同一属性，以完全停用该功能：

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

重要提示： 选择退出是临时性的，在未来的 Android 版本中，如果应用以目标 API 级别 37 为目标平台，则无法选择退出。也就是说，对于目标 API 级别为 37 的应用，在尺寸至少为 sw600dp 的显示屏上，屏幕方向、尺寸可调整性和宽高比限制会被忽略。

Salud y fitness

Android 16 (nivel de API 36) incluye los siguientes cambios relacionados con los datos de salud y 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 correspondiente en lugar de BODY_SENSORS

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

• 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 acceder a los 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 para leer 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 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.

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 los 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 enfocaba en la app que enviaba el intent. Ahora, con Android 16, el control se traslada a la app que lo recibe, lo que permite que los desarrolladores habiliten la resolución estricta de intents con el manifiesto de la 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 se orienta explícitamente a 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 se deben resolver 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 aceptación significa que los desarrolladores deben habilitarla de forma explícita en el manifiesto de la app para que se aplique. Por lo tanto, 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 activamente incorporar prácticas más estrictas de manejo de intents en sus apps

Este enfoque de habilitación minimiza el riesgo de que se dañen 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 de intents más seguros tiene una hoja de ruta para un impacto más amplio en futuras versiones de Android. El plan es que, con el tiempo, la resolución estricta de intents sea el comportamiento predeterminado.

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

Sin embargo, la transición a la inhabilitación y la aplicación obligatoria de políticas se deben administrar con cuidado para abordar los posibles problemas de compatibilidad con las apps existentes.

Implementación

Los desarrolladores deben habilitar de forma explícita una coincidencia de intents más estricta con el atributo intentMatchingFlags en el manifiesto de la app. Este es un ejemplo en el que la función está habilitada para toda la app, pero inhabilitada o inhabilitada 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 de coincidencia especiales para los intents entrantes. Cuando se especifican varias marcas, los valores en conflicto se resuelven dando prioridad a la marca "none"
allowNullAction	Flexibiliza las reglas de coincidencia para permitir que los intents sin una acción coincidan. Esta marca se debe usar junto con "enforceIntentFilter" para lograr un comportamiento específico.

Pruebas y depuración

Cuando la aplicación de medidas por incumplimiento esté activa, las apps deberían funcionar correctamente si el emisor del intent lo completó de forma adecuada. Sin embargo, los intents bloqueados 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

为了强化 Mali GPU 表面，已废弃或仅用于 GPU 开发的 Mali GPU IOCTL 已在正式版 build 中被屏蔽。此外，用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试应用。如需详细了解平台级政策，请参阅 SAC 更新。

此变更适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 在其 r54p2 版本的 Documentation/ioctl-categories.rst 中提供了其 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。

此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 GPU 性能分析工具（例如 Streamline Performance Analyzer 和 Android GPU 检查器）不会受到影响。

测试

如果您看到类似以下内容的 SELinux 拒绝，则您的应用可能已受到此变更的影响：

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

如果您的应用需要使用被屏蔽的 IOCTL，请提交 bug 并将其分配给 [e-mail]。

常见问题解答

1. 此政策变更是否适用于所有 OEM？ 此项变更将采用选择启用的方式，但任何想要使用此加固方法的 OEM 都可以使用。如需了解如何实现此变更，请参阅实现文档。

2. 是否必须在 OEM 代码库中进行更改才能实现此功能，还是说新的 AOSP 版本默认提供此功能？ 默认情况下，平台级变更将随新的 AOSP 版本一起发布。如果供应商希望应用此更改，可以在其代码库中选择启用此更改。

3. SoC 是否负责确保 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何更改与 ARM 联系？ 各个 SoC 必须在驱动程序发布时更新其每个设备的 IOCTL 列表。 例如，ARM 会在驱动程序更新时更新其发布的 IOCTL 列表。 不过，OEM 应确保将这些更新纳入其 SEPolicy 中，并根据需要将任何选定的自定义 IOCTL 添加到列表中。

4. 此变更会自动应用于所有在售 Pixel 设备，还是需要用户执行操作来切换某些设置才能应用此变更？ 此变更适用于所有使用 Mali GPU 的 Pixel 在售设备（Pixel 6-9）。用户无需采取任何行动即可应用此变更。

5. 使用此政策是否会影响内核驱动程序的性能？ 此政策已在 Mali GPU 上使用 GFXBench 进行了测试，未观察到 GPU 性能发生可测量的变化。

6. IOCTL 列表是否必须与当前用户空间和内核驱动程序版本保持一致？ 是的，允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新，则 SEPolicy IOCTL 列表也必须进行更新以保持一致。

7. ARM 已将 IOCTL 分类为“受限”/“插桩”，但我们希望在生产用例中使用其中一些 IOCTL，和/或拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置，决定如何对所使用的 IOCTL 进行分类。 ARM 的列表可用于帮助确定这些设置，但每个 OEM/SoC 的用例可能有所不同。

Privacidad

Android 16 (nivel de API 36) incluye los siguientes cambios de 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 de privacidad, como formar una huella digital del usuario y ser un proxy de ubicación.

El proyecto de protecciones de red local tiene como objetivo proteger la privacidad del usuario restringiendo 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 25Q2 y compartan 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 con la siguiente guía 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 habilitación es que los desarrolladores de apps comprendan qué partes de su app dependen del acceso implícito a la red local, de modo 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 lo siguiente:

• 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 de nivel de 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 muestran algunos casos comunes:

Operación de red de bajo nivel de la app	Se requiere permiso de red local
Establece una conexión TCP saliente	sí
Acepta conexiones TCP entrantes	sí
Envía una transmisión de unidifusión, multidifusión o difusión de UDP	sí
Recibir una transmisión unicast, multicast o de emisión UDP entrante	sí

Estas restricciones se implementan en lo profundo de la pila de red y, por lo tanto, se aplican a todas las APIs de red. Esto incluye los sockets creados en código nativo o administrado, las bibliotecas de herramientas de redes, como Cronet y OkHttp, y las APIs implementadas sobre ellas. 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 WebViews 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 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 su selector integrado en la app no necesitarán permisos de red local (se proporcionarán más instrucciones en el cuarto trimestre de 2025).

Nota: Muchas situaciones de transmisión de contenido multimedia dependen del acceso a la red local y se verán afectadas por este cambio. Sin embargo, no todas las apps que ofrecen transmisión necesitará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 (aceptación)

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 a la app permiso 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 app] > 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 todas tus situaciones deberían funcionar como antes de habilitar la app.

Una vez que comience la aplicación de la protección de la 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
Concedido	Works	Works	Works
No otorgado	Errores	Works	Errores

Usa el siguiente comando para desactivar la marca de compatibilidad de la app:

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 se refiere a una red IP que utiliza una interfaz de red con capacidad de transmisión, como Wi-Fi o Ethernet, pero excluye las conexiones móviles (WWAN) o de VPN.

Las siguientes se consideran redes locales:

IPv4:

• 169.254.0.0/16 // Link 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 stub como Thread
• Varias subredes (por definir)

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

Fotos que pertenecen a la app

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。