La segunda versión beta de Android 17

Hoy lanzamos la segunda versión beta de Android 17, y continuamos nuestro trabajo para crear una plataforma que priorice la privacidad, la seguridad y el rendimiento mejorado. Esta actualización ofrece una variedad de capacidades nuevas, incluidas la API de EyeDropper y un selector de contactos que preserva la privacidad. También agregamos APIs de rango avanzado, de transferencia multidispositivo y mucho más.

Esta versión continúa el cambio en nuestra cadencia de lanzamiento, siguiendo este lanzamiento anual principal del SDK en el segundo trimestre con una actualización menor del SDK.

Experiencia del usuario y IU del sistema

Burbujas

Las burbujas son una función de modo de ventanas que ofrece una nueva experiencia de IU flotante independiente de la API de burbujas de mensajería. Los usuarios pueden crear una burbuja de app en su teléfono, dispositivo plegable o tablet manteniendo presionado el ícono de la app en el selector. En pantallas grandes, hay una barra de burbujas como parte de la barra de tareas en la que los usuarios pueden organizar, moverse entre ellas y moverlas hacia y desde puntos anclados en la pantalla.

Debes seguir los lineamientos para admitir el modo multiventana para asegurarte de que tus apps funcionen correctamente como burbujas.

Las burbujas aún no están completamente habilitadas en la versión beta 2. Búscalas en una compilación futura de Android 17.

API de EyeDropper

Una nueva API de EyeDropper a nivel del sistema permite que tu app solicite un color de cualquier píxel en la pantalla sin requerir permisos sensibles de captura de pantalla.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

Selector de contactos

Un nuevo selector de contactos a nivel del sistema a través de ACTION_PICK_CONTACTS otorga acceso de lectura temporal basado en la sesión solo a los campos de datos específicos solicitados por el usuario, lo que reduce la necesidad de los permisos READ_CONTACTS amplios. También permite selecciones de los perfiles personales o de trabajo del dispositivo.

val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

Compatibilidad más sencilla de captura de puntero con paneles táctiles

Anteriormente, los paneles táctiles informaban eventos de una manera muy diferente a los mouses cuando una app había capturado el puntero, informando las ubicaciones de los dedos en el panel en lugar de los movimientos relativos que informaría un mouse. Esto dificultaba bastante la compatibilidad adecuada con los paneles táctiles en los juegos en primera persona. Ahora, de forma predeterminada, el sistema reconocerá el movimiento del puntero y los gestos de desplazamiento cuando se capture el panel táctil, y los informará como eventos del mouse. Aún puedes solicitar los datos de ubicación de los dedos antiguos y detallados solicitando explícitamente la captura en el nuevo modo "absoluto".

// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

Límites de reposo del selector interactivo

Si llamas a getInitialRestingBounds en ChooserSession de Android, tu app puede identificar la posición de destino que ocupa el selector después de que se completan las animaciones y la carga de datos, lo que permite mejores ajustes de la IU.

Conectividad y multidispositivo

Transferencia de apps multidispositivo

Una nueva API de Handoff te permite especificar el estado de la aplicación que se reanudará en otro dispositivo, como una tablet Android. Cuando se habilita, el sistema sincroniza el estado a través de CompanionDeviceManager y muestra una sugerencia de transferencia en el selector de los dispositivos cercanos del usuario. Esta función está diseñada para ofrecer una continuidad de tareas sin problemas, lo que permite a los usuarios retomar exactamente donde lo dejaron en su flujo de trabajo en todo el ecosistema de Android. De manera fundamental, Handoff admite transiciones nativas de app a app y de app a la Web, lo que proporciona máxima flexibilidad y garantiza una experiencia completa, incluso si la app nativa no está instalada en el dispositivo receptor.

APIs de rango avanzado

Agregamos compatibilidad con 2 nuevas tecnologías de rango:

