Cambios de comportamiento: todas las apps

Android 10 incluye cambios de comportamiento que podrían afectar a tu app. Los cambios que se enumeran en esta página se aplican a tu app cuando se ejecuta en Android 10, independientemente de su targetSdkVersion. Deberías probar tu app y modificarla según sea necesario para que admita estos cambios de manera correcta.

Si la targetSdkVersion de tu app es 29 o una versión posterior, también deberás admitir cambios adicionales. Asegúrate de leer los cambios de comportamiento para apps que se orientan a la versión 29 para obtener más detalles.

Nota: Además de los cambios que se enumeran en esta página, Android 10 presenta varios cambios y restricciones basados en la privacidad, incluidos los siguientes:

• Acceso en segundo plano a la ubicación del dispositivo
• Inicio de actividades en segundo plano
• Información de afinidad de contactos
• Aleatorización de direcciones MAC
• Metadatos de la cámara
• Modelo de permisos

Estos cambios afectan a todas las apps y mejoran la privacidad del usuario. Para obtener más información sobre cómo admitir estos cambios, consulta la página Cambios en la privacidad.

Restricciones en interfaces no SDK

Para ayudar a garantizar la estabilidad y compatibilidad de las apps, la plataforma comenzó a restringir las interfaces no pertenecientes al SDK que tu app puede usar en Android 9 (nivel de API 28). Android 10 incluye listas actualizadas de este tipo de interfaces que están basadas en la colaboración con desarrolladores de Android y las pruebas internas más recientes. Nuestro objetivo es asegurarnos de que las alternativas públicas estén disponibles antes de restringir las interfaces que no pertenecen al SDK.

Si no orientarás tu app a Android 10 (nivel de API 29), es posible que algunos de estos cambios no te afecten de inmediato. Sin embargo, aunque actualmente puedes usar algunas interfaces que no pertenecen al SDK (según el nivel de API al que esté orientada la app), utilizar cualquier método o campo que no pertenezca al SDK siempre implica un gran riesgo de error para tu app.

Si no sabes con seguridad si tu app usa este tipo de interfaces, puedes probarla para verificarlo. Si tu app depende de interfaces que no pertenecen al SDK, debes comenzar a planificar una migración hacia otras alternativas SDK, Sin embargo, sabemos que algunas apps tienen casos prácticos válidos para usarlas. Si no encuentras una alternativa al uso de una interfaz que no pertenece al SDK para una función de tu app, deberías solicitar una nueva API pública.

Para obtener más información, consulta las actualizaciones de restricciones sobre interfaces que no pertenecen al SDK para Android 10 y las restricciones sobre interfaces que no pertenecen al SDK.

Navegación por gestos

A partir de Android 10, los usuarios pueden habilitar la navegación por gestos en todo el dispositivo. Si un usuario habilita la navegación por gestos, esta acción afecta a todas las apps en el dispositivo, independientemente de si se orientan al nivel de API 29 o no. Por ejemplo, si el usuario desliza el dedo hacia adentro desde el borde de la pantalla, el sistema interpreta ese gesto como una navegación "Atrás", a menos que una app anule específicamente ese gesto para determinadas secciones de la pantalla.

Para que tu app sea compatible con la navegación gestual, te recomendamos extender el contenido de la app de borde a borde y administrar los gestos conflictivos de manera apropiada. Para obtener más información, consulta la documentación sobre Navegación por gestos.

NDK

En Android 10, se incluyen los siguientes cambios en el NDK.

Los objetos compartidos no pueden contener reubicaciones de texto

En Android 6.0 (nivel de API 23) se prohibió el uso de reubicaciones de texto en objetos compartidos. El código se debe cargar sin modificaciones. Este cambio mejora la seguridad y los tiempos de carga de la app.

SELinux aplica esta restricción en las apps orientadas a Android 10 o versiones posteriores. Si estas apps continúan usando objetos compartidos que contienen reubicaciones de texto, corren un alto riesgo de fallar.

Cambios en las bibliotecas Bionic y las rutas de vinculador dinámico

A partir de Android 10, varias rutas de acceso son vínculos simbólicos, en lugar de archivos normales. Es posible que las apps que dependan de que las rutas sean archivos normales fallen:

• /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
• /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
• /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
• /system/bin/linker -> /apex/com.android.runtime/bin/linker

Estos cambios también se aplican a las variantes de 64 bits del archivo, con lib/ reemplazada por lib64/.

