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 automóvil o un dispositivo XR. Los usuarios esperan que sus apps funcionen en cualquier lugar. Ya sea que realicen varias tareas a la vez en una tablet, desplieguen un dispositivo para leer con comodidad 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 posición del dispositivo.

Presentamos cambios significativos en las APIs de orientación y cambio de tamaño para facilitar el comportamiento adaptable, además de proporcionar una opción de inhabilitación temporal para ayudarte con la transición. Ya vimos a muchos desarrolladores adaptarse con éxito a esta transición cuando segmentan sus aplicaciones para el 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 de las restricciones de orientación y cambio de tamaño en dispositivos con pantalla grande (ancho mínimo > 600 dp). Cuando segmentes tu app para el nivel de API 37, esta deberá poder adaptarse a una variedad de tamaños de pantalla.

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é cambiará en Android 17

Las apps que se segmentan para 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 que los desarrolladores rechacen la opción. 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 a 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 sw 600 dp ni a las apps categorizadas como juegos según la marca android:appCategory. 

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

Prepara tu app

Las apps deberán admitir diseños horizontales y verticales para tamaños de pantalla en todo el rango de relaciones de aspecto en el que los usuarios pueden elegir usar apps, incluidas las ventanas redimensionables, ya que 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 Android 17 Beta 1 con los emuladores de las series Pixel Tablet y Pixel Fold en Android Studio, y configura targetSdkPreview = “CinnamonBun”. Como alternativa, puedes usar el marco de compatibilidad de la app habilitando la marca de UNIVERSAL_RESIZABLE_BY_DEFAULT si tu app aún no se orienta 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 que sea más adaptable con Compose UI Check, y simular características de pantalla 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 vistas previas de la cámara sesgadas o mal orientadas, diseños estirados, botones inaccesibles o pérdida del estado del usuario cuando se controlan los cambios de configuración. 

Veamos algunas estrategias para abordar estos problemas habituales.

Cómo garantizar 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 el modo 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 plegables y con pantallas grandes 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 de CameraX de Jetpack. 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
• 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 Implementa una vista previa en la documentación de CameraX.

Solución 2: CameraViewfinder 

Si usas una base de código de Camera2 existente, la biblioteca CameraViewfinder (retrocompatible con el nivel de API 21) es otra solución moderna. Simplifica la visualización de la transmisión de la cámara con un TextureView o SurfaceView y aplica todas las transformaciones necesarias (relación de aspecto, escala y rotación) por ti.

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 la vista previa de la cámara.

Solución 3: Implementación manual de Camera2 

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

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

Importante: Ten en cuenta que es posible que la app de la cámara se ejecute 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 las métricas de ventana. De lo contrario, la vista previa de la cámara se estirará.

Para obtener más información, consulta la guía para desarrolladores de la vista previa de la cámara y el video de 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 integrar una biblioteca de cámara para facilitar el mantenimiento y la adaptabilidad. 

Para obtener más información, consulta Intenciones 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 se estiren en pantallas grandes.

Es posible que hayas configurado botones, campos de texto y tarjetas como fillMaxWidth o match_parent.  En un teléfono, se ve genial. Sin embargo, en una tablet o un dispositivo plegable en orientación horizontal, los elementos de la IU se extienden por 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 una tablet o un dispositivo plegable, es posible que los botones de acción, como Guardar o Acceder, que se encuentran en la parte inferior de la pantalla, se rendericen fuera de la pantalla. Si el contenedor no se puede desplazar, es posible que se impida que el usuario continúe. 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 max-width con el desplazamiento vertical, te aseguras de que tu app siga siendo funcional y utilizable, independientemente de qué tan ancho o corto sea el tamaño de la ventana de la app.

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

Cómo conservar 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 restablecerán a la parte superior, los formularios a medio completar se borrarán y se perderá el historial de navegación. Para garantizar una experiencia adaptable sin problemas, es fundamental que tu app conserve el estado durante estos cambios de configuración. Con Jetpack Compose, puedes inhabilitar la recreación y, en cambio, 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.

El nivel de API objetivo será el 37 en agosto de 2027

Si tu app inhabilitó estos cambios 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 se oriente al nivel de API 37. Para ayudarte a planificar con anticipación y realizar los ajustes necesarios en tu app, aquí tienes el cronograma en el que entrarán en vigencia estos cambios:

• Android 17: Los cambios descritos anteriormente serán la experiencia de referencia para los dispositivos con pantallas grandes (ancho de pantalla más pequeño > 600 dp) para las apps que segmentan el nivel de API 37. Los desarrolladores no tendrán la opción de rechazar esta modificación.

Las fechas límite para segmentar un nivel de API específico son específicas de cada tienda de aplicaciones. En el caso de Google Play, las apps nuevas y las actualizaciones deberán segmentarse para el nivel de API 37, lo que hará que este comportamiento sea obligatorio para la distribución en agosto de 2027.

Preparativos 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 Android 17 Beta 1 y actualiza a targetSdkPreview = “CinnamonBun” o usa el marco de compatibilidad de apps para habilitar cambios específicos.

El futuro de Android es adaptable, y estamos aquí para ayudarte a llegar a él. Mientras te preparas para Android 17, te recomendamos que consultes nuestras guías para crear diseños adaptativos 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 esperes más. Comienza a prepararte para Android 17 hoy mismo