1. UWB DL-TDOA que permite que las apps usen UWB para la navegación en interiores. Esta superficie de API cumple con la especificación DL-TDOA 4.0 de FIRA (Fine Ranging Consortium) y permite la navegación en interiores que preserva la privacidad  (evita el seguimiento del dispositivo por el ancla).
2. Detección de proximidad que permite que las apps usen la nueva especificación de rango que adopta WFA (WiFi Alliance). Esta tecnología proporciona una confiabilidad y precisión mejoradas en comparación con la especificación de rango existente basada en Wifi Aware.

Mejoras en el plan de datos

Para optimizar la calidad de los medios, tu app ahora puede recuperar las tasas de datos máximas asignadas por el operador para las aplicaciones de transmisión con getStreamingAppMaxDownlinkKbps y getStreamingAppMaxUplinkKbps.

Funcionalidad principal, privacidad y rendimiento

Acceso a la red local

Android 17 presenta el permiso de tiempo de ejecución ACCESS_LOCAL_NETWORK para proteger a los usuarios del acceso no autorizado a la red local. Como esto se incluye en el grupo de permisos existente NEARBY_DEVICES, los usuarios que ya otorgaron otros permisos NEARBY_DEVICES no volverán a recibir la solicitud. Si declaras y solicitas este permiso, tu app puede descubrir dispositivos en la red de área local (LAN) y conectarse a ellos, como dispositivos de casa inteligente o receptores de transmisión. Esto evita que las apps maliciosas aprovechen el acceso sin restricciones a la red local para el seguimiento de usuarios y la creación de huellas digitales encubiertos. Las apps orientadas a Android 17 o versiones posteriores ahora tendrán dos rutas para mantener la comunicación con los dispositivos LAN: adoptar selectores de dispositivos que preserven la privacidad y que estén mediados por el sistema para omitir la solicitud de permiso o solicitar explícitamente este nuevo permiso en el tiempo de ejecución para mantener la comunicación de la red local.

Transmisión de cambio de compensación de zona horaria

Android ahora proporciona un intent de transmisión confiable, ACTION_TIMEZONE_OFFSET_CHANGED, que se activa cuando cambia la compensación de zona horaria del sistema, como durante las transiciones del horario de verano. Esto complementa los intents de transmisión existentes ACTION_TIME_CHANGED y ACTION_TIMEZONE_CHANGED, que se activan cuando cambia la marca de tiempo de Unix y cuando cambia el ID de la zona horaria, respectivamente.

Administración y priorización de la NPU

Las apps orientadas a Android 17 que necesitan acceder directamente a la NPU deben declarar FEATURE_NEURAL_PROCESSING_UNIT en su manifiesto para evitar que se bloquee el acceso a la NPU. Esto incluye apps que usan el delegado de NPU de LiteRT, SDKs específicos del proveedor y la NNAPI obsoleta.

Compatibilidad con ICU 78 y Unicode 17

Se actualizaron las bibliotecas principales de internacionalización a ICU 78, lo que amplió la compatibilidad con secuencias de comandos, caracteres y bloques de emojis nuevos, y permitió el formato directo de objetos de tiempo.

Protección de OTP por SMS

Android está expandiendo su protección de OTP por SMS retrasando automáticamente el acceso a los mensajes SMS con OTP. Anteriormente, la protección se centraba principalmente en el formato de SMS Retriever, en el que la entrega de mensajes que contienen un hash de SMS Retriever se retrasa durante tres horas para la mayoría de las apps. Sin embargo, para ciertas apps, como la app de SMS predeterminada, etc., y la app que corresponde al hash, están exentas de este retraso. Esta actualización extiende la protección a todos los mensajes SMS con OTP. En la mayoría de las apps, solo se podrá acceder a los mensajes SMS que contengan una OTP después de un retraso de tres horas para evitar el secuestro de OTP. Se retendrá la transmisión SMS_RECEIVED_ACTION y se filtrarán las consultas de la base de datos del proveedor de SMS. El mensaje SMS estará disponible para estas apps después del retraso. 

Acceso retrasado a mensajes SMS con formato WebOTP