Para la compatibilidad, los symlinks se proporcionan en las rutas de acceso anteriores. Por ejemplo, /system/lib/libc.so es un symlink a /apex/com.android.runtime/lib/bionic/libc.so. Por lo tanto, dlopen(“/system/lib/libc.so”) sigue funcionando, pero las apps encontrarán la diferencia cuando intenten examinar las bibliotecas cargadas leyendo /proc/self/maps o algo similar, lo cual no es habitual, pero descubrimos que algunas apps lo hacen como parte de su proceso antipiratería. Si es así, las rutas de acceso /apex/… deben agregarse como rutas válidas para los archivos Bionic.

Bibliotecas y objetos binarios del sistema asignados a memoria de solo ejecución

A partir de Android 10, los segmentos ejecutables de bibliotecas y objetos binarios del sistema se asignan a la memoria de solo ejecución (no de lectura) como técnica de endurecimiento contra los ataques de reutilización de código. Si tu app realiza operaciones de lectura en los segmentos de memoria marcados como de solo ejecución, ya sea por un error, una vulnerabilidad o una inspección intencional de la memoria, el sistema envía una señal SIGSEGV a tu app.

Para identificar si una falla fue producto de este cambio, examina el archivo de exclusión relacionado en /data/tombstones/. Una falla relacionada con la ejecución solo contiene el siguiente mensaje de anulación:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

Para solucionar este problema y realizar operaciones como la inspección de memoria, puedes marcar los segmentos de solo ejecución como de lectura y ejecución mediante una llamada a mprotect(). Sin embargo, te recomendamos revertir la configuración a "solo ejecución" una vez que termines, ya que de esta manera se brindará más protección a tu app y los usuarios.

Nota: Las llamadas a ptrace no se ven afectadas por este comportamiento, lo que te permite depurar ptrace.

Seguridad

Android 10 incluye los siguientes cambios de seguridad.

TLS 1.3 habilitado de forma predeterminada

En Android 10 y versiones posteriores, TLS 1.3 está habilitado de forma predeterminada para todas las conexiones TLS. A continuación, se muestran algunos detalles importantes sobre nuestra implementación de TLS 1.3:

• Los conjuntos de algoritmos de cifrado de TLS 1.3 no se pueden personalizar. Aquellos que son compatibles siempre están habilitados cuando TLS 1.3 está habilitado. Se ignorará cualquier intento de inhabilitarlos con una llamada a setEnabledCipherSuites().
• Cuando se negocia TLS 1.3, se llama a los objetos HandshakeCompletedListener antes de que se agreguen sesiones a la caché de sesiones. (En TLS 1.2 y otras versiones anteriores, se llama a estos objetos después de que se agregan las sesiones a la caché de sesiones).
• En algunas situaciones en las que las instancias de SSLEngine arrojan SSLHandshakeException en versiones anteriores de Android, estas instancias, en cambio, arrojan SSLProtocolException en Android 10 y versiones posteriores.
• No se admite el modo 0-RTT.

Si lo deseas, puedes obtener un SSLContext que tenga TLS 1.3 inhabilitado con una llamada a SSLContext.getInstance("TLSv1.2"). También puedes habilitar o inhabilitar versiones de protocolo por conexión si llamas a setEnabledProtocols() en un objeto correspondiente.

Los certificados firmados con SHA-1 no son confiables en TLS

En Android 10, los certificados que usan el algoritmo de hash SHA-1 no se consideran confiables en las conexiones TLS. Las AC raíz no emiten ese certificado desde 2016, y ya no se consideran confiables en Chrome ni en otros navegadores importantes.

Fallará cualquier intento de establecer conexión con un sitio que presente un certificado con SHA-1.

Mejoras y cambios en el comportamiento de KeyChain

Algunos navegadores, como Google Chrome, les permiten a los usuarios elegir un certificado cuando un servidor TLS envía un mensaje de solicitud de certificado como parte de un protocolo de enlace TLS. A partir de Android 10, los objetos KeyChain respetan los emisores y los parámetros de especificación de claves cuando llaman a KeyChain.choosePrivateKeyAlias() para mostrarles a los usuarios un mensaje de selección de certificado. En particular, esta solicitud no contiene opciones que no cumplen con las especificaciones del servidor.

Si no hay ningún certificado disponible para que el usuario seleccione, como sucede cuando no hay ninguno que cumpla con las especificaciones del servidor o un dispositivo no tiene certificados instalados, no se mostrará la solicitud de selección de certificado.

