Con el lanzamiento de Android 16 en 2025, compartimos nuestra visión de un ecosistema de dispositivos en el que las apps se adapten sin problemas a cualquier pantalla, ya sea un teléfono, un dispositivo plegable, una tablet, una computadora, una pantalla de auto o XR. Los usuarios esperan que sus apps funcionen en todas partes. Ya sea que realicen varias tareas en una tablet, desplieguen un dispositivo para leer cómodamente o ejecuten apps en un entorno de ventanas de escritorio, los usuarios esperan que la IU llene el espacio de visualización disponible y se adapte a la postura del dispositivo.

Presentamos cambios significativos en las APIs de orientación y capacidad de cambio de tamaño para facilitar el comportamiento adaptable, al tiempo que proporcionamos una opción de exclusión temporal para ayudarte a realizar la transición. Ya vimos que muchos desarrolladores se adaptaron correctamente a esta transición cuando se orientaron al nivel de API 36.

Ahora, con el lanzamiento de la versión beta de Android 17, pasamos a la siguiente fase de nuestra hoja de ruta adaptable: Android 17 (nivel de API 37) quita la opción de inhabilitación para desarrolladores para las restricciones de orientación y capacidad de cambio de tamaño en dispositivos con pantallas grandes (ancho mínimo > 600 dp). Cuando tu nivel de API objetivo sea 37, tu app deberá poder adaptarse a una variedad de tamaños de visualización.

Los cambios de comportamiento garantizan que el ecosistema de Android ofrezca una experiencia coherente y de alta calidad en todos los factores de forma de los dispositivos.

Qué cambia en Android 17

Las apps orientadas a Android 17 deben garantizar su compatibilidad con la eliminación gradual de los atributos del manifiesto y las APIs de tiempo de ejecución que se introdujeron en Android 16. Entendemos que, para algunas apps, esta puede ser una gran transición, por lo que incluimos prácticas recomendadas y herramientas para ayudar a evitar problemas comunes más adelante en esta entrada de blog.

No se introdujeron cambios nuevos desde Android 16, pero ya no es posible la exclusión para desarrolladores. Como recordatorio, cuando tu app se ejecuta en una pantalla grande (donde pantalla grande significa que la dimensión más pequeña de la pantalla es mayor o igual que 600 dp), se ignoran los siguientes atributos y APIs del manifiesto:

Nota: Como se mencionó anteriormente con Android 16, estos cambios no se aplican a las pantallas que son más pequeñas que el ancho mínimo de 600 dp ni a las apps clasificadas como juegos según la marca android:appCategory. 

Además, los usuarios conservan el control. En la configuración de la relación de aspecto, los usuarios pueden habilitar explícitamente el uso del comportamiento solicitado de la app.

Prepara tu app

Las apps deberán admitir diseños horizontales y verticales para tamaños de pantalla en el rango completo de relaciones de aspecto en las que los usuarios pueden elegir usar apps, incluidas las ventanas que pueden cambiar de tamaño, ya que ya no habrá forma de restringir la relación de aspecto y la orientación a vertical u horizontal.

Prueba tu app

El primer paso es probar tu app con estos cambios para asegurarte de que funcione bien en todos los tamaños de pantalla.

Usa la versión beta 1 de Android 17 con los emuladores de Pixel Tablet y Pixel Fold en Android Studio, y establece targetSdkPreview = “CinnamonBun”. Como alternativa, puedes usar el framework de compatibilidad de apps habilitando la marca UNIVERSAL_RESIZABLE_BY_DEFAULT si tu app aún no está orientada al nivel de API 36.

Tenemos herramientas adicionales para garantizar que tus diseños se adapten correctamente. Puedes auditar automáticamente tu IU y obtener sugerencias para hacerla más adaptable con Compose UI Check y simular características de visualización específicas en tus pruebas con DeviceConfigurationOverride.

En el caso de las apps que históricamente restringieron la orientación y la relación de aspecto, solemos ver problemas con las vistas previas de la cámara sesgadas o mal orientadas, los diseños estirados, los botones inaccesibles o la pérdida del estado del usuario cuando se controlan los cambios de configuración. 

