- Android 16 ignora restricciones de orientación, aspecto y redimensionado en pantallas grandes
- Diseño adaptable con Window Size Classes y UI responsiva para plegados y posturas
- Pruebas con emuladores Pixel, Espresso y compatibilidad universal resizable
- Excepciones, opción de inhabilitar por actividad y requisitos de Play
El universo Android ya no cabe en un único molde de pantalla. Teléfonos, tablets, plegables, ChromeOS, automóviles, TV y XR conviven con tamaños, orientaciones y contextos de uso muy distintos. Ese abanico trae una buena noticia para tus usuarios y un reto técnico para tu equipo: diseñar interfaces y lógicas que se adapten como un guante sin importar el lienzo. A continuación, conoce cómo cambiar la relación de aspecto de las apps en estos equipos.
¿Qué cambia con Android 16 en pantallas grandes sw600dp?
Para apps con objetivo de nivel de API 36, Android 16 impone un modelo coherente de diseño adaptable que ignora varias restricciones tradicionales cuando el dispositivo entra en la categoría de pantalla grande. Esto afecta a tablets, pantallas internas de plegables grandes y el modo de ventanas de escritorio.
- Atributos ignorados en pantallas con ancho más pequeño mayor o igual a 600 dp: screenOrientation con valores como portrait o landscape, resizeableActivity, minAspectRatio y maxAspectRatio.
- Métodos relacionados con orientación como setRequestedOrientation y getRequestedOrientation también quedan neutralizados para valores de orientación fija.
- En este contexto, las apps objetivo API 36 son redimensionables y entran en multiventana, equivalente a tener resizeableActivity en true cuando sw es mayor o igual a 600 dp, sin necesitar ajustes extra.
Este enfoque homogeneiza el comportamiento y reduce sorpresas de UI en pantallas grandes. La experiencia del usuario manda sobre cierres forzados a una orientación o aspecto, lo que implica revisar suposiciones antiguas en layouts y vistas.
Excepciones y casos particulares sobre ajustar la relación de aspecto
Hay situaciones en las que el sistema mantiene el comportamiento anterior. Las principales excepciones a estas anulaciones son:
- Pantallas con sw menor a 600 dp, donde siguen respetándose las restricciones del manifiesto habituales en la mayoría de teléfonos y pantallas externas de algunos plegables.
- Juegos identificados con la marca de manifiesto appCategory como game, siempre que se distribuyan con Android App Bundles y firma de apps de Play.
- Si el usuario fuerza el comportamiento predeterminado de la app en los ajustes del dispositivo para relación de aspecto, esa preferencia prima.
¿Cómo inhabilitar temporalmente las anulaciones?
Si necesitas tiempo de adaptación, puedes desactivar esta nueva conducta por actividad o a nivel de aplicación. Declara la propiedad de manifiesto android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY y así pides mantener las antiguas restricciones en pantallas grandes.
- En un elemento activity añade una property con name android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY y value true para esa actividad concreta.
- En el elemento application replica la misma property si quieres aplicar el comportamiento en toda la app.
Importante: se trata de una red de seguridad con fecha de caducidad. En el nivel de API 37 el framework eliminará esta posibilidad, por lo que en versiones posteriores las restricciones serán ignoradas siempre en pantallas con sw mayor o igual a 600 dp.

