Prepara tu app para los cambios de cambio de tamaño y orientación en Android 17
Lectura de 6 min
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 un dispositivo de XR. Los usuarios esperan que sus apps funcionen en todas partes. 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 modo de ventanas de escritorio, los usuarios esperan que la IU ocupe el espacio de visualización disponible y se adapte a la postura del dispositivo.
Introdujimos cambios significativos en las APIs de orientación y cambio de tamaño para facilitar el comportamiento adaptable, a la vez que proporcionamos una inhabilitació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 de adaptabilidad: 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 (sw > 600 dp). Cuando orientas tu app al nivel de API 37, esta debe poder adaptarse a una variedad de tamaños de pantalla.
Los cambios de comportamiento garantizan que el ecosistema 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 orienten a Android 17 deben garantizar su compatibilidad con la eliminación gradual de los atributos del manifiesto y las APIs del entorno de ejecución que se introdujeron en Android 16. Entendemos que, para algunas apps, esta puede ser una transición importante, 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 inhabiliten la funció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 que 600 dp), se ignoran los siguientes atributos de manifiesto y APIs:
Nota: Como se mencionó anteriormente con Android 16, estos cambios no se aplican a las pantallas que tienen un ancho menor que 600 dp ni a las apps categorizadas como juegos según el android:appCategory.
| Atributos/API del manifiesto | Valores ignorados |
| screenOrientation | portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape |
| setRequestedOrientation() | portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape |
| resizeableActivity | todos |
| minAspectRatio | todos |
| maxAspectRatio | todos |
Además, los usuarios conservan el control. En la configuración de la relación de aspecto, los usuarios pueden habilitar de forma explícita el comportamiento solicitado de la app.
Prepara tu app
Las apps deberán admitir diseños horizontales y verticales para los tamaños de pantalla en el rango completo de relaciones de aspecto en las que los usuarios pueden elegir usar las apps, incluidas las ventanas que pueden cambiar de tamaño, 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 la 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 la serie Pixel Tablet y Pixel Fold en Android Studio, y establece el 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 tiene como objetivo el 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 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 vistas previas de la cámara sesgadas o mal orientadas, diseños estirados, botones inaccesibles o pérdida del estado del usuario cuando se manejan los cambios de configuración.
Veamos algunas estrategias para abordar estos problemas comunes.
Cómo garantizar la compatibilidad de la cámara
Un problema común en los dispositivos plegables en modo horizontal 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 o 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:
PreviewViewse ajusta correctamente para la orientación del sensor, la rotación del dispositivo y el escalamiento.- PreviewView mantiene la relación de aspecto de la imagen de la cámara, por lo general, centrando y recortando (
FILL_CENTER). - Puedes establecer el tipo de escala en
FIT_CENTERpara ajustar la vista previa al formato de pantalla ancha si es necesario.
Para obtener más información, consulta Cómo implementar 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 de CameraViewfinder (retrocompatible con el nivel de API 21) es otra solución moderna. Simplifica la visualización del feed 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 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 o 270 grados) de
CameraCharacteristics. - Obtener la rotación de pantalla actual del dispositivo (por ejemplo, 0, 90, 180 o 270 grados)
- Usa los valores de orientación del sensor de la cámara y de rotación de la pantalla para determinar las transformaciones necesarias para tu
SurfaceViewoTextureView. - Asegúrate de que la relación de aspecto de tu
Surfacede salida coincida con la relación de aspecto de la vista previa de la cámara para evitar distorsiones.
Importante: Ten en cuenta que la app de cámara podría estar ejecutándose 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 la 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 sobre la 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, 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 con una biblioteca de cámara para facilitar el mantenimiento y la adaptabilidad.
Para obtener más información, consulta Intents de cámara.
Evita la IU estirada o los botones inaccesibles
Si tu app asume una orientación del dispositivo o una relación de aspecto de la pantalla específicas, 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 modo 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 que el contenido se estire:
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, que se encuentran en la parte inferior de la pantalla, se rendericen fuera de la pantalla. Si no se puede desplazar por el contenedor, 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, independientemente de lo ancha o corta que sea 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 la 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 recrean 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 al principio, los formularios completados a medias se borrarán y se perderá el historial de navegación. Para garantizar una experiencia adaptable sin interrupciones, es fundamental que tu app conserve el estado durante 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.
Nivel de API objetivo 37 para agosto de 2027
Si tu app inhabilitó estos cambios cuando se orientaba 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, consulta el cronograma de entrada en vigencia de estos cambios:
- Android 17: Los cambios descritos anteriormente serán la experiencia de referencia para los dispositivos con pantalla grande (ancho de pantalla mínimo > 600 dp) en las apps que se orienten al nivel de API 37. Los desarrolladores no tendrán la opción de inhabilitar esta función.
Las fechas límite para segmentar un nivel de API específico dependen de cada tienda de aplicaciones. En Google Play, las apps nuevas y las actualizaciones deberán tener como objetivo el nivel de API 37, lo que hará que este comportamiento sea obligatorio para la distribución en agosto de 2027.
Prepárate para Android 17
Consulta la página de cambios de Android 17 para conocer 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 lograrlo. Mientras te preparas para Android 17, te recomendamos que revises nuestras guías para crear 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 esperes. Comienza a prepararte para Android 17 hoy mismo.
-
Novedades de productosHoy, en Galaxy Unpacked, Samsung presentó su línea más reciente de dispositivos plegables y wearables. Para los desarrolladores, esto significa que la variedad de factores de forma, tamaños de pantalla y posiciones de dispositivos que tu app debe admitir se está expandiendo una vez más.
Fahd Imtiaz, Miguel Montemayor • Lectura de 3 min -
Novedades de productosCon la incorporación de nuevos factores de forma, como el Pixel 10 Pro Fold, al ecosistema Android, el desarrollo de apps adaptables es esencial para crear experiencias del usuario de alta calidad en teléfonos, tablets y dispositivos plegables.
Fahd Imtiaz, Miguel Montemayor • Lectura de 3 min -
Novedades de productosLas apps que se orienten a la próxima versión de Android ya no podrán escribir directamente en los contactos con el permiso WRITE_CONTACTS.
Roxanna Aliabadi Walker • Lectura de 6 min
Recibe la información más reciente sobre el desarrollo de Android en tu bandeja de entrada todas las semanas.