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 que se segmentan 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 error 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
A partir de Android 17, las apps que se segmentan para Android 17 (nivel de API 37) o versiones posteriores reciben una nueva implementación sin bloqueo de android.os.MessageQueue. La nueva implementación mejora el rendimiento y reduce los fotogramas perdidos, pero puede interrumpir los clientes que reflejan los campos y métodos privados de MessageQueue.
Para obtener más información, incluidas las estrategias de mitigación, consulta la guía sobre el cambio de comportamiento de MessageQueue.
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
InputConnectionpersonalizado pueden recuperar datos de selección de candidatos llamando aTextAttribute.isTextSuggestionSelected(). Luego, estas apps deben llamar aAccessibilityEvent.setTextChangeTypes()cuando envíen eventosTYPE_VIEW_TEXT_CHANGED. Las apps que se segmentan para Android 17 (nivel de API 37) y que usan elTextViewestándar tendrán esta función habilitada de forma predeterminada. (Es decir,TextViewcontrolará 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_CHANGEDpueden llamar aAccessibilityEvent.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 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.
For apps targeting Android 17 (API level 37) or higher, ECH is used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the client sends an ECH extension with randomized contents (a mechanism called ECH GREASE). See RFC 9849 for more details on how ECH GREASE works.
To allow apps to customize this behavior, Android 17 adds a new
<domainEncryption> element to the Network Security Configuration file.
Developers can use <domainEncryption> within <base-config> or
<domain-config> tags to select an ECH mode (for example,
"enabled" or "disabled") on a global or per-domain basis.
For more information, see the Encrypted Client Hello documentation.
Se requiere permiso de acceso a la red local para las apps que segmentan Android 17
Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission
to protect users from unauthorized local network access. Because this falls
under the existing NEARBY_DEVICES permission group, users who have already
granted other NEARBY_DEVICES permissions aren't prompted again. This new
requirement prevents malicious apps from exploiting unrestricted local network
access for covert user tracking and fingerprinting. By declaring and requesting
this permission, your app can discover and connect to devices on the local area
network (LAN), such as smart home devices or casting receivers.
Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.
For more information, see the Local network permission documentation.
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
Beginning with Android 17, Android is extending its SMS OTP protection
to apply to standard SMS messages (SMS messages containing an OTP that do not
use the WebOTP or SMS Retriever formats). For most apps targeting
Android 17 (API level 37) or higher, these SMS messages do not become
available until three hours after receipt. This delay is intended to help
prevent OTP hijacking. During this three hour delay, the
SMS_RECEIVED_ACTION broadcast is withheld and
SMS provider database queries are filtered. The SMS message is
available to these apps after the delay.
Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.
Seguridad
Android 17 incluye las siguientes mejoras en la seguridad de los dispositivos y las apps.
Seguridad de la actividad
En Android 17, la plataforma continúa su cambio hacia una arquitectura "segura de forma predeterminada", y presenta un conjunto de mejoras diseñadas para mitigar los exploits de gravedad alta, como el phishing, el secuestro de interacciones y los ataques de confusión de delegados. Esta actualización requiere que los desarrolladores habiliten explícitamente los nuevos estándares de seguridad para mantener la compatibilidad de la app y la protección del usuario.
Entre los impactos clave para los desarrolladores, se incluyen los siguientes:
- Endurecimiento de BAL y habilitación mejorada: Estamos mejorando las restricciones de inicio de actividad en segundo plano (BAL) extendiendo las protecciones a
IntentSender. Los desarrolladores deben migrar de la constante heredadaMODE_BACKGROUND_ACTIVITY_START_ALLOWED. En cambio, debes adoptar controles detallados, comoMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, que restringe los inicios de actividad a situaciones en las que la app de llamadas es visible, lo que reduce significativamente la superficie de ataque. - Herramientas de adopción: Los desarrolladores deben utilizar el modo estricto y las verificaciones de lint actualizadas para identificar patrones heredados y garantizar la preparación para los requisitos futuros del SDK de destino.
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
Si tu app se orienta a Android 14 (nivel de API 37) o versiones posteriores, la protección de carga dinámica de código (DCL) más segura que se introdujo en Android 14 para los archivos DEX y JAR ahora se extiende a las bibliotecas nativas.
Todos los archivos nativos cargados con System.load() deben marcarse como de solo lectura.
De lo contrario, el sistema arroja UnsatisfiedLinkError.
Recomendamos que las apps eviten la carga dinámica de códigos siempre que sea posible, ya que de esta manera aumenta, en gran medida, el riesgo de que una app pueda verse comprometida por la inserción o la manipulación de código.
Restringe los campos de PII en la vista de datos de CP2
En el caso de las apps que segmentan Android 17 (nivel de API Android 17 [nivel de API 37]) y versiones posteriores, Proveedor de contactos 2 (CP2) restringe ciertas columnas que contienen información de identificación personal (PII) de la vista de datos. Cuando se habilita este cambio, estas columnas se quitan de la vista de datos para mejorar la privacidad del usuario. Las columnas restringidas incluyen lo siguiente:
Las apps que usan estas columnas de ContactsContract.Data pueden extraerlas de ContactsContract.RawContacts, uniéndose con RAW_CONTACT_ID.
Aplica verificaciones estrictas de SQL en CP2
En el caso de las apps que se segmentan para Android 17 (nivel de API 37) y versiones posteriores, Proveedor de contactos 2 (CP2) aplica una validación estricta de las consultas en SQL cuando se accede a la tabla ContactsContract.Data sin el permiso READ_CONTACTS.
Con este cambio, si una app no tiene permiso de READ_CONTACTS, se establecen las opciones StrictColumns y StrictGrammar cuando se consulta la tabla ContactsContract.Data. Si una búsqueda usa un patrón que no es compatible con estos, se rechazará y se generará una excepción.
Inteligencia
Android 17 incluye los siguientes cambios en la inteligencia del sistema.
Baja de setContentCaptureEnabled
Content Capture is enabled by default on certain devices to allow on-device AI features to analyze screen contents for intelligent experiences.
Starting in Android 17, the
ContentCaptureManager.setContentCaptureEnabled(boolean)
API method is deprecated. For apps that target Android 17 (API level 37) or
higher, calling setContentCaptureEnabled(false) no longer disables Content
Capture.
If your app needs to continue disabling Content Capture or restrict screen
contents from being captured by the system, you must transition to using the
FLAG_SECURE window layout parameter.
To disable Content Capture, set the FLAG_SECURE flag on your window as shown
in the following example:
Kotlin
window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
Java
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
);
For more details, see the
WindowManager.LayoutParams.FLAG_SECURE reference
documentation.
Medios
Android 17 incluye los siguientes cambios en el comportamiento de los medios.
Protección de audio en segundo plano
Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.
Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:
- The foreground service must have while-in-use (WIU) capabilities.
- The app must have the exact alarm permission and be interacting with
USAGE_ALARMaudio streams.
For more information, including mitigation strategies, see Background audio hardening.
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
En el caso de las apps segmentadas para Android 17 (nivel de API 37), el método read() del objeto InputStream obtenido de un objeto BluetoothSocket basado en RFCOMM ahora devuelve -1 cuando se cierra el socket o se interrumpe la conexión.
Este cambio hace que el comportamiento del socket RFCOMM sea coherente con los sockets LE CoC y se alinea con la documentación estándar de InputStream.read(), que indica que se devuelve -1 cuando se alcanza el final de la transmisión.
Las apps que dependen únicamente de detectar una IOException para salir de un bucle de lectura pueden verse afectadas por este cambio y deben actualizar los bucles de lectura de BluetoothSocket para verificar explícitamente un valor de retorno de -1. Esto garantiza que el bucle finalice correctamente cuando se desconecta el dispositivo remoto o se cierra el socket. Para ver un ejemplo de la implementación recomendada, consulta el fragmento de código en la guía Cómo transferir datos por Bluetooth.