Si te estás preguntando cómo cambiar la relación de aspecto en apps para dispositivos plegables, has llegado al lugar adecuado. Los móviles y tablets plegables han disparado la diversidad de tamaños y orientaciones, y eso afecta directamente a cómo se ven tus aplicaciones. Entre nuevas políticas de Android 16, ajustes del sistema y buenas prácticas de diseño, hay mucho que tener en cuenta para que todo encaje en pantallas compactas, medianas y expandidas.
El panorama es claro: Android está empujando a que todas las apps sean redimensionables y respeten la experiencia de pantallas grandes (tablets, modo escritorio y pantallas internas de plegables). Aun así, hay formas de ajustar la relación de aspecto por app, probar en emuladores, habilitar comportamientos de compatibilidad y, si hace falta, optar por excepciones. Vamos paso a paso, sin rodeos.
Qué ha cambiado en Android 16 (API 36): orientación, aspecto y tamaño
Con Android 16 (nivel de API 36), el sistema puede ignorar restricciones de la app sobre orientación, relación de aspecto y redimensionado en pantallas grandes. Esto aplica a dispositivos con smallest width (sw) ≥ 600dp: tablets, la pantalla interna de muchos plegables y el modo de ventanas de escritorio. El objetivo es ofrecer una experiencia coherente en pantallas grandes, respetando las preferencias del usuario sobre orientación y tamaño cuando hay espacio de sobra.
En apps que apunten a API 36, las actividades pasan a ser redimensionables por defecto y pueden entrar en modo multiventana si el dispositivo tiene sw ≥ 600dp (equivalente a tener resizeableActivity=»true»). De forma práctica, el sistema ignora varios atributos que solían forzar un comportamiento fijo en pantalla grande.
Atributos ignorados en pantallas grandes cuando se apunta a API 36
Si tu app targetea Android 16, en displays sw ≥ 600dp se ignoran varias banderas del manifiesto y APIs relacionadas. Entre los atributos que dejan de surtir efecto están screenOrientation (portrait, landscape y variantes sensor/user), resizeableActivity, minAspectRatio, maxAspectRatio y llamadas como setRequestedOrientation()/getRequestedOrientation() con esos mismos valores fijos.
Este cambio impide que una app quede «bloqueada» en vertical o con una relación de aspecto estrecha cuando hay mucho más espacio para mostrar contenido. La idea es favorecer layouts adaptativos y evitar estiramientos o recortes indeseados que frustran a los usuarios de pantallas grandes.
Excepciones: cuándo no se aplican estos cambios
Aunque el nuevo modelo es más estricto en pantallas grandes, hay excepciones. No se aplican estas anulaciones a pantallas con sw < 600dp (muchos teléfonos, algunos plegables en modo externo), y los juegos (categoría android:appCategory=»game») quedan aparte. Además, si el usuario activa el comportamiento predeterminado de la app en las opciones de relación de aspecto, esa preferencia manda.
Si publicas juegos, Google Play puede ayudarte a gestionar la categoría de la app cuando usas Android App Bundles y la firma de apps de Play, obteniendo beneficios adicionales de distribución. Para apps no-juego, lo importante es construir IU responsiva y dejar que el sistema gestione la ventana.
Cómo inhabilitar el comportamiento en API 36 y aviso para API 37
Si, por una razón bien justificada, necesitas optar por no aplicar este comportamiento en API 36, puedes declarar la propiedad de manifiesto «android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY». Establécela en una activity concreta o en toda la aplicación:
<activity ...>
<property
android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
android:value="true" />
</activity><application ...>
<property
android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
android:value="true" />
</application>Ojo con esto: el framework eliminará la posibilidad de «opt-out» en API 37. Es decir, para apps que targeteen 37 o superior, las restricciones de orientación, relación de aspecto y redimensionado siempre serán ignoradas en pantallas con sw ≥ 600dp.
Pruebas en emuladores y dispositivos: cómo reproducir casos reales
Para saber si tu app está afectada por los cambios, usa los emuladores de Pixel Tablet y Pixel Fold en Android Studio. Define targetSdkPreview = «Baklava» en tu build.gradle de módulo y observa cómo responde tu IU al cambiar orientación, plegado/desplegado y tamaño de ventana.
También puedes habilitar el comportamiento universal redimensionable con la marca de compatibilidad UNIVERSAL_RESIZABLE_BY_DEFAULT en tus dispositivos de prueba. Y, para pruebas automáticas, Espresso y las APIs de test de Jetpack Compose te permiten validar flujos completos con cambios de tamaño, rotación y multiventana.
Problemas habituales en pantallas grandes y cómo evitarlos
Las apps que se ataban a orientación fija, aspect ratio concreto o actividad no redimensionable suelen sufrir en Android 16: elementos estirados, solapes, botones fuera de viewport y errores de cámara en previsualizaciones. La solución pasa por abrazar un diseño adaptable.
- Evita componentes estirados: añade anchos máximos para que una card, toolbar o imagen no se desmadre en horizontal.
- Habilita scroll donde proceda: si no hay desplazamiento, el usuario puede perder controles vitales al pasar a landscape.
- Cuida la cámara en ambas orientaciones: ajusta visor y rotación respecto al sensor; no presupongas una relación de aspecto fija.
- Preserva estado al redimensionar: la actividad puede recrearse; conserva entradas de formularios y contexto del usuario.
- Usa Window Size Classes: piensa en categorías de tamaño y en layouts responsivos que se adaptan al espacio.
La voz del usuario: «mis apps se ven raras en el Fold»
Si usas un plegable como Galaxy Fold y notas Instagram o Reddit demasiado aumentadas o estiradas, no estás solo. Es un síntoma de apps no optimizadas para pantallas grandes o con escalado forzado. En juegos, además, hay títulos que aún no aprovechan bien el espacio y se ven mal.
¿Hay ajustes? En muchos fabricantes puedes forzar pantalla completa por app. Sin embargo, si una app no está adaptada, el resultado puede ser subóptimo. Lo ideal es que el desarrollador adopte layouts adaptativos; como usuario, revisa Ajustes > Pantalla > Apps en pantalla completa (o Escalado de aplicaciones) para gestionar cada app.
Ajustes útiles del sistema: relación de aspecto por app y densidad
En capas de Android de varios fabricantes encontrarás opciones para que ciertas apps se ejecuten a pantalla completa o en una relación de aspecto concreta. Rutas habituales: Ajustes > Pantalla > Escalado de aplicaciones / Apps en pantalla completa. Actívalo por app y revisa el resultado.
Si aun así el contenido no cuadra, puedes jugar con la densidad (Ancho más pequeño) desde las opciones de desarrollador. Habilita el modo desarrollador pulsando 7 veces el número de compilación (Ajustes > Sistema > Información del teléfono), entra en Opciones de desarrollador y modifica «Ancho más pequeño»: bajar el valor hace todo más grande; subirlo, más pequeño. Hazlo paso a paso y anota el valor original.
Para pantallas curvas, algunos sistemas incluyen «Ignorar toques aleatorios en los bordes» o «Protección frente a toques accidentales». Puede personalizarse el área afectada en ciertas capas (por ejemplo, en algunos modelos de Xiaomi). No arregla la relación de aspecto, pero reduce toques fantasma mientras pruebas ajustes.
Compose y diseño adaptable: clases de tamaño de ventana
Jetpack Compose aporta herramientas perfectas para UIs que se estiran sin romperse. Las Window Size Classes (Material 3) simplifican la lógica desacoplando el layout de medidas físicas de pantalla. Clasifica por ancho/alto en Compact, Medium y Expanded y ajusta la UI en consecuencia.
En el composable raíz puedes obtener la clase de tamaño y propagarla como estado. Evita decisiones de diseño basadas en «¿es tablet?» o una relación de aspecto fija; la app puede ir en multiventana, en un segmento de pantalla o en un monitor externo.
Para componentes internos, usa su ancho real de renderizado. BoxWithConstraints permite cambiar QUÉ se muestra en función del espacio (por ejemplo, pasar de una columna a un layout en filas con detalles), asumiendo el coste de composición diferida en la fase de layout.
Todo el contenido disponible, todo el tiempo
Si un componente muestra más detalles cuando hay ancho suficiente, no cargues los datos «en función» del tamaño. Pásalos siempre (por ejemplo, imageUrl, title, description) y decide en el composable qué partes se ven. Así evitas efectos secundarios al redimensionar y preservas el estado.
Cuando el layout cambia (de una a dos columnas, o viceversa), conviene elevar marcas de estado como showMore al nivel superior. Esto conserva la intención del usuario aunque cambie la distribución. En Compose, recuerda que rememberSaveable ayuda a mantener el estado a través de recreaciones de Activity.
Manifiesto y restricciones que bloquean el cambio de tamaño
Si tu app no se redimensiona o queda atrapada en una relación de aspecto concreta, revisa el AndroidManifest.xml. Elimina android:maxAspectRatio, android:resizeableActivity=»false» y screenOrientation fija si estás optimizando para pantallas grandes o formato libre. En API 36, de poco servirán en sw ≥ 600dp porque el sistema los ignorará.
Para apps legacy, este paso es clave: permitir que la ventana crezca y se reduzca es el primer gran filtro para que tu IU responda bien en modo escritorio, split-screen o al desplegar un plegable.
Cambios de configuración y ciclo de vida
Al cambiar el tamaño de ventana, se actualiza la Configuration (width/height, orientation, aspect ratio). En vistas clásicas puedes observarlo con onConfigurationChanged; en Compose, LocalConfiguration.current refleja esos cambios automáticamente.
También notarás implicaciones de ciclo de vida. Desde API 24, solo los cambios significativos de tamaño recrean la Activity, pero puede ocurrir. Registra eventos con un LifecycleEventObserver y verifica cuándo se destruye/crea la Activity. Si conectas un monitor externo o varía la densidad, puede recrearse también.
Continuidad del estado y trabajo en segundo plano
Para conservar UI state ante recreaciones, usa rememberSaveable en lugar de remember cuando el estado deba sobrevivir a cambios de configuración. Y eleva estado a ViewModel para continuidad real entre recreaciones, evitando duplicar cargas costosas.
Si la inicialización se lanza en onCreate(), puede repetirse. Mueve la inicialización al init del ViewModel para que se ejecute una sola vez por ciclo de vida del ViewModel. Es especialmente importante si hay llamadas de red o E/S pesadas.
Diseño web para plegables: CSS, APIs y rendimiento
Para sitios web, la cosa va en paralelo. Los foldables requieren media queries más precisas, no solo breakpoints clásicos. Combina min/max-width con aspect-ratio para escenarios como 3/4 (vertical plegado) o 16/9 (apaisado). Reorganiza menús, grids e imágenes según el espacio real disponible.
@media (min-width: 600px) and (max-width: 900px) {
/* Pantallas intermedias: plegable semiabierto */
}
@media (aspect-ratio: 3/4) {
/* Vertical plegado */
}
@media (aspect-ratio: 16/9) {
/* Apaisado desplegado */
}La Window Segments API ayuda a detectar segmentos activos de pantalla en entornos multipanel. También cuida el viewport-fit: cover para esquinas redondeadas o recortes, y detecta orientation desde JS para ajustar UI sin parpadeos. Optimiza rendimiento con lazy loading y compresión para escenarios multitarea típicos de un plegable.
if (window.screenSegments) {
const segments = window.screenSegments;
console.log(segments);
}
/* CSS */
body { /* iOS/entornos compatibles */
viewport-fit: cover;
}
/* JS */
if (screen.orientation.type === 'landscape-primary') {
console.log('Modo apaisado');
}Clases de tamaño: umbrales recomendados y ejemplos
Google recomienda tres rangos de ancho/alto en dp que cuadran muy bien con móviles, plegables y tablets. Compact (0–599dp), Medium (600–839dp), Expanded (840+dp). Un móvil plegable en vertical puede quedar en Medium; desplegado horizontal suele pasar a Expanded.
Sobre esa base, puedes cambiar listas por grids con 2–3 columnas cuando hay espacio, subir tipografías en Expanded, y mantener el contenido legible en Compact. Material 3 aporta material3-window-size-class para calcularlo de forma fiable (recuerda que puede estar en estado experimental y requiere @OptIn).
Prácticas de IU: componibles reutilizables y lógicas en capas
Un buen patrón es centralizar la lógica de tamaño en un punto (p. ej., el composable raíz) y pasar un estado derivado al resto. Evita que composables internos dependan implícitamente de un tamaño de pantalla global; así serán más reutilizables y testables.
Para un list-detail adaptable, decide en el nivel superior si se muestra uno o dos paneles según el ancho, y deja a los hijos centrarse en el contenido. Si una card muestra información extra cuando hay más espacio, decide con BoxWithConstraints o modificadores, pero no bloquees al componente a una única ubicación o tamaño.
Modo escritorio y multiventana: prepárate para moverte
En ChromeOS y escritorio de Android, la ventana se redimensiona como en un sistema operativo de PC. Tu app debe asumir cambios frecuentes de tamaño y conservar su estado, sin bloqueos por orientación fija ni aspect ratio estático. Los emuladores y codelabs de Google son una vía estupenda para probar todo esto de forma metódica.
Es un entorno ideal para validar que tu app no recalcula ni recarga de más al cambiar tamaño, y que las transiciones de layout son fluidas. Si el usuario minimiza y vuelve, que la app reanude sin perder contexto.
Cronograma y requisitos de publicación
Android 16 marca una referencia: compatibilidad con todas las orientaciones, relaciones de aspecto y redimensionado en pantallas ≥ 600dp para apps que targetean API 36 (con posibilidad de inhabilitarlo en 36, pero no en 37).
Las fechas límite dependen de cada tienda, pero Google Play exigirá target API 36 a partir de agosto de 2026. Si aún mantienes restricciones rígidas, es hora de planificar la migración para evitar sorpresas y, sobre todo, mejorar la experiencia en pantallas grandes.
Recursos y pruebas recomendadas
Para practicar, Google ofrece codelabs centrados en redimensionado: observa LocalConfiguration, registra ciclo de vida, migra restricciones de manifiesto y habilita rememberSaveable. La app ejemplo Reply, JetNews o CanonicalLayouts muestran patrones validados para pantallas grandes.
Para equipos web, Chrome DevTools, BrowserStack y Samsung Remote Test Lab facilitan pruebas en estados plegado/desplegado. Y si trabajas en Android nativo, los emuladores de Pixel Tablet/Fold y el marco de compatibilidad UNIVERSAL_RESIZABLE_BY_DEFAULT son tu campo de juego.
Un apunte de la comunidad: expectativas y realidad
Muchos usuarios de plegables comentan que deben arreglar app por app el escalado, y que algunos juegos se ven peor. Es comprensible en una transición de ecosistema, pero Android 16 y las prácticas de diseño adaptativo ponen la alfombra roja para que las apps aprovechen de verdad las pantallas grandes. Cuanto antes migres, antes dejarán de aparecer quejas por estiramientos y recortes.
Si pese a todo sientes que tu dispositivo no ofrece la experiencia que esperabas, hay opciones de recompra y venta de terminales usados. El contenido original mencionaba servicios como Moviloff para convertir tu viejo móvil en dinero y darle una segunda vida, algo que también contribuye al medio ambiente. No es una solución técnica, pero puede interesarte si estás pensando en cambiar de dispositivo.
Dominar la relación de aspecto y el redimensionado en apps para plegables pasa por aceptar el nuevo modelo: dejar que el sistema gestione ventanas grandes, construir UIs responsivas, preservar el estado y probar en escenarios reales. Con Android 16 empujando a favor (y Android 37 cerrando la puerta a restricciones en pantallas grandes), el camino está marcado: adopta Window Size Classes, limpia el manifiesto, evita componentes estirados, habilita scroll, cuida la cámara en ambas orientaciones y mide el rendimiento.
Si necesitas ajustes inmediatos, recurre a opciones del sistema como apps en pantalla completa y, con prudencia, al «Ancho más pequeño». Los usuarios lo notarán enseguida: más contenido visible, menos deformaciones y una experiencia digna de una pantalla grande. Comparte esta información y más usuarios sabrán cambiar la relación sde aspecto en su móvil.