Pruebas y entorno de desarrollo
Para verificar el impacto de estos cambios, usa los emuladores de Pixel Tablet y Pixel Fold en Android Studio. Configura en tu módulo targetSdkPreview con el valor Baklava para empezar a validar.
- En dispositivos reales, activa la marca UNIVERSAL_RESIZABLE_BY_DEFAULT dentro del marco de compatibilidad de apps para simular el nuevo comportamiento.
- Automatiza pruebas de interfaz con Espresso y las APIs de test de Jetpack Compose, cubriendo rotaciones, cambio de tamaño de ventana, plegado y multiventana.
- Si no tienes un parque físico variado, apóyate en granjas de dispositivos como Firebase Test Lab o Samsung Remote Test Lab para pruebas bajo demanda e integración continua.
Problemas habituales y cómo solucionarlos
Cuando una app asumía una ventana fija, el salto a pantallas grandes y posturas plegadas puede sacar a la luz varios fallos:
- Componentes que se estiran sin límite en horizontal o vertical. Añade anchos máximos y contenedores que limiten la expansión para mantener proporciones agradables.
- Diseños sin scroll que ocultan botones o campos en horizontal. Activa el desplazamiento donde proceda y valida accesibilidad con distintos altos de ventana.
- Visores de cámara con relación de aspecto rígida. Asegúrate de rotar correctamente la vista previa y de que el visor se adapte a la relación de aspecto de IU distintas a la del sensor.
- Pérdida de estado con redimensionado o rotación. Sostén el estado con ViewModel, rememberSaveable en Compose y patrones de elevación de estado, evitando recreaciones destructivas.
- Asunciones de tamaño estático. Modela la UI con Window Size Classes y adopta layouts responsivos que reaccionen a cambios frecuentes.
Diseño responsivo y adaptable en plegables
Un diseño responsivo asegura que la app se vea bien en muchos tamaños, pero con plegables hace falta ir más allá. El diseño adaptable permite variantes optimizadas para pantallas plegadas y desplegadas, o posturas como mesa y libro.
Desplegado en horizontal, un plegable de pantalla grande se comporta como tablet. Un patrón de dos paneles con riel de navegación aprovecha la amplitud. Plegado, un layout de una sola columna con barra inferior funciona de forma limpia y directa.
Los dispositivos se pliegan hacia dentro o hacia fuera, y el pliegue puede ser flexible o una bisagra con oclusión. Ten en cuenta occlusionType FULL en dispositivos de doble pantalla como algunos formatos, donde no se debe pintar contenido en la zona de la bisagra.
- Estados típicos: FLAT completamente abierto y HALF_OPENED en algún punto intermedio.
- Posturas en HALF_OPENED: posición de mesa cuando el pliegue es horizontal, y posición de libro cuando es vertical.
- Evita controles cercanos al pliegue, coloca diálogos y menús emergentes fuera de la zona de oclusión y reparte contenido en áreas izquierda y derecha o arriba y abajo según postura.
Para empezar con un responsivo sencillo en Compose, BoxWithConstraints te permite adaptar contenido según el espacio disponible, y escalar después a variantes más ricas por postura.
Clases de tamaño de ventana y Compose
Antes de hablar de umbrales, refresquemos unidades: px representa píxeles físicos, dp se escala por densidad y sp añade la configuración del usuario, ideal para tipografías. Trabaja con dp y sp para que tu UI se vea consistente en distintas densidades.
El ecosistema reciente recomienda clasificar ventanas en tres tramos. En ancho y alto, Compact, Medium y Expanded cubren la mayoría de casos:
- 0 a 599 dp Compact, típicamente móvil en vertical.
- 600 a 839 dp Medium, móvil plegable en vertical o tablet vertical.
- 840 dp o más Expanded, móvil en horizontal, plegable en horizontal o tablet en horizontal.
Con la librería Material 3 window size class, calculateWindowSizeClass devuelve una foto del tamaño actual para decidir layouts. Si prefieres control total, implementa tu rememberWindowSize y categoriza width y height con tus propios límites.
Esta clasificación te permite definir patrones como lista en Compact y grid con columnas variables en Medium y Expanded, además de aumentar tamaños de tipografías o paddings donde tenga sentido.
Manifiesto, cambio de tamaño libre y continuidad
Muchas apps antiguas arrastran tres líneas problemáticas: maxAspectRatio limitado, resizeableActivity en false y screenOrientation bloqueado. Quitarlas es el primer paso para un comportamiento sano en formato libre, y fundamental con Android 16.
Observa cambios de configuración con LocalConfiguration en Compose o el callback onConfigurationChanged en vistas, para entender cómo varían screenWidthDp, screenHeightDp y orientación mientras el usuario redimensiona o rota.
Vigila también el ciclo de vida de Activity. En redimensionados significativos puede recrearse la actividad desde API 24, pero no en cambios menores. Añade un LifecycleEventObserver para ver qué eventos se disparan al minimizar, volver a primer plano y cambiar tamaños.
En Compose, remember conserva estado entre recomposiciones pero no entre recreaciones de actividad. rememberSaveable apoya el almacenamiento en savedInstanceState y evita perder, por ejemplo, la expansión de un encabezado o la posición de scroll tras un redimensionado.
Cuando eleves estado al ViewModel, pon la inicialización pesada en su init. Evitarás repetir llamadas de red o E S de archivos si la actividad se destruye y crea varias veces durante pruebas de formato libre.
Multiventana, arrastrar y soltar y productividad
En pantallas grandes, Android 12 y superiores usan multiventana por defecto. Las apps conviven en pantalla dividida y en modo de ventanas de escritorio donde se mueven y redimensionan como en el escritorio tradicional.
Este contexto desbloquea flujos potentes como arrastrar y soltar entre apps. Implementa el framework de drag and drop para mover imágenes, texto o archivos con gestos naturales e integrarte en escenarios reales de productividad.
Herramientas, SDKs y ecosistema
Jetpack Compose es hoy la apuesta moderna para UI declarativa. Su reactividad facilita escuchar cambios de ventana y postura, componer variantes y conservar estado.
Flutter ha avanzado en soporte para plegables, posibilitando apps nativas para Android e iOS con interfaces adaptativas coherentes. Además, Samsung ofrece un SDK específico para plegables Galaxy con simuladores y emuladores para validar modos de pantalla antes de publicar.
Si trabajas con recursos clásicos, recuerda la familia de densidades ldpi, mdpi, hdpi, xhdpi, xxhdpi y xxxhdpi. Los vectores ayudan a reducir matrices por densidad, y los qualifiers por tamaño y orientación siguen siendo válidos para casos concretos.
Ejemplo real: rediseño de Google Wallet en plegables
Una app popular que ha dado el salto es Wallet. En plegables tipo Fold, con relación de aspecto cercana a 4 3, su UI evolucionó desde una ampliación poco útil de tarjetas a un esquema de dos paneles que aprovecha mejor el espacio.
Ahora el selector de tarjetas de pago queda en una columna, y las tarjetas de fidelización ocupan la otra mitad con desplazamiento vertical. Los elementos vuelven a tamaños naturales en lugar de expandirse hasta el ridículo, y aunque exista una zona visualmente más vacía, la legibilidad y el control mejoran claramente. Este tipo de decisiones ejemplifica la filosofía de diseño adaptable: priorizar estructura y jerarquía por encima de llenar píxeles.
Consejos prácticos para quien usa un plegable reciente
Si notas apps aumentadas o estiradas en un Fold moderno, entra en los ajustes de relación de aspecto por app del dispositivo. Algunas capas permiten forzar pantalla completa o un aspecto concreto, con impacto dispar según la app. Recuerda que en Android 16 el usuario puede habilitar el comportamiento predeterminado de la app en los ajustes de relación de aspecto, influyendo en el resultado final.
Aun así el balón está en el tejado del desarrollador. Cuando la app adopta diseños responsivos y conserva estado, la experiencia al desplegar, rotar o separar ventanas deja de ser un dolor y pasa a ser un plus que engancha.
Cámara, continuidad y detalles que marcan
Las vistas previas de cámara suelen asumir una proporción fija. En pantallas no conformes pueden verse estiradas o invertidas. Asegúrate de rotar el visor con los cambios de orientación y de permitir visores que se adapten a proporciones de IU distintas a la del sensor.
La continuidad es crucial al pasar de la pantalla exterior a la interior. Si el usuario abre un email en el panel pequeño, al desplegar deberías mostrar lista y detalle en dos paneles sin perder el foco. Mantén texto en campos, estado del teclado, posición de scroll y la reproducción multimedia donde se dejó.
Cronograma y requisitos de publicación
En Android 16, durante 2025, la compatibilidad con todas las orientaciones, relación de aspecto y redimensionado se convierte en referencia en pantallas grandes para apps objetivo API 36, con posibilidad de inhabilitar temporalmente como se explicó.
Las fechas de objetivo de API dependen de cada tienda, pero Google Play ha marcado una línea: a partir de agosto de 2026 exigirá target API 36. Mejor planificar la migración ya para llegar a tiempo con tests, rediseños y mejoras de estado.
Más allá de los plegables: Wear OS y otras pantallas
Aunque el foco aquí son los plegables, el principio es el mismo para relojes. En Wear OS manda la interacción de vistazo, con Tiles, complicaciones y notificaciones compactas que ofrecen valor en segundos, no minutos.
Compose for Wear OS y Material 3 ayudan con componentes como ScalingLazyColumn para superficies curvas. Optimiza batería y rendimiento minimizando red y procesado, y apóyate en Health Services API para sensores. En diseño, prioriza objetivos táctiles grandes, gestos simples y voz.
El mercado de pantallas dinámicas encadena una evolución clara. Android 16 empuja a las apps a abandonar ataduras a orientaciones y relación de aspecto fijas en pantallas grandes, y los casos de uso multiventana, posturas plegadas y arrastrar y soltar ya no son excentricidades, sino expectativas. Con un diseño adaptable basado en Window Size Classes, una arquitectura que conserva el estado, pruebas realistas y atención a detalles como la cámara, tu app pasa de estirarse a lo bruto a sentirse nativa en cualquier lienzo, creando experiencias que de verdad apetecen usar. Comparte esta guía y más usuarios sabran ajustar la relación de aspecto de sus apps en Android.