Además, en Android 10 o versiones posteriores, no es necesario tener un bloqueo de pantalla del dispositivo para importar claves o certificados de AC al objeto KeyChain.

Otros cambios en la criptografía y en TLS

Se realizaron pequeños cambios en las bibliotecas de criptografía y TLS que se aplicarán en Android 10:

• Los algoritmos de cifrado AES/GCM/NoPadding y ChaCha20/Poly1305/NoPadding muestran tamaños de búfer más precisos desde getOutputSize().
• El conjunto de algoritmos de cifrado TLS_FALLBACK_SCSV se omite de los intentos de conexión con un protocolo máximo de TLS 1.2 o superior. Como se incorporaron mejoras en las implementaciones del servidor TLS, no recomendamos revertir a la configuración de TLS externo. En su lugar, te recomendamos basarte en la negociación de versiones de TLS.
• ChaCha20-Poly1305 es un alias para ChaCha20/Poly1305/NoPadding.
• Los nombres de hosts con puntos finales no se consideran nombres de hosts de SNI válidos.
• Se respeta la extensión supported_signature_algorithms admitida en CertificateRequest cuando se elige una clave de firma para respuestas de certificados.
• Las claves de firma opacas, como las del almacén de claves de Android, se pueden usar con firmas RSA-PSS en TLS.

Transmisiones por Wi-Fi directo

En Android 10, las siguientes transmisiones relacionadas con Wi-Fi directo no son persistentes:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Si tu app dependía de la recepción de estas transmisiones en el registro debido a que eran fijas, en su lugar, usa el método get() apropiado en la inicialización para obtener la información.

Capacidades de reconocimiento de Wi-Fi

En Android 10, se agregó compatibilidad para facilitar la creación de un Socket TCP/UDP mediante rutas de acceso a datos de reconocimiento de Wi-Fi. Para crear un socket TCP/UDP que se conecte a un ServerSocket, el dispositivo del cliente debe conocer la dirección IPv6 y el puerto del servidor. Anteriormente, este debía comunicarse por fuera de la banda (por ejemplo, por medio de mensajería de nivel 2 a través de Bluetooth o reconocimiento de Wi-Fi) o detectarse dentro de la banda mediante otros protocolos (por ejemplo, mDNS). Con Android 10, la información se puede transmitir como parte de la configuración de red.

El servidor puede realizar cualquiera de las siguientes acciones:

• Inicializar un ServerSocket y obtener o configurar el puerto que se usará
• Especificar la información del puerto como parte de la solicitud de red de reconocimiento de Wi-Fi

En la siguiente muestra de código, se indica cómo especificar la información del puerto como parte de la solicitud de red:

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

Luego, el cliente realiza una solicitud de red de reconocimiento de Wi-Fi para obtener el IPv6 y el puerto que proporciona el servidor:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW en dispositivos Go

Las apps que se ejecutan en dispositivos con Android 10 (edición Go) no pueden obtener el permiso SYSTEM_ALERT_WINDOW. Esto se debe a que el dibujo de ventanas superpuestas usa demasiada memoria, lo que es particularmente dañino para el rendimiento de los dispositivos Android con poca memoria.

Si una app que se ejecuta en un dispositivo Go con Android 9 o versiones anteriores recibe el permiso SYSTEM_ALERT_WINDOW, la app retiene este permiso incluso si el dispositivo se actualiza a Android 10. Sin embargo, las apps que todavía no tengan el permiso no podrán obtenerlo una vez que se actualice el dispositivo.

Si una app en un dispositivo Go envía un intent con la acción ACTION_MANAGE_OVERLAY_PERMISSION, el sistema rechaza automáticamente la solicitud y dirige al usuario a una pantalla de Configuración en la que se indica que no se permite el permiso porque ralentiza el dispositivo. Si una app en un dispositivo Go llama a Settings.canDrawOverlays(), el método siempre mostrará un resultado falso. Estas restricciones no se aplican a apps que recibieron el permiso SYSTEM_ALERT_WINDOW antes de que el dispositivo se actualizara a Android 10.

Advertencias para las apps orientadas a versiones anteriores de Android

Los dispositivos que ejecutan Android 10 o versiones posteriores advierten a los usuarios la primera vez que ejecutan una app orientada a Android 5.1 (nivel de API 22) o versiones anteriores. Si la app requiere que el usuario otorgue permisos, este tendrá la oportunidad de ajustar los permisos de esa app antes de permitir que se ejecute por primera vez.