Si la app tiene permiso para leer mensajes SMS, pero no es el destinatario previsto de la OTP (según lo determinado por la verificación de dominio), solo se podrá acceder al mensaje SMS con formato WebOTP después de que hayan transcurrido tres horas. Este cambio está diseñado para mejorar la seguridad del usuario, ya que garantiza que solo las apps asociadas con el dominio mencionado en el mensaje puedan leer el código de verificación de forma programática. Este cambio se aplica a todas las apps, independientemente de su nivel de API objetivo.

Acceso retrasado a mensajes SMS estándar con OTP

En el caso de los mensajes SMS que contienen una OTP que no usan los formatos WebOTP o SMS Retriever, solo se podrá acceder al SMS de OTP después de tres horas para la mayoría de las apps. Este cambio solo se aplica a las apps orientadas a Android 17 (nivel de API 37) o versiones posteriores.

Ciertas apps, como la app de SMS predeterminada, la app del Asistente, junto con las apps complementarias de dispositivos conectados, etc., estarán exentas de este retraso.

Todas las apps que dependen de la lectura de mensajes SMS para la extracción de OTP deben hacer la transición al uso de las APIs de SMS Retriever o de consentimiento del usuario de SMS para garantizar la funcionalidad continua.

Cronograma de Android 17

Pasaremos rápidamente de esta versión beta a nuestro hito de estabilidad de la plataforma, previsto para marzo. En este hito, entregaremos las APIs finales del SDK/NDK. A partir de ese momento, tu app puede orientarse al SDK 37 y publicarse en Google Play para ayudarte a completar las pruebas y recopilar comentarios de los usuarios en los meses anteriores a la disponibilidad general de Android 17.

Un año de lanzamientos

Planeamos que Android 17 siga recibiendo actualizaciones en una serie de lanzamientos trimestrales. El próximo lanzamiento en el segundo trimestre es el único en el que presentamos cambios de comportamiento planificados que interrumpen la app. Planeamos lanzar una versión menor del SDK en el cuarto trimestre con APIs y funciones adicionales.

Comienza a usar Android 17

Puedes inscribir cualquier dispositivo Pixel compatible para obtener esta y futuras actualizaciones de la versión beta de Android de forma inalámbrica. Si no tienes un dispositivo Pixel, puedes usar las imágenes del sistema de 64 bits con Android Emulator en Android Studio.

Si actualmente estás en el programa de versiones beta de Android, recibirás una actualización inalámbrica a la versión beta 2.

Si tienes la versión beta de Android 26Q1 y quieres obtener la versión estable final de 26Q1 y salir de la versión beta, debes ignorar la actualización inalámbrica a la versión beta 2 de 26Q2 y esperar el lanzamiento de 26Q1.

Queremos recibir tus comentarios, así que informa los problemas y envía solicitudes de funciones en la página de comentarios. Cuanto antes recibamos tus comentarios, más podremos incluir en nuestro trabajo en la versión final.

Para que tengas la mejor experiencia de desarrollo con Android 17, te recomendamos que uses la versión preliminar más reciente de Android Studio (Panda). Una vez que hayas configurado todo, haz lo siguiente:

• Compila con el nuevo SDK, prueba en entornos de CI y notifica cualquier problema en nuestra herramienta de seguimiento en la página de comentarios.
• Prueba tu app actual para verificar la compatibilidad, descubre si tu app se ve afectada por los cambios en Android 17, instala tu app en un dispositivo o emulador que ejecute Android 17 y pruébala de forma exhaustiva.

Actualizaremos las imágenes del sistema de vista previa o beta y el SDK con regularidad durante el ciclo de lanzamiento de Android 17. Una vez que hayas instalado una compilación beta, recibirás automáticamente actualizaciones futuras

de forma inalámbrica para todas las versiones preliminares y betas posteriores.

Para obtener información completa, visita el sitio para desarrolladores de Android 17.

Únete a la conversación

A medida que avanzamos hacia la estabilidad de la plataforma y la disponibilidad general de Android 17 más adelante este año, tus comentarios siguen siendo nuestro recurso más valioso. Ya seas un usuario pionero en el canal Canary o un desarrollador de apps que realiza pruebas en la versión beta 2, considera unirte a nuestras comunidades y enviar comentarios. Queremos saber tu opinión.