Cambios de comportamiento: todas las apps

Android 10 incluye cambios de comportamiento que podrían afectar a tu app. Los cambios que se indican en esta página se aplican a tu app cuando se ejecuta en Android 10, independientemente de la targetSdkVersion. Debes 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 mencionados 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 sobre la 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 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 certeza si tu app usa interfaces que no pertenecen al SDK, puedes probarla para averiguarlo. Si tu app depende de interfaces que no pertenecen al SDK, debes comenzar a planificar una migración hacia alternativas de 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 de interfaces que no pertenecen al SDK para Android 10 y las restricciones para 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, esto afectará a todas las apps del dispositivo, independientemente de si la app se orienta al nivel de API 29 o no. Por ejemplo, si el usuario desliza el dedo desde el borde de la pantalla, el sistema interpreta ese gesto como una navegación hacia atrás, a menos que una app anule ese gesto específicamente para partes de la pantalla.

Para que tu app sea compatible con la navegación por gestos, te recomendamos extender el contenido de la app de borde a borde y manejar los gestos conflictivos de manera adecuada. Si deseas obtener más detalles, consulta la documentación sobre la 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 como está y no debe modificarse. 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. Las apps que dependían de que las rutas fueran archivos normales podrían fallar:

• /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, y se reemplaza lib/ 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 /apex/… se deben agregar 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 memoria de solo ejecución (no de lectura) como técnica de endurecimiento contra ataques de reutilización de código. Si tu app realiza operaciones de lectura en 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 este comportamiento causó una falla, examina el archivo de exclusión relacionado en /data/tombstones/. Una falla de solo ejecución 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 llamando a mprotect(). Sin embargo, te recomendamos que vuelvas a configurarlo como de solo ejecución después, ya que esta configuración de permiso de acceso proporciona una mejor protección para 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. Los conjuntos de algoritmos de cifrado de TLS 1.3 admitidos 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 muestran una 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 la 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 cifrados 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 posterior. Debido a las mejoras en las implementaciones del servidor TLS, no recomendamos probar el resguardo de TLS externo. En su lugar, recomendamos basarse 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 fijas:

• 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 porque 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 agrega compatibilidad para facilitar la creación de un Socket TCP/UDP mediante rutas de datos de reconocimiento de Wi-Fi. Para crear un socket TCP/UDP que se conecte a ServerSocket, el dispositivo cliente debe conocer la dirección IPv6 y el puerto del servidor. Antes, esto debía comunicarse fuera de banda, por ejemplo, a través de mensajería de capa 2 o Bluetooth, o detectarse dentro de la banda con otros protocolos, como mDNS. Con Android 10, la información se puede comunicar como parte de la configuración de la red.

El servidor puede realizar cualquiera de las siguientes acciones:

• Inicializa un ServerSocket y configura u obtén 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 recibir 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 el permiso incluso si el dispositivo se actualiza a Android 10. Sin embargo, las apps que aún 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 lleva al usuario a la pantalla de Configuración, que 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 muestra un valor falso. Estas restricciones no se aplican a las 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, también se le da la oportunidad de ajustar los permisos de la app antes de que esta pueda ejecutarse por primera vez.

Debido a los requisitos de la API objetivo de Google Play, un usuario solo verá estas advertencias cuando ejecute 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 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:

• Mejoras en las estadísticas de uso de las apps Además, Android 10 realiza un seguimiento correcto del uso de las apps instantáneas.

• Escala de grises por app:

• Estado de distracción por app:

• Suspensión y reproducción:

Cambios en la conexión HTTPS

Si una app que ejecuta Android 10 pasa null a setSSLSocketFactory(), se produce una IllegalArgumentException. En versiones anteriores, pasar null a setSSLSocketFactory() tenía el mismo efecto que pasar la fábrica predeterminada 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 pública de ejemplo 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 en su lugar.

ZipFile

En Android 10 y versiones posteriores, el constructor para ZipFile que toma argumentos de tipo File, int y Charset no arroja un ZipException si el archivo ZIP proporcionado no contiene ningún archivo.

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 eso cambió con la expansión de los factores de forma disponibles, como los dispositivos plegables. Esa suposición en estos dispositivos puede provocar que la pantalla del visor de la cámara se ajuste o rote (o ambas) de forma incorrecta.

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 cuando el dispositivo se cargó por completo o que el dispositivo pasó de estar casi agotado a tener casi todo cargado.

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 batería.

Baja de Android Beam

En Android 10, dejará de estar disponible oficialmente Android Beam, una función más antigua para iniciar el uso compartido de datos entre dispositivos mediante la Comunicación de campo cercano (NFC). También daremos de baja varias de las APIs de NFC relacionadas. De manera opcional, Android Beam sigue disponible para los socios fabricantes de dispositivos que quieran usarlo, pero ya no está en desarrollo activo. Sin embargo, Android seguirá admitiendo otras APIs 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 patrón

Se modificó el resultado de split() para que ya no comience con un String vacío (“”) 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 arroja una IllegalArgumentException en lugar de IndexOutOfBoundsException si el String de reemplazo termina con una sola barra inversa, lo cual es ilegal. Ahora se arroja la misma excepción si el String de reemplazo termina con un $. Anteriormente, no se mostraba ninguna excepción en esta situación.
• replaceFirst(null) ya no llama a reset() en Matcher si arroja una NullPointerException. Ahora también se arroja NullPointerException cuando no hay coincidencia. Anteriormente, se lanzaba solo cuando había una coincidencia.
• start(int group), end(int group) y group(int group) ahora arrojan una IndexOutOfBoundsException más general si el índice de 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 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 el SUID predeterminado

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

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 condiciones siguientes:

• La app tiene como objetivo el nivel de API 23 o uno anterior.
• Una clase está serializada.
• 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 corrección sugerida, que consiste en establecer explícitamente serialVersionUID en el valor predeterminado que se calcularía si la app se orientara al nivel de API 24 o 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 que mostraba truncate(), pero Android 10 genera una IOException. Si necesitas el comportamiento anterior, debes usar código nativo.