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

Al igual que las versiones anteriores, Android 17 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 17 o versiones posteriores. Si tu app está orientada a Android 17 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 17, independientemente de la targetSdkVersion de tu app.

Experiencia del usuario y la IU del sistema

Android 17 incluye los siguientes cambios que tienen como objetivo crear una experiencia del usuario más coherente e intuitiva.

Widget de límite de memoria

A partir de Android 17, para las apps segmentadas para Android 17 (nivel de API 37) o versiones posteriores, el sistema aplica un límite de memoria estricto (1.5 * ancho de pantalla * alto de pantalla * 4) en el uso combinado de memoria de los mapas de bits y los íconos presentes en el paquete RemoteViews. Si se superan estos límites, se arroja un IllegalArgumentException fatal y se bloquea el proceso de la app.

Para obtener más información, consulta UpdateAppWidget.

Funcionalidad principal

Android 17 incluye los siguientes cambios que modifican o expanden varias capacidades principales del sistema Android.

Nueva implementación sin bloqueo de MessageQueue

Beginning with Android 17, apps targeting Android 17 (API level 37) or higher receive a new lock-free implementation of android.os.MessageQueue. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

For more information, including mitigation strategies, see MessageQueue behavior change guidance.

Los campos finales estáticos ahora son inmodificables

Apps running on Android 17 or higher that target Android 17 (API level 37) or higher cannot change static final fields. If an app attempts to change a static final field by using reflection, it will cause an IllegalAccessException. Attempting to modify one of these fields through JNI APIs (such as SetStaticLongField()) will cause the app to crash.

Accesibilidad

Android 17 incluye los siguientes cambios para mejorar la accesibilidad.

Compatibilidad con la accesibilidad de la escritura compleja con IME en teclados físicos

Esta función presenta nuevas APIs de AccessibilityEvent y TextAttribute para mejorar la descripción por voz del lector de pantalla para la entrada de idiomas CJKV. Las apps de IME de CJKV ahora pueden indicar si se seleccionó un candidato de conversión de texto durante la composición de texto. Las apps con campos de edición pueden especificar tipos de cambio de texto cuando envían eventos de accesibilidad de texto cambiado. Por ejemplo, las apps pueden especificar que se produjo un cambio de texto durante la composición de texto o que un cambio de texto se produjo a partir de una confirmación. Esto permite que los servicios de accesibilidad, como los lectores de pantalla, proporcionen comentarios más precisos según la naturaleza de la modificación del texto.

Adopción de apps

• Apps de IME: Cuando se configura la composición de texto en campos de edición, los IME pueden usar TextAttribute.Builder.setTextSuggestionSelected() para indicar si se seleccionó un candidato de conversión específico.

• Apps con campos de edición: Las apps que mantienen un InputConnection personalizado pueden recuperar datos de selección de candidatos llamando a TextAttribute.isTextSuggestionSelected(). Luego, estas apps deben llamar a AccessibilityEvent.setTextChangeTypes() cuando envíen eventos TYPE_VIEW_TEXT_CHANGED. Las apps que se segmentan para Android 17 (nivel de API 37) y que usan el TextView estándar tendrán esta función habilitada de forma predeterminada. (Es decir, TextView controlará la recuperación de datos del IME y establecerá tipos de cambios de texto cuando envíe eventos a los servicios de accesibilidad).

• Servicios de accesibilidad: Los servicios de accesibilidad que procesan eventos de TYPE_VIEW_TEXT_CHANGED pueden llamar a AccessibilityEvent.getTextChangeTypes() para identificar la naturaleza de la modificación y ajustar sus estrategias de comentarios en consecuencia.

Privacidad

Android 17 incluye los siguientes cambios para mejorar la privacidad del usuario.

ECH (Encrypted Client Hello) habilitado

Android 17 introduce compatibilidad con la plataforma para Encrypted Client Hello (ECH), una extensión de TLS que mejora la privacidad del usuario encriptando la indicación del nombre del servidor (SNI) en el protocolo de enlace TLS. Este encriptado ayuda a evitar que los observadores de la red identifiquen fácilmente el dominio específico al que se conecta tu app.