Debido a los requisitos del nivel de API objetivo de Google Play, un usuario solo verá estas advertencias si ejecuta una app que no se actualizó recientemente. En el caso de las apps que se distribuyen en otras tiendas, se aplicarán requisitos similares de la API objetivo durante 2019. Para obtener más información sobre estos requisitos, consulta Cómo expandir los requisitos del nivel de API objetivo en 2019.

Eliminación de conjuntos de cifrado SHA-2 CBC

Se quitaron de la plataforma los siguientes conjuntos de cifrado SHA-2 CBC:

• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Estos conjuntos de algoritmos de cifrado son menos seguros que otros similares que usan GCM y la mayoría de los servidores admiten las variantes de GCM y CBC de estos conjuntos de cifrado o no admiten ninguna de ellas.

Nota: Las apps y bibliotecas deben cruzar el conjunto deseado de conjuntos de algoritmos de cifrado con el valor que se muestra de getSupportedCipherSuites() para preparar la selección del conjunto de algoritmos de cifrado para evitar eliminaciones futuras.

Uso de apps

Android 10 presenta los siguientes cambios en el comportamiento relacionados con el uso de apps:

• Además, Android 10 puede realizar un seguimiento adecuado del uso de las apps instantáneas.

• Estado de distracción por app: Android 10 puede configurar las apps de forma selectiva en un "estado de distracción" en el que se suprimen sus notificaciones y no aparecen como apps sugeridas.

• Suspensión y reproducción: En Android 10, las apps suspendidas no pueden reproducir audio.

Cambios en la conexión HTTPS

Si una app que ejecuta Android 10 pasa null a setSSLSocketFactory(), se produce una IllegalArgumentException. En las versiones anteriores, pasar null en setSSLSocketFactory() tenía el mismo efecto que pasar el valor de fábrica predeterminado actual.

La biblioteca android.preference dejó de estar disponible

La biblioteca android.preference dejó de estar disponible a partir de Android 10. En su lugar, los desarrolladores deben usar la biblioteca de preferencia de AndroidX, que forma parte de Android Jetpack. Para obtener recursos adicionales de ayuda durante la migración y el desarrollo, consulta la Guía de configuración actualizada, nuestra app de ejemplo pública y la documentación de referencia.

Cambios en la biblioteca de utilidades de archivos ZIP

En Android 10, se introducen los siguientes cambios en las clases del paquete java.util.zip, que controla los archivos ZIP. Estos cambios hacen que el comportamiento de la biblioteca sea más coherente entre Android y otras plataformas que usan java.util.zip.

Inflater

En versiones anteriores, algunos métodos de la clase Inflater arrojaban una IllegalStateException si se invocaban después de una llamada a end(). En Android 10, estos métodos muestran una NullPointerException.

ZipFile

En Android 10 y versiones posteriores, el constructor de ZipFile que toma argumentos de tipo File, int y Charset no arroja una ZipException si el archivo ZIP proporcionado no contiene archivos.

ZipOutputStream

En Android 10 y versiones posteriores, el método finish() en ZipOutputStream no arroja una ZipException si intenta escribir una transmisión de salida para un archivo ZIP que no contiene ningún archivo.

Cambios en la cámara

Muchas apps que usan la cámara suponen que, si el dispositivo está en configuración vertical, entonces el dispositivo físico también tiene orientación vertical, como se describe en la orientación de la cámara. Esta suposición solía ser cierta, pero con la expansión de los factores de forma disponibles, como los dispositivos plegables, ya no se aplica, porque podría llevar a que el visor de la cámara se ajuste o rote (o ambas cosas) incorrectamente.

Las aplicaciones que se orientan al nivel de API 24 o a uno superior deben configurar android:resizeableActivity de forma explícita y proporcionar la funcionalidad necesaria para controlar la operación multiventana.

Seguimiento del uso de batería

A partir de Android 10, SystemHealthManager restablece las estadísticas de uso de batería cada vez que el dispositivo se desconecta después de un evento de carga importante. En términos generales, un evento de carga importante puede ser que el dispositivo se cargó completamente o que pasó de tener muy poca carga a tenerla casi completa.

En versiones anteriores a Android 10, las estadísticas de uso de batería se restablecían cada vez que el dispositivo se desconectaba, independientemente del cambio en el nivel de la batería.

