Hoy lanzamos la segunda beta de Android 17, con la que seguimos trabajando para crear una plataforma que priorice la privacidad, la seguridad y el rendimiento optimizado. Esta actualización ofrece una serie de nuevas funciones, como la API EyeDropper y un selector de contactos que protege la privacidad. También vamos a añadir APIs de localización avanzada y de transferencia multidispositivo, entre otras.

Esta versión continúa el cambio en nuestra cadencia de lanzamientos. Tras esta versión principal anual del SDK en el segundo trimestre, lanzaremos una actualización menor del SDK.

Experiencia de usuario e interfaz de usuario del sistema

Burbujas

Burbujas es una función de modo de ventanas que ofrece una nueva experiencia de interfaz de usuario flotante independiente de la API de burbujas de mensajes. Los usuarios pueden crear una burbuja de aplicación en su teléfono, plegable o tablet manteniendo pulsado el icono de la aplicación en el Launcher. En las pantallas grandes, hay una barra de burbujas que forma parte de la barra de tareas, donde los usuarios pueden organizar y mover las burbujas, así como desplazarse entre ellas y moverlas a los puntos de anclaje de la pantalla y viceversa.

Debes seguir las directrices para admitir el modo multiventana para que tus aplicaciones funcionen correctamente como burbujas.

Las burbujas aún no están totalmente habilitadas en la beta 2. Estarán disponibles en una versión futura de Android 17.

API EyeDropper

Una nueva API cuentagotas a nivel del sistema permite que tu aplicación solicite un color de cualquier píxel de la pantalla sin necesidad de permisos de captura de pantalla sensibles.

  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 de sistema a través de ACTION_PICK_CONTACTS concede acceso de lectura temporal y basado en sesiones solo a los campos de datos específicos solicitados por el usuario, lo que reduce la necesidad de usar los permisos generales READ_CONTACTS. También permite seleccionar contenido 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 del puntero con paneles táctiles

Antes, los paneles táctiles registraban los eventos de una forma muy diferente a los ratones cuando una aplicación había capturado el puntero, ya que registraban las ubicaciones de los dedos en el panel en lugar de los movimientos relativos que registraría un ratón. Esto hacía que fuera bastante difícil admitir correctamente los trackpads en los juegos en primera persona. Ahora, de forma predeterminada, el sistema reconocerá los movimientos del puntero y los gestos de desplazamiento cuando se capture el panel táctil, y los registrará como eventos de ratón. Puedes seguir solicitando los datos antiguos y detallados de la ubicación de los dedos pidiendo 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

Al llamar a getInitialRestingBounds en ChooserSession de Android, tu aplicación puede identificar la posición de destino que ocupa el selector una vez que se han completado las animaciones y la carga de datos, lo que permite realizar mejores ajustes en la interfaz de usuario.

Conectividad y multidispositivo

Transferencia de aplicaciones multidispositivo

Una nueva API Handoff te permite especificar el estado de la aplicación que se va a reanudar en otro dispositivo, como una tablet Android. Si se habilita esta opción, el sistema sincroniza el estado a través de CompanionDeviceManager y muestra una sugerencia de transferencia en el menú de aplicaciones de los dispositivos cercanos del usuario. Esta función se ha diseñado para ofrecer una continuidad de las tareas fluida, lo que permite a los usuarios retomar exactamente donde lo dejaron en su flujo de trabajo en todo el ecosistema Android. Es fundamental que Handoff admita tanto las transiciones de aplicación a aplicación nativas como la redirección de aplicación a web, lo que proporciona la máxima flexibilidad y garantiza una experiencia completa aunque la aplicación nativa no esté instalada en el dispositivo receptor.

APIs de localización avanzada

Vamos a añadir compatibilidad con dos nuevas tecnologías de medición de distancias:

1. UWB DL-TDOA, que permite a las aplicaciones usar UWB para la navegación en interiores. Esta superficie de API cumple la especificación 4.0 DL-TDOA de FIRA (Fine Ranging Consortium) y permite la navegación en interiores protegiendo la privacidad  (evitando que la baliza rastree el dispositivo).
2. Detección de proximidad: permite que las aplicaciones usen la nueva especificación de distancia que está adoptando WFA (Wi-Fi Alliance). Esta tecnología ofrece una fiabilidad y una precisión mejoradas en comparación con la especificación de distancia basada en Wi-Fi Aware.

Mejoras en los planes de datos

Para optimizar la calidad multimedia, tu aplicación ahora puede obtener las tasas de datos máximas asignadas por el operador para aplicaciones de streaming mediante getStreamingAppMaxDownlinkKbps y getStreamingAppMaxUplinkKbps.

Funciones principales, privacidad y rendimiento

Acceso a la red local

Android 17 introduce el permiso de ejecución ACCESS_LOCAL_NETWORK para proteger a los usuarios frente a accesos no autorizados a la red local. Como esta acción se incluye en el grupo de permisos NEARBY_DEVICES, no se volverá a pedir a los usuarios que ya hayan concedido otros permisos NEARBY_DEVICES. Al declarar y solicitar este permiso, tu aplicación puede detectar dispositivos de la red de área local (LAN), como dispositivos domésticos inteligentes o receptores de emisión, y conectarse a ellos. De esta forma, se evita que las aplicaciones maliciosas exploten el acceso sin restricciones a la red local para el seguimiento de usuarios y la recogida de huella digital de forma encubierta. Las aplicaciones orientadas a Android 17 o versiones posteriores ahora tendrán dos formas de mantener la comunicación con los dispositivos de la LAN: adoptar selectores de dispositivos mediados por el sistema que protejan la privacidad para saltarse la petición de permiso o solicitar explícitamente este nuevo permiso en el tiempo de ejecución para mantener la comunicación con la red local.

Difusión de cambio de desfase de zona horaria

Android ahora proporciona un intent de emisión fiable, ACTION_TIMEZONE_OFFSET_CHANGED, que se activa cuando cambia el desfase de la zona horaria del sistema, como durante los cambios al horario de verano. Esto complementa las intenciones de emisión ACTION_TIME_CHANGED y ACTION_TIMEZONE_CHANGED, que se activan cuando cambia la marca de tiempo Unix y cuando cambia el ID de la zona horaria, respectivamente.

Gestión y priorización de la NPU

Las aplicaciones orientadas a Android 17 que necesiten 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 aplicaciones que usan el delegado de NPU de LiteRT, los SDKs específicos de proveedores y la NNAPI obsoleta.

Compatibilidad con ICU 78 y Unicode 17

Las bibliotecas de internacionalización principales se han actualizado a ICU 78, lo que amplía la compatibilidad con nuevas secuencias de comandos, caracteres y bloques de emojis, y permite el formato directo de objetos time.

Protección de OTP por SMS

Android va a ampliar su protección de contraseñas de un solo uso por SMS retrasando automáticamente el acceso a los mensajes SMS con contraseñas de un solo uso. Antes, la protección se centraba principalmente en el formato SMS Retriever, en el que el envío de mensajes que contienen un hash de SMS Retriever se retrasa tres horas en la mayoría de las aplicaciones. Sin embargo, algunas aplicaciones, como la aplicación de SMS predeterminada, etc., y la aplicación que corresponde al hash están exentas de este retraso. Esta actualización amplía la protección a todos los mensajes SMS con OTP. En la mayoría de las aplicaciones, solo se podrá acceder a los mensajes SMS que contengan una OTP después de un retraso de tres horas para evitar el robo de OTPs. La emisión SMS_RECEIVED_ACTION se retendrá y se filtrarán las consultas de la base de datos del proveedor de SMS. El mensaje SMS estará disponible en estas aplicaciones después del retraso. 

Acceso retrasado a mensajes SMS con formato WebOTP

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

Acceso retrasado a mensajes SMS estándar con OTP

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

Algunas aplicaciones, como la aplicación de SMS predeterminada, la aplicación de asistencia y las aplicaciones complementarias de dispositivos conectados, estarán exentas de este retraso.

Todas las aplicaciones que dependan de la lectura de mensajes SMS para extraer contraseñas de un solo uso deben migrar a las APIs SMS Retriever o SMS User Consent para seguir funcionando.

Calendario de Android 17

Vamos a pasar rápidamente de esta versión beta a la fase de estabilidad de la plataforma, que tenemos previsto alcanzar en marzo. En esta fase, proporcionaremos las APIs finales del SDK y del NDK. A partir de ese momento, tu aplicación podrá orientarse al SDK 37 y publicarse en Google Play para ayudarte a completar las pruebas y recoger los 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 vamos a introducir cambios en el comportamiento de las aplicaciones que pueden provocar errores. Tenemos previsto lanzar una versión menor del SDK en el cuarto trimestre con APIs y funciones adicionales.

Empezar a usar Android 17

Puedes registrar cualquier dispositivo Pixel compatible para recibir esta y futuras actualizaciones de Android Beta de forma inalámbrica. Si no tienes un dispositivo Pixel, puedes usar las imágenes del sistema de 64 bits con el emulador de Android en Android Studio.

Si estás participando en el programa beta de Android, se te ofrecerá una actualización OTA a la versión beta 2.

Si tienes la versión beta del primer trimestre del 2026 de Android y quieres obtener la versión estable final del primer trimestre del 2026 y salir de la versión beta, debes ignorar la actualización inalámbrica a la versión beta 2 del segundo trimestre del 2026 y esperar al lanzamiento del primer trimestre del 2026.

Nos gustaría recibir tus comentarios, así que informa de 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 disfrutar de 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 lo hayas configurado, te recomendamos que hagas lo siguiente:

• Compila con el nuevo SDK, haz pruebas en entornos de integración continua e informa de cualquier problema en nuestro sistema de seguimiento en la página de comentarios.
• Prueba la compatibilidad de tu aplicación actual, comprueba si se ve afectada por los cambios de Android 17 e instala tu aplicación en un dispositivo o emulador con Android 17 para probarla a fondo.

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

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.

Participa en la conversación

A medida que nos acercamos a la estabilidad de la plataforma y a la disponibilidad general de Android 17 a finales de este año, tus comentarios siguen siendo nuestro recurso más valioso. Tanto si eres de los primeros en adoptar el canal Canary como si eres desarrollador de aplicaciones y estás probando la versión beta 2, te recomendamos que te unas a nuestras comunidades y nos envíes tus comentarios. Tenemos muy en cuenta tus comentarios.