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 optimizado. 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 rango avanzado, transferencia multidispositivo y mucho más.

Esta versión continúa el cambio en nuestra cadencia de lanzamientos, ya que, después de este lanzamiento anual del SDK principal en el segundo trimestre, se lanzará una actualización secundaria 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 una 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 burbujas y moverlas hacia y desde puntos anclados 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úscalos en una compilación futura de Android 17.

API de EyeDropper

Una nueva API de cuentagotas 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 solicitados por el usuario, lo que reduce la necesidad de los permisos amplios READ_CONTACTS. También permite seleccionar 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 del puntero con paneles táctiles

Anteriormente, los pads táctiles informaban eventos de una manera muy diferente a los mouse cuando una app había capturado el puntero, ya que informaban las ubicaciones de los dedos en el pad en lugar de los movimientos relativos que informaría un mouse. Esto dificultó la compatibilidad adecuada con los paneles táctiles en los juegos en primera persona. Ahora, de forma predeterminada, el sistema reconocerá los gestos de desplazamiento y movimiento del puntero cuando se capture el panel táctil, y los registrará como eventos del mouse. Aún puedes solicitar los datos de ubicación detallados de los dedos anteriores 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 descanso 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 esta opción, 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. Es fundamental destacar que Handoff admite tanto las transiciones nativas de aplicación a aplicación como la alternativa de aplicación a la 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 rango avanzadas

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

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 parte de la baliza).
2. Detección de proximidad, que permite que las apps usen la nueva especificación de medición de distancia que adoptó la WFA (Wi-Fi Alliance). Esta tecnología proporciona una mayor confiabilidad y precisión en comparación con la especificación de rango existente basada en Wifi Aware.

Mejoras en los planes 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 introduce el permiso de tiempo de ejecución ACCESS_LOCAL_NETWORK para proteger a los usuarios del acceso no autorizado a la red local. Dado que esto se incluye en el grupo de permisos existente NEARBY_DEVICES, los usuarios que ya otorgaron otros permisos de NEARBY_DEVICES no recibirán nuevamente la solicitud. Si declaras y solicitas este permiso, tu app podrá descubrir dispositivos en la red de área local (LAN) y conectarse a ellos, como dispositivos inteligentes para la casa o receptores de transmisión. Esto evita que las apps maliciosas exploten el acceso sin restricciones a la red local para realizar un seguimiento de usuarios y una creación de huellas digitales encubiertos. Las apps que se segmenten para Android 17 o versiones posteriores ahora tendrán dos rutas para mantener la comunicación con los dispositivos LAN: adoptar selectores de dispositivos mediados por el sistema que preserven la privacidad para omitir el mensaje de permiso o solicitar explícitamente este nuevo permiso en el tiempo de ejecución para mantener la comunicación de red local.

Transmisión del cambio de desfase de zona horaria

Android ahora proporciona una intención de transmisión confiable, ACTION_TIMEZONE_OFFSET_CHANGED, que se activa cuando cambia el desfase de zona horaria del sistema, por ejemplo, durante las transiciones del horario de verano. Esto complementa las 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 que se segmentan para Android 17 y necesitan acceder directamente a la NPU deben declarar FEATURE_NEURAL_PROCESSING_UNIT en su manifiesto para evitar que se bloquee su 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

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

Protección contra 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, 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 una demora de tres horas para ayudar a evitar el secuestro de OTP. Se retendrá la transmisión de SMS_RECEIVED_ACTION y se filtrarán las consultas de la base de datos del proveedor de SMS. El mensaje de SMS estará disponible para estas apps después de la demora. 

Acceso retrasado a los 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 determina la verificación de dominio), solo se podrá acceder al mensaje SMS con formato WebOTP después de que transcurran 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 los mensajes SMS estándar con OTP

En el caso de los mensajes SMS que contienen una OTP y que 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 segmentan Android 17 (nivel de API 37) o versiones posteriores.

Ciertas apps, como la de SMS predeterminada, la app del asistente y 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 migrar al uso de las APIs de SMS Retriever o SMS User Consent para garantizar la continuidad de la funcionalidad.

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 y el NDK. A partir de ese momento, tu app podrá segmentar el SDK 37 y publicarse en Google Play para ayudarte a completar las pruebas y recopilar comentarios de los usuarios durante los meses previos a la disponibilidad general de Android 17.

Un año de lanzamientos

Tenemos previsto 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 se introducirán cambios de comportamiento rotundos planificados en la app. Tenemos previsto 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 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 el lanzamiento de 26Q1.

Queremos conocer 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 sobre 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 configurado todo, haz lo siguiente:

• Compila con el nuevo SDK, realiza pruebas en entornos de CI y, luego, informa cualquier problema en nuestro sistema de seguimiento en la página de comentarios.
• Prueba la compatibilidad de tu app actual, descubre si se ve afectada por los cambios en Android 17, instálala en un dispositivo o emulador que ejecute Android 17 y pruébala exhaustivamente.

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

inalámbricas para todas las versiones Beta y de vista previa 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 activo más valioso. Ya sea que seas un usuario pionero en el canal Canary o un desarrollador de apps que realiza pruebas en Beta 2, considera unirte a nuestras comunidades y enviar comentarios. Queremos saber tu opinión.