Segunda versión beta de Android 17

Hoy lanzamos la segunda versión beta de Android 17, con la que continuamos nuestro trabajo para crear una plataforma que priorice la privacidad, la seguridad y un rendimiento mejorado. Esta actualización ofrece una variedad de funciones nuevas, como la API de EyeDropper y un selector de contactos que preserva la privacidad. También agregaremos APIs de medición de distancia avanzada, transferencia entre dispositivos y mucho más.

Esta versión continúa con el cambio en nuestro ritmo de lanzamientos, después de este lanzamiento anual de la versión principal del SDK en el segundo trimestre con una actualización menor del SDK.

Experiencia del usuario y la IU del sistema

Burbujas

Las burbujas son una función del 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 las pantallas grandes, hay una barra de burbujas como parte de la barra de tareas en la que los usuarios pueden organizar las burbujas, moverse entre ellas y moverlas hacia y desde puntos fijos en la pantalla.

Debes seguir los lineamientos para admitir el modo multiventana y 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 de la pantalla sin necesidad de 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 que solicita el usuario, lo que reduce la necesidad de los permisos amplios de READ_CONTACTS. También permite seleccionar elementos 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 la captura de puntero con paneles táctiles

Anteriormente, los paneles táctiles informaban los eventos de una manera muy diferente a la de los mouse cuando una app capturaba el puntero, ya que informaban las ubicaciones de los dedos en el panel en lugar de los movimientos relativos que informaría un mouse. Esto dificultaba 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 antiguos y detallados de la ubicación de los dedos solicitando de forma explícita 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 realizar mejores ajustes de la IU.

Conectividad y multidispositivo

Transferencia de apps entre dispositivos

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 se diseñó para ofrecer una continuidad de tareas sin interrupciones, lo que permite que los usuarios retomen su flujo de trabajo exactamente donde lo dejaron en todo el ecosistema de Android. Es fundamental destacar que Handoff admite transiciones de aplicación nativa a aplicación nativa y resguardo de aplicación a web, lo que proporciona la máxima flexibilidad y garantiza una experiencia completa, incluso si la aplicación nativa no está instalada en el dispositivo receptor.

APIs de medición de distancia avanzadas

Agregaremos compatibilidad con 2 tecnologías de medición de distancia nuevas: 

1. DL-TDOA de UWB, que permite que las apps usen UWB para la navegación en interiores Esta plataforma de API cumple con la especificación DL-TDOA de FIRA (Fine Ranging Consortium) 4.0 y permite la navegación en interiores que preserva la privacidad  (evita que el ancla realice un seguimiento del dispositivo).
2. Detección de proximidad, que permite que las apps usen la nueva especificación de rango que está adoptando la WFA (WiFi Alliance) Esta tecnología proporciona una mayor confiabilidad y precisión en comparación con la especificación de medición de distancia existente basada en Wi-Fi Aware.

Mejoras en los planes de datos

Para optimizar la calidad del contenido multimedia, 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. Debido a que esto se incluye en el grupo de permisos NEARBY_DEVICES existente, no se volverá a solicitar a los usuarios que ya hayan otorgado otros permisos de NEARBY_DEVICES. Si declaras y solicitas este permiso, tu app podrá descubrir dispositivos en la red de área local (LAN), como dispositivos inteligentes para la casa o receptores de transmisión, y conectarse a ellos. Esto evita que las apps maliciosas aprovechen el acceso sin restricciones a la red local para realizar un seguimiento encubierto de los usuarios y crear huellas digitales. Las apps orientadas a Android 17 o versiones posteriores ahora tendrán dos formas de mantener la comunicación con los dispositivos de LAN: adoptar selectores de dispositivos que preserven la privacidad y estén mediados por el sistema para omitir el mensaje de permiso, o solicitar explícitamente este nuevo permiso durante el tiempo de ejecución para mantener la comunicación con la red local.

Transmisión de cambio de diferencia de zona horaria

Android ahora proporciona un intent de transmisión confiable, ACTION_TIMEZONE_OFFSET_CHANGED, que se activa cuando cambia el desfase de la 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 les bloquee el acceso a la NPU. Esto incluye las apps que usan el delegado de NPU de LiteRT, los SDKs específicos del proveedor y la NNAPI obsoleta.

Compatibilidad con ICU 78 y Unicode 17

Las bibliotecas de internacionalización principales se actualizaron a ICU 78, lo que amplía la compatibilidad con nuevas secuencias de comandos, caracteres y bloques de emojis, y habilita 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 tres horas para la mayoría de las apps. Sin embargo, algunas apps, como la app de SMS predeterminada, etc., y la app que corresponde al hash están exentas de esta demora. 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 ayudar a evitar el robo 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 de la demora. 

Acceso retrasado a los mensajes SMS con formato de WebOTP

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

Acceso retrasado a los mensajes SMS estándar con OTP

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

Ciertas apps, como la de SMS predeterminada, la aplicación de asistencia, las apps complementarias de dispositivos conectados, etc., estarán exentas de esta demora.

Todas las apps que dependen de la lectura de mensajes SMS para la extracción de OTP deben realizar la transición para usar las APIs de SMS Retriever o SMS User Consent para garantizar la funcionalidad continua.

Cronograma de Android 17

Pasaremos rápidamente de esta versión beta al hito de estabilidad de la plataforma, previsto para marzo. En este hito, entregaremos las APIs finales del SDK y el NDK. A partir de ese momento, tu app podrá orientarse al SDK 37 y publicarse en Google Play para ayudarte a completar las pruebas y recopilar comentarios de los usuarios en los meses previos 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. La próxima versión del segundo trimestre es la única en la que introduciremos cambios de comportamiento planificados que interrumpen el funcionamiento de las apps. Planeamos lanzar una versión secundaria 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 las 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 participas 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 a que se lance la versión 26Q1.

Queremos conocer tu opinión, 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 para la versión final.

Para obtener 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 completado la configuración, te recomendamos que hagas lo siguiente:

• Compila con el SDK nuevo, realiza pruebas en entornos de CI y, si encuentras algún problema, infórmalo en nuestra herramienta de seguimiento en la página de comentarios.
• Prueba la compatibilidad de tu app actual, averigua si se ve afectada por los cambios en Android 17, instálala en un dispositivo o emulador que ejecute Android 17 y pruébala de forma exhaustiva.

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

inalámbricas 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 nos acercamos a la estabilidad de la plataforma y a la disponibilidad general de Android 17 más adelante este año, tus comentarios siguen siendo nuestro recurso más valioso. Ya sea que 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.