Veamos algunas estrategias para abordar estos problemas comunes.

Garantiza la compatibilidad de la cámara

Un problema común en los dispositivos plegables horizontales o para los cálculos de la relación de aspecto en situaciones como la multiventana, el modo de ventanas de escritorio o las pantallas conectadas es cuando la vista previa de la cámara aparece estirada, rotada o recortada.

Asegúrate de que la vista previa de la cámara no esté estirada ni rotada.

Este problema suele ocurrir en dispositivos con pantallas grandes y plegables porque las apps suponen relaciones fijas entre las funciones de la cámara (como la relación de aspecto y la orientación del sensor) y las funciones del dispositivo (como la orientación del dispositivo y la orientación natural).

Para asegurarte de que la vista previa de la cámara se adapte correctamente a cualquier tamaño u orientación de la ventana, considera estas cuatro soluciones:

Solución 1: Jetpack CameraX (preferida) 

La solución más sencilla y sólida es usar la biblioteca Jetpack CameraX. Su elemento de la IU PreviewView está diseñado para controlar automáticamente todas las complejidades de la vista previa:

• PreviewView se ajusta correctamente a la orientación del sensor, la rotación del dispositivo y el ajuste de escala.
• PreviewView mantiene la relación de aspecto de la imagen de la cámara, por lo general, centrándola y recortándola (FILL_CENTER).
• Puedes establecer el tipo de escala en FIT_CENTER para agregar barras negras a la vista previa si es necesario.

Para obtener más información, consulta Implementar una vista previa en la documentación de CameraX.

Solución 2: CameraViewfinder 

Si usas una base de código Camera2 existente, la biblioteca CameraViewfinder (compatible con versiones anteriores hasta el nivel de API 21) es otra solución moderna. Simplifica la visualización del feed de la cámara mediante el uso de un TextureView o SurfaceView y la aplicación de todas las transformaciones necesarias (relación de aspecto, escala y rotación).

Para obtener más información, consulta la entrada de blog _Presentación del visor de la cámara_ y la guía para desarrolladores de _Vista previa de la cámara_.

Solución 3: Implementación manual de Camera2 

Si no puedes usar CameraX ni CameraViewfinder, debes calcular manualmente la orientación y la relación de aspecto, y asegurarte de que los cálculos se actualicen en cada cambio de configuración:

• Obtén la orientación del sensor de la cámara (por ejemplo, 0, 90, 180, 270 grados) de CameraCharacteristics.
• Obtén la rotación actual de la pantalla del dispositivo (por ejemplo, 0, 90, 180, 270 grados).
• Usa los valores de orientación del sensor de la cámara y rotación de la pantalla para determinar las transformaciones necesarias para tu SurfaceView o TextureView.
• Asegúrate de que la relación de aspecto de tu Surface de salida coincida con la relación de aspecto de la vista previa de la cámara para evitar la distorsión.

Importante: Ten en cuenta que la app de cámara podría ejecutarse en una parte de la pantalla, ya sea en el modo multiventana o de ventanas de escritorio, o en una pantalla conectada. Por este motivo, no se debe usar el tamaño de la pantalla para determinar las dimensiones del visor de la cámara; en su lugar, usa métricas de ventana. De lo contrario, corres el riesgo de que la vista previa de la cámara se estire.

Para obtener más información, consulta la guía para desarrolladores de Vista previa de la cámara y el video Tu app de cámara en diferentes factores de forma.

Solución 4: Realiza acciones básicas de la cámara con un intent 

Si no necesitas muchas funciones de la cámara, una solución simple y directa es realizar acciones básicas de la cámara, como capturar una foto o un video, con la aplicación de cámara predeterminada del dispositivo. En este caso, puedes usar un Intent en lugar de integrarlo a una biblioteca de la cámara para facilitar el mantenimiento y la adaptabilidad. 

Para obtener más información, consulta Intents de la cámara.

Evita la IU estirada o los botones inaccesibles