Baja de Android Beam

En Android 10, dejará de estar disponible Android Beam oficialmente, una antigua función para iniciar el uso compartido de datos entre dispositivos por medio de la Comunicación de campo cercano (NFC). También dejaremos de admitir varias de las APIs de NFC relacionadas. Android Beam seguirá disponible de manera opcional para los socios fabricantes que quieran usarla, pero no se seguirá desarrollando. Sin embargo, Android aún admitirá otras API y capacidades de NFC, y los casos de uso como la lectura de etiquetas y pagos seguirán funcionando como se espera.

Cambio de comportamiento de java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() ya no conserva los ceros finales como un caso especial si el valor de entrada es cero.

Cambios en el comportamiento de java.util.regex.Matcher y Pattern

Se cambió el resultado de split() para que ya no comience con una String vacía ("") cuando hay una coincidencia de ancho cero al comienzo de la entrada. Esto también afecta a String.split(). Por ejemplo, "x".split("") ahora muestra {"x"}, mientras que solía mostrar {"", "x"} en versiones anteriores de Android. "aardvark".split("(?=a)" ahora muestra {"a", "ardv", "ark"} en lugar de {"", "a", "ardv", "ark"}.

También se mejoró el comportamiento de excepción para los argumentos no válidos:

• appendReplacement(StringBuffer, String) ahora muestra una IllegalArgumentException en lugar de IndexOutOfBoundsException si el reemplazo String termina con una barra invertida sola, lo que es ilegal. Ahora, se arroja la misma excepción si el String de reemplazo termina con un $. Anteriormente, no se generaba ninguna excepción en esta situación.
• replaceFirst(null) ya no llama a reset() en Matcher si arroja un NullPointerException. Ahora también se arroja NullPointerException cuando no hay coincidencia. Anteriormente, solo se arrojaba cuando había una coincidencia.
• start(int group), end(int group) y group(int group) ahora arrojan un IndexOutOfBoundsException más general si el índice del grupo está fuera de los límites. Anteriormente, estos métodos arrojaban ArrayIndexOutOfBoundsException.

El ángulo predeterminado para GradientDrawable ahora es TOP_BOTTOM.

En Android 10, si defines un GradientDrawable en XML y no proporcionas una medición de ángulo, la orientación del gradiente se establece de forma predeterminada en TOP_BOTTOM. Este es un cambio con respecto a las versiones anteriores de Android, en las que el valor predeterminado era LEFT_RIGHT.

Como solución alternativa, si actualizas a la versión más reciente de AAPT2, la herramienta establece una medición de ángulo de 0 para las apps heredadas si no se especifica una medición de ángulo.

Registro de objetos serializados con SUID predeterminado

A partir de Android 7.0 (nivel de API 24), la plataforma realizó una corrección en el serialVersionUID predeterminado para objetos serializables. Esta corrección no afectó a las apps orientadas al nivel de API 23 o inferior.

A partir de Android 10, si una app se orienta al nivel de API 23 o versiones anteriores y se basa en la serialVersionUID antigua, incorrecta y predeterminada, el sistema registra una advertencia y sugiere una corrección de código.

Específicamente, el sistema registra una advertencia si se cumplen todas las siguientes condiciones:

• La app se orienta al nivel de API 23 o a una versión anterior.
• Se serializa una clase.
• La clase serializada usa el serialVersionUID predeterminado, en lugar de configurar un serialVersionUID de forma explícita.
• El serialVersionUID predeterminado es diferente del serialVersionUID si la app se orientara al nivel de API 24 o superior.

Esta advertencia se registra una vez por cada clase afectada. El mensaje de advertencia incluye una solución sugerida, que es configurar de forma explícita serialVersionUID en el valor predeterminado que se calcularía si la app se orientara al nivel de API 24 o uno superior. Si usas esa corrección, puedes asegurarte de que, si un objeto de esa clase se serializa en una app orientada al nivel de API 23 o versiones anteriores, las apps orientadas a la versión 24 o versiones posteriores leerán correctamente el objeto, y viceversa.

Cambios en java.io.FileChannel.map()

A partir de Android 10, FileChannel.map() no es compatible con archivos no estándar, como /dev/zero, cuyo tamaño no se puede cambiar con truncate(). Las versiones anteriores de Android no mostraban el "errno" de truncate(), pero Android 10 genera una IOException. Si necesitas el comportamiento anterior, debes usar código nativo.