Cambios de comportamiento: todas las apps

Android 10 incluye cambios de comportamiento que podrían afectar tu app. Los cambios que se detallan 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 admitir 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 orientadas al nivel 29 a fin de obtener detalles.

Nota: Además de los mencionados en esta página, Android 10 presenta una gran cantidad de cambios y restricciones basados en la privacidad, entre los que se incluyen 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 este tipo de interfaces, puedes probarla para averiguarlo. 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 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, todas las apps del dispositivo se verán afectadas, independientemente de que la app se oriente al nivel de API 29. Por ejemplo, si el usuario desliza el dedo desde el borde de la pantalla, el sistema interpretará 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 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) no está permitido el uso de reubicaciones de texto en objetos compartidos. El código se debe cargar como está y no se debe modificar. 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 de acceso 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, con lib/ reemplazado 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 mediante la lectura de /proc/self/maps o elementos similares, lo cual no es habitual. Sin embargo, algunas apps lo hacen como parte de su proceso antihackeo. 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 refuerzo 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 este comportamiento causó una falla, examina el archivo de tombstone 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 con el objetivo de realizar operaciones como la inspección de memoria, es posible marcar los segmentos de solo ejecución como de lectura y ejecución mediante una llamada a mprotect(). Sin embargo, te recomendamos que vuelvas a configurarla como solo de ejecución más adelante, ya que esta configuración del permiso de acceso proporciona una mejor protección para la 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 las 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 una SSLHandshakeException en versiones anteriores de Android, estas instancias, en cambio, arrojan un 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 llamando 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. La AC raíz no emite 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 que usa 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 algoritmos de cifrado AES/GCM/NoPadding y ChaCha20/Poly1305/NoPadding devuelven 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. Debido a las mejoras en las implementaciones del servidor TLS, no recomendamos intentar 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 durante el registro porque eran fijas, 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 del cliente debe conocer la dirección IPv6 y el puerto del servidor. Anteriormente, esto debía comunicarse fuera de banda, por ejemplo, mediante mensajería de nivel 2 o Bluetooth con reconocimiento de Wi-Fi, o detectarse dentro de la banda mediante 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 obtén o establece 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 información de puertos 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 la dirección 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 memoria excesiva, lo que es particularmente perjudicial 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, a las apps que aún no tienen ese permiso no se les puede otorgar una vez que se actualiza 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 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 cualquier app orientada a Android 5.1 (nivel de API 22) o versiones anteriores. Si la app requiere que el usuario otorgue permisos, este también podrá 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 de destino 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 o no admiten ninguno de ellos.

Nota: Las apps y las bibliotecas deben cruzar el conjunto de conjuntos de algoritmos de cifrado que desees con el valor que se muestra de getSupportedCipherSuites() para proteger el futuro de la selección de conjuntos de algoritmos de cifrado con respecto a eliminaciones futuras.

Uso de apps

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

• Uso -Estadísticas de uso de la app 0 Además, Android 10 realiza un seguimiento correcto del uso de las apps instantáneas.

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

A partir de Android 10, la biblioteca android.preference dejó de estar disponible. En su lugar, los desarrolladores deben usar la biblioteca de preferencias 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 mostraban un IllegalStateException si se invocaban después de una llamada a end(). En Android 10, estos métodos arrojan 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() de ZipOutputStream no arroja un ZipException si intenta escribir un flujo 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, el dispositivo físico también está en orientación vertical, como se describe en la orientación de la cámara. Esta suposición anteriormente era segura, pero cambió con la expansión de los factores de forma disponibles, como los dispositivos plegables. Esa suposición en estos dispositivos puede llevar a que el visor de la cámara se gire o ajuste de manera incorrecta (o ambas).

Las aplicaciones que se orientan al nivel de API 24 o superior deben establecer 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 sus 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 haya cargado completamente o que haya pasado de estar casi completamente cargado a estar casi totalmente cargado.

Antes de Android 10, las estadísticas de uso de batería se restablecen cada vez que el dispositivo se desconecta, independientemente de los pequeños cambios que se hayan producido en el nivel de la batería.

Baja de Android Beam

En Android 10, Android Beam dejará de estar disponible oficialmente, una función anterior para iniciar el uso compartido de datos entre dispositivos a través de la Comunicación de campo cercano (NFC). También dejarán de estar disponibles varias APIs de NFC relacionadas. De manera opcional, Android Beam sigue disponible para los socios fabricantes de dispositivos que deseen 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 de comportamiento de java.util.regex.Matcher y Patterns

Se cambió el resultado de split() para que ya no comience con un String vacío ("") cuando haya 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 antes mostraba {"", "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 argumentos no válidos:

• appendReplacement(StringBuffer, String) ahora arroja un IllegalArgumentException en lugar de IndexOutOfBoundsException si el String de reemplazo termina con una barra inversa única, lo que es ilegal. Ahora se arroja la misma excepción si el String de reemplazo termina con una $. Anteriormente, no se arrojaba 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, 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 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 para objetos serializados con el SUID predeterminado

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

A partir de Android 10, si una app se orienta al nivel de API 23 o versiones anteriores, y depende de la serialVersionUID predeterminada, incorrecta y anterior, 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 valor predeterminado de serialVersionUID es diferente del que sería serialVersionUID si la app se orientara al nivel de API 24 o superior.

Esta advertencia se registra una vez para cada clase afectada. El mensaje de advertencia incluye una corrección sugerida, que consiste en establecer de forma explícita serialVersionUID en el valor predeterminado que se calcularía si la app se segmenta al nivel de API 24 o superior. Con esa corrección, puedes asegurarte de que, si un objeto de esa clase se serializa en una app que se orienta al nivel de API 23 o versiones anteriores, las apps orientadas al nivel 24 o versiones posteriores leerán el objeto correctamente, y viceversa.

Cambios en java.io.FileChannel.map()

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