Si tu app supone una orientación específica del dispositivo o una relación de aspecto de la pantalla, es posible que tenga problemas cuando se use en varias orientaciones o tamaños de ventana.

Asegúrate de que los botones, los campos de texto y otros elementos no estén estirados en pantallas grandes.

Es posible que hayas configurado los botones, los campos de texto y las tarjetas en fillMaxWidth o match_parent. En un teléfono, se ve excelente. Sin embargo, en una tablet o un dispositivo plegable en orientación horizontal, los elementos de la IU se estiran en toda la pantalla grande. En Jetpack Compose, puedes usar el modificador widthIn para establecer un ancho máximo para los componentes y evitar el contenido estirado:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

Si un usuario abre tu app en orientación horizontal en un dispositivo plegable o una tablet, es posible que los botones de acción, como Guardar o Acceder , en la parte inferior de la pantalla no se rendericen. Si el contenedor no es desplazable, es posible que el usuario no pueda continuar. En Jetpack Compose, puedes agregar un modificador verticalScroll a tu componente:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

Si combinas las restricciones de ancho máximo con el desplazamiento vertical, te aseguras de que tu app siga siendo funcional y utilizable, sin importar qué tan ancho o corto sea el tamaño de la ventana de la app.

Consulta nuestra guía para compilar diseños adaptables.

Conserva el estado con los cambios de configuración

Quitar las restricciones de orientación y relación de aspecto significa que el tamaño de la ventana de tu app cambiará con mucha más frecuencia. Los usuarios pueden rotar el dispositivo, plegarlo o desplegarlo, o cambiar el tamaño de tu app de forma dinámica en los modos de pantalla dividida o de ventanas de escritorio.

De forma predeterminada, estos cambios de configuración destruyen y vuelven a crear tu actividad. Si tu app no administra correctamente este evento del ciclo de vida, los usuarios tendrán una experiencia frustrante: las posiciones de desplazamiento se restablecen a la parte superior, los formularios incompletos se borran y se pierde el historial de navegación. Para garantizar una experiencia adaptable sin problemas, es fundamental que tu app conserve el estado a través de estos cambios de configuración. Con Jetpack Compose, puedes inhabilitar la recreación y, en su lugar, permitir que los cambios de tamaño de la ventana vuelvan a componer tu IU para reflejar la nueva cantidad de espacio disponible.

Consulta nuestra guía para guardar el estado de la IU.

Orientación al nivel de API 37 para agosto de 2027

Si tu app inhabilitó estos cambios anteriormente cuando se orientó al nivel de API 36, solo se verá afectada por la eliminación de la inhabilitación de Android 17 después de que tu app se oriente al nivel de API 37. Para ayudarte a planificar con anticipación y realizar los ajustes necesarios en tu app, esta es la línea de tiempo en la que estos cambios entrarán en vigencia:

• Android 17: Los cambios descritos anteriormente serán la experiencia de referencia para dispositivos con pantallas grandes (ancho de pantalla más pequeño > 600 dp) para apps orientadas al nivel de API 37. Los desarrolladores no tendrán la opción de inhabilitar.

Los plazos para orientarse a un nivel de API específico son específicos de la tienda de aplicaciones. En el caso de Google Play, las apps y actualizaciones nuevas deberán orientarse al nivel de API objetivo 37, lo que hará que este comportamiento sea obligatorio para la distribución en agosto de 2027.

Preparación para Android 17

Consulta la página de cambios de Android 17 para ver todos los cambios que afectan a las apps en Android 17. Para probar tu app, descarga la versión beta 1 de Android 17 y actualiza a targetSdkPreview = “CinnamonBun” o usa el framework de compatibilidad de apps para habilitar cambios específicos.

El futuro de Android es adaptable, y estamos aquí para ayudarte a llegar allí. Mientras te preparas para Android 17, te recomendamos que revises nuestras guías para compilar diseños adaptables y nuestros lineamientos de calidad para pantallas grandes. Estos recursos están diseñados para ayudarte a controlar varios factores de forma y tamaños de ventana con confianza.

No pierdas tiempo. Comienza a prepararte para Android 17 hoy mismo.