En el caso de las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores, se usa ECH para las conexiones TLS. El ECH solo está activo si la biblioteca de redes que usa la app (por ejemplo, HttpEngine, WebView o OkHttp) tiene compatibilidad integrada con el ECH y el servidor remoto también admite el protocolo ECH. Si no se puede negociar ECH, el cliente envía una extensión de ECH con contenido aleatorio (un mecanismo llamado ECH GREASE). Consulta RFC 9849 para obtener más detalles sobre cómo funciona ECH GREASE.

Para permitir que las apps personalicen este comportamiento, Android 17 agrega un nuevo elemento <domainEncryption> al archivo de configuración de seguridad de red. Los desarrolladores pueden usar <domainEncryption> dentro de las etiquetas <base-config> o <domain-config> para seleccionar un modo de ECH (por ejemplo, "enabled" o "disabled") de forma global o por dominio.

Para obtener más información, consulta la documentación de Encrypted Client Hello.

Se requiere permiso de acceso a la red local para las apps que segmentan Android 17

Android 17 introduce el permiso de tiempo de ejecución ACCESS_LOCAL_NETWORK para proteger a los usuarios del acceso no autorizado a la red local. Dado que esto se incluye en el grupo de permisos NEARBY_DEVICES existente, los usuarios que ya otorgaron otros permisos de NEARBY_DEVICES no recibirán el mensaje de nuevo. Este nuevo requisito evita que las apps maliciosas exploten el acceso sin restricciones a la red local para realizar un seguimiento de usuarios y crear huellas digitales encubiertos. Si declaras y solicitas este permiso, tu app podrá descubrir dispositivos en la red de área local (LAN), como dispositivos inteligentes para la casa o receptores de transmisión, y conectarse a ellos.

Las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores ahora tienen dos rutas para mantener la comunicación con dispositivos LAN: adoptar selectores de dispositivos mediados por el sistema que preservan la privacidad para omitir el mensaje de permiso o solicitar explícitamente este nuevo permiso durante el tiempo de ejecución para mantener la comunicación de red local.

Para obtener más información, consulta la documentación sobre el permiso de red local.

Cómo ocultar contraseñas en dispositivos físicos

If an app targets Android 17 (API level 37) or higher and the user is using a physical input device (for example, an external keyboard), the Android operating system applies the new show_passwords_physical setting to all characters in the password field. By default, that setting hides all password characters.

The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.

If the user is using the device's touchscreen, the system applies the new show_passwords_touch setting.

Protección de OTP para mensajes SMS estándar

A partir de Android 17, Android extiende su protección de OTP por SMS para aplicarla a los mensajes SMS estándar (mensajes SMS que contienen una OTP y que no usan los formatos de WebOTP o SMS Retriever). En el caso de la mayoría de las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores, estos mensajes SMS no están disponibles hasta tres horas después de recibirlos. Este retraso tiene como objetivo evitar el secuestro de OTP. Durante este retraso de tres horas, se retiene la transmisión de SMS_RECEIVED_ACTION y se filtran las consultas de la base de datos del proveedor de SMS. El mensaje SMS estará disponible para estas apps después de la demora.

Ciertas apps, como la app predeterminada de asistente de SMS, las apps complementarias de dispositivos conectados, etcétera, están exentas de esta demora. Todas las apps que dependen de la lectura de mensajes SMS para la extracción de OTP deben migrar al uso de las APIs de SMS Retriever o SMS User Consent para garantizar la continuidad de la funcionalidad.

Seguridad

Android 17 incluye las siguientes mejoras en la seguridad de los dispositivos y las apps.

Seguridad de la actividad

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

• BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
• Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

Habilita la CT de forma predeterminada

Si una app se orienta a Android 17 (nivel de API 37) o versiones posteriores, la transparencia de certificados (CT) está habilitada de forma predeterminada. (En Android 16, la CT está disponible, pero las apps debieron habilitarla).

DCL nativa más segura: C

If your app targets Android 17 (API level 37) or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries.

All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError.

We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

Restringe los campos de PII en la vista de datos de CP2

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

Apps that are using these columns from ContactsContract.Data can extract them from ContactsContract.RawContacts instead, by joining with RAW_CONTACT_ID.

Aplica verificaciones estrictas de SQL en CP2

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when the ContactsContract.Data table is accessed without READ_CONTACTS permission.

With this change, if an app doesn't have READ_CONTACTS permission, StrictColumns and StrictGrammar options are set when querying the ContactsContract.Data table. If a query uses a pattern that isn't compatible with these, it will be rejected and cause an exception to be thrown.

Inteligencia

Android 17 incluye los siguientes cambios en la inteligencia del sistema.

Baja de setContentCaptureEnabled

La función Captura de contenido está habilitada de forma predeterminada en ciertos dispositivos para permitir que las funciones de IA integradas en el dispositivo analicen el contenido de la pantalla y brinden experiencias inteligentes.

A partir de Android 17, el método de la API de ContentCaptureManager.setContentCaptureEnabled(boolean) dejó de estar disponible. En el caso de las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores, llamar a setContentCaptureEnabled(false) ya no inhabilita la captura de contenido.

Si tu app necesita seguir inhabilitando la Captura de contenido o restringir que el sistema capture el contenido de la pantalla, debes realizar la transición para usar el parámetro de diseño de ventana FLAG_SECURE.

Para inhabilitar la captura de contenido, establece la marca FLAG_SECURE en tu ventana, como se muestra en el siguiente ejemplo:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

Para obtener más detalles, consulta la documentación de referencia de WindowManager.LayoutParams.FLAG_SECURE.

Medios

Android 17 incluye los siguientes cambios en el comportamiento de los medios.

Protección de audio en segundo plano

A partir de Android 17, el framework de audio aplica restricciones en las interacciones de audio en segundo plano, como la reproducción de audio, las solicitudes de enfoque de audio y las APIs de cambio de volumen, para garantizar que el usuario inicie estos cambios de forma intencional.

Se aplican algunas restricciones de audio a todas las apps. Sin embargo, las restricciones son más estrictas si una app se segmenta para Android 17 (nivel de API 37). Si una de estas apps interactúa con el audio mientras está en segundo plano, debe tener un servicio en primer plano en ejecución. Además, la app debe cumplir con uno o ambos de los siguientes requisitos:

• El servicio en primer plano debe tener capacidades de permiso durante el uso (WIU).
• La app debe tener el permiso de alarma exacta y estar interactuando con transmisiones de audio de USAGE_ALARM.

Para obtener más información, incluidas las estrategias de mitigación, consulta Protección de audio en segundo plano.

Factores de forma del dispositivo

Android 17 incluye los siguientes cambios para mejorar la experiencia del usuario en una variedad de tamaños y factores de forma de dispositivos.

Cambios en la API de la plataforma para ignorar las restricciones de orientación, cambio de tamaño y relación de aspecto en pantallas grandes (sw>=600 dp)

En Android 16, presentamos cambios en la API de la plataforma para ignorar las restricciones de orientación, relación de aspecto y cambio de tamaño en pantallas grandes (ancho mínimo >= 600 dp) para las apps que segmentan el nivel de API 36 o posterior. Los desarrolladores tienen la opción de inhabilitar estos cambios con el SDK 36, pero esta opción ya no estará disponible para las apps que segmenten Android 17 (nivel de API 37) o versiones posteriores.

Para obtener más información, consulta Se ignoran las restricciones de orientación y cambio de tamaño.

Conectividad

Android 17 introduce el siguiente cambio para mejorar la coherencia y alinearse con el comportamiento estándar de InputStream de Java para los sockets RFCOMM de Bluetooth.

Comportamiento coherente de read() de BluetoothSocket para RFCOMM

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.