La primera beta de Android 17 (API 37), anunciada en el Android Developers Blog por Matthew McCullough, no solo trae funciones nuevas: cambia la forma de probarlas. Google deja atrás el modelo clásico de “Developer Preview” por un canal continuo llamado Android Canary. La idea se parece a pasar de recibir un periódico cada cierto tiempo a tener una cinta de noticias 24/7: las novedades llegan en cuanto superan pruebas internas, sin esperar al siguiente hito trimestral.
Este enfoque busca tres efectos prácticos para el ecosistema: acceso más rápido a APIs y comportamientos, una beta más “pulida” gracias al rodaje temprano, y pruebas más sencillas porque Canary admite actualizaciones OTA y encaja mejor en flujos de CI. Para equipos que viven de compilar, testear y volver a compilar, ese detalle es oro: reduce fricción y acorta el tiempo entre “lo he encontrado” y “ya lo reporté”.
En calendario, Google marca un paso acelerado hacia Platform Stability en marzo, momento en el que el SDK/NDK y los comportamientos orientados a apps quedan prácticamente cerrados. Y, como línea de continuidad, Android 17 seguirá recibiendo actualizaciones trimestrales, con un Q2 como el gran punto donde se concentrarán los cambios de comportamiento que podrían romper apps y un Q4 que apunta a un SDK menor con APIs y funciones nuevas.
Pantallas grandes: se acabó “no me adapto” cuando apuntes a API 37
Uno de los mensajes más contundentes de esta beta tiene que ver con apps adaptativas y pantallas grandes. Si tu aplicación apunta a SDK 37, Android 17 elimina el “opt-out” que permitía evitar restricciones de orientación y redimensionado en dispositivos con sw > 600 dp. Traducido a lenguaje de día a día: si tu app entra en una tablet, un plegable desplegado o un modo de ventanas tipo escritorio, ya no vale poner un candado para forzar un único formato.
Cuando tu app se ejecute en pantallas grandes (dimensión menor ≥ 600dp), el sistema ignorará una serie de atributos y llamadas que antes se usaban como muleta: valores de screenOrientation, setRequestedOrientation() y también controles sobre resizeableActivity, minAspectRatio y maxAspectRatio. El objetivo es que la interfaz aproveche el espacio disponible y respete la postura del dispositivo, algo que el usuario ya da por hecho cuando arrastra ventanas o divide pantalla.
Hay matices importantes. Esto no se aplica a pantallas menores de sw600dp, lo que cubre móviles “clásicos”. Los juegos quedan exentos si están categorizados como tal mediante android:appCategory. Y, por encima de todo, el usuario conserva el mando: puede optar por el comportamiento por defecto de la app o ajustarlo con los controles del sistema relacionados con el aspecto.
A nivel de desarrollo, la recomendación de Google es clara: probar con Android 17 Beta 1 en emuladores de Pixel Tablet o Pixel Fold, y también validar en Android 16 activando el marco de compatibilidad con UNIVERSAL_RESIZABLE_BY_DEFAULT. La metáfora útil aquí es la de una maleta: antes podías llevar solo una rígida; ahora necesitas una que se adapte al compartimento del tren, al maletero del coche y al cajón de casa sin romperse.
Menos reinicios de Activity: estabilidad para vídeo, entradas y estado
Otro cambio que puede sentirse “invisible” hasta que deja de fallar es la actualización en los reinicios de Activity por cambios de configuración. A partir de Android 17, el sistema dejará de reiniciar Activities por defecto en una serie de cambios que normalmente no exigen recrear UI, como teclado, navegación, tipo de UI (cuando solo cambia a modo escritorio), pantalla táctil o modo de color.
En lugar de reiniciar, las Activities reciben el aviso vía onConfigurationChanged. Para el usuario, esto puede significar menos cortes bruscos: un vídeo que no se interrumpe por un cambio menor, una entrada táctil que no “se pierde”, una experiencia más continua. Si una app depende de un reinicio completo para recargar recursos, ahora deberá declararlo de forma explícita con el nuevo atributo de manifiesto android:recreateOnConfigChanges, especificando qué cambios sí deben disparar el ciclo completo.
Rendimiento: colas de mensajes sin bloqueos y un ART más eficiente
En rendimiento, Android 17 mete mano en piezas profundas. La implementación de android.os.MessageQueue pasa a ser lock-free para apps que apunten a SDK 37 o superior. En cristiano: menos esperas por “cerraduras” internas significa más fluidez y menos frames perdidos. El coste está en una esquina poco recomendable pero real: si alguna librería o app hace reflexión sobre campos o métodos privados de MessageQueue, puede romperse.
El motor de ejecución también mejora. Android 17 introduce recolección de basura generacional en el colector Concurrent Mark-Compact de ART. La comparación cotidiana sería limpiar tu casa con dos rutinas: una rápida y frecuente para lo que se ensucia a diario, y otra profunda para todo el piso. Con más colecciones “jóvenes” ligeras y menos dependencia de limpiezas completas, se busca reducir coste de CPU y duración de pausas. Google señala que estas mejoras de ART también llegan, vía Google Play System updates, a muchísimos dispositivos desde Android 12 (API 31) en adelante, lo que amplía impacto más allá de quien instale Android 17.
También hay un endurecimiento curioso: los campos static final pasan a ser “final de verdad” para apps que apunten a Android 17. Intentar modificarlos por reflexión lanzará IllegalAccessException, y hacerlo por JNI con SetStatic<Type>Field causará un crash inmediato. Es un “no” tajante que permite al runtime optimizar con más agresividad.
En notificaciones, se restringe el tamaño de vistas personalizadas para ahorrar memoria, cerrando un agujero que permitía saltarse límites usando URIs. Y en diagnóstico aparece una herramienta útil: nuevos disparadores para ProfilingManager, como TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM y TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE, pensados para capturar datos cuando pasan cosas que de verdad importan.
Cámara y medios: transiciones suaves y vídeo con controles más finos
Android 17 intenta acercar capacidades “pro” a apps de cámara y media con cambios que atacan problemas típicos: transiciones con tirones, configuraciones pesadas, y control fino del vídeo.
En Camera2 aparece updateOutputConfigurations() en CameraCaptureSession, que permite adjuntar o separar superficies de salida sin reconstruir toda la sesión. Es una mejora con impacto directo en la experiencia: cambiar de modo foto a vídeo sin congelaciones visibles y sin cargar desde el inicio todas las superficies “por si acaso”. Es como cocinar con una encimera ordenada: sacas la sartén cuando toca, no cuando abres la nevera.
Para cámaras lógicas (las que combinan sensores físicos), llega el acceso a metadatos de todas las cámaras físicas activas, no solo de la primaria, mediante la clave LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS. Esto evita trucos y streams innecesarios para saber qué hace la cámara “seguidora” durante un zoom o un cambio de lente, y puede ayudar a optimizar recursos.
En vídeo, Android 17 incorpora soporte para VVC (Versatile Video Coding) con el tipo MIME video/vvc, perfiles en MediaCodecInfo e integración con MediaExtractor, condicionado a que el dispositivo tenga decodificación por hardware y drivers capaces. Y para grabación aparece setVideoEncodingQuality() en MediaRecorder, con un modo de calidad constante (CQ) que da más control que un bitrate fijo.
Otro endurecimiento: audio en segundo plano. El framework aplicará restricciones a reproducción, solicitudes de foco y APIs de volumen si la app no está en un ciclo de vida válido. Algunas llamadas fallarán en silencio y el audio focus devolverá AUDIOFOCUS_REQUEST_FAILED. El mensaje es claro: las interacciones de audio deben iniciarse de forma intencional por el usuario, cerrando caminos “sorpresa”.
Privacidad y seguridad: menos tráfico en claro y criptografía moderna
En privacidad y seguridad, Android 17 depreca android:usesCleartextTraffic. Si una app apunta a Android 17 o superior y dependía de usesCleartextTraffic="true" sin una Network Security Configuration, el comportamiento por defecto pasa a bloquear tráfico en claro. La recomendación es migrar a configuraciones de seguridad de red para control granular. Es como pasar de dejar la puerta entornada “porque nunca pasa nada” a instalar un cerradero con reglas claras de quién entra y por dónde.
En criptografía aparece una SPI pública para HPKE (Hybrid Public Key Encryption), combinando clave pública con cifrado simétrico AEAD, orientada a comunicaciones seguras modernas.
Conectividad, llamadas y dispositivos compañeros: más contexto y menos fricción
En conectividad y telecom, Android 17 mejora la integración del historial de llamadas VoIP con control de preferencias del usuario y soporte para URIs de avatar en el marcador del sistema, reforzando privacidad y también presentación visual.
El Wi-Fi ranging suma capacidades de detección de proximidad con medición continua y descubrimiento P2P seguro. En Wi-Fi Aware llegan APIs para “peer handles” y caché de PMKID para ranging seguro 11az, con la promesa de experiencias de proximidad más fiables.
En productividad, destacan los cambios para apps de dispositivos compañeros. CompanionDeviceManager incorpora perfiles para dispositivos médicos (solicitud de permisos necesarios con un toque) y para fitness trackers (DEVICE_PROFILE_FITNESS_TRACKER) con iconografía y rol más precisos. También se unifica el diálogo de asociación y permisos de Nearby, con setExtraPermissions para reducir el carrusel de ventanas emergentes que tanto fatiga a los usuarios.
Cómo empezar: Beta en Pixel, emulador y Android Studio Panda
Google invita a subirse a la beta con dispositivos Pixel compatibles mediante OTA, o con imágenes de sistema de 64 bits en el emulador. Para una experiencia de desarrollo más completa, recomienda la preview de Android Studio (Panda). El recorrido típico es el de siempre, solo que ahora conviene hacerlo antes: compilar con el nuevo SDK, integrar pruebas en CI, validar compatibilidad y dedicar tiempo a las áreas donde Android 17 aprieta más: adaptabilidad en pantallas grandes, cambios en recreación de Activity, audio en segundo plano y endurecimientos de seguridad.
Android 17 Beta 1, según el propio Android Developers Blog, apunta a que el sistema se sienta más consistente y predecible en un ecosistema cada vez más variado. La clave para los equipos de desarrollo es tratarlo como una revisión a fondo de los “supuestos” de la app: qué ocurre cuando la ventana cambia, cuando el usuario multitarea, cuando el audio intenta sonar sin contexto, cuando la cámara cambia de modo, cuando la seguridad deja de permitir atajos.