Con el lanzamiento de Android 16 en el 2025, compartimos nuestra visión de un ecosistema de dispositivos en el que las aplicaciones se adapten perfectamente a cualquier pantalla, ya sea de un teléfono, un plegable, una tablet, un ordenador, una pantalla de coche o un dispositivo de realidad extendida. Los usuarios esperan que sus aplicaciones funcionen en cualquier lugar. Tanto si hacen varias tareas a la vez en una tablet, como si abren un dispositivo para leer cómodamente o ejecutan aplicaciones en un entorno de ventanas de escritorio, los usuarios esperan que la interfaz de usuario ocupe el espacio de pantalla disponible y se adapte a la postura del dispositivo.

Hemos introducido cambios significativos en las APIs de orientación y cambio de tamaño para facilitar el comportamiento adaptativo, al tiempo que hemos proporcionado una opción de inhabilitación temporal para ayudarte a hacer la transición. Hemos visto que muchos desarrolladores se han adaptado correctamente a esta transición al orientar sus aplicaciones 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 adaptativa: Android 17 (nivel de API 37) elimina la opción de inhabilitar las restricciones de orientación y redimensionamiento para desarrolladores en dispositivos de pantalla grande (sw > 600 dp). Si orientas tu aplicación al nivel de API 37, esta debe poder adaptarse a diferentes tamaños de pantalla.

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

Cambios en Android 17

Las aplicaciones orientadas a Android 17 deben asegurarse de que sean compatibles con la retirada de los atributos del manifiesto y las APIs de tiempo de ejecución introducidas en Android 16. Somos conscientes de que, para algunas aplicaciones, puede ser una transición importante, por lo que hemos incluido prácticas recomendadas y herramientas para ayudar a evitar problemas comunes más adelante en esta entrada de blog.

No se han introducido cambios nuevos desde Android 16, pero los desarrolladores ya no pueden inhabilitar esta función. Te recordamos que, cuando tu aplicación se ejecuta en una pantalla grande (es decir, cuando la dimensión más pequeña de la pantalla es igual o superior a 600 dp), se ignoran los siguientes atributos del archivo de manifiesto y APIs:

Nota:  Como ya hemos mencionado en Android 16, estos cambios no se aplican a las pantallas que tengan un ancho inferior a 600 dp ni a las aplicaciones clasificadas como juegos según la marca android:appCategory. 

Además, los usuarios conservan el control. En los ajustes de relación de aspecto, los usuarios pueden habilitar explícitamente el comportamiento solicitado por la aplicación.

Preparar la aplicación

Las aplicaciones deberán admitir diseños horizontales y verticales para tamaños de pantalla en toda la gama de relaciones de aspecto en las que los usuarios puedan elegir usar las aplicaciones, incluidas las ventanas redimensionables, ya que no habrá forma de restringir la relación de aspecto y la orientación a vertical u horizontal.

Probar la aplicación

El primer paso es probar la aplicación con estos cambios para asegurarte de que funciona bien en pantallas de diferentes tamaños.

Usa Android 17 Beta 1 con los emuladores de las series Pixel Tablet y Pixel Fold en Android Studio, y define el targetSdkPreview = “CinnamonBun”. También puedes usar el framework de compatibilidad de aplicaciones habilitando la marca UNIVERSAL_RESIZABLE_BY_DEFAULT si tu aplicación aún no está orientada al nivel de API de destino 36.

Tenemos herramientas adicionales para asegurarnos de que tus diseños se adapten correctamente. Puedes auditar automáticamente tu interfaz de usuario y recibir sugerencias para que sea más adaptativa con Compose UI Check, así como simular características de pantalla específicas en tus pruebas con DeviceConfigurationOverride.

En las aplicaciones que han restringido históricamente la orientación y la relación de aspecto, solemos ver problemas con las vistas previas de la cámara inclinadas o mal orientadas, diseños estirados, botones inaccesibles o pérdida del estado del usuario al gestionar los cambios de configuración. 

Veamos algunas estrategias para abordar estos problemas habituales.

Comprobar la compatibilidad de la cámara

Un problema habitual en los plegables en horizontal o en los cálculos de la relación de aspecto en situaciones como el modo multiventana, el modo Ventanas de escritorio o las pantallas conectadas es que la vista previa de la cámara aparece estirada, girada o recortada.

Comprueba que la vista previa de la cámara no esté estirada ni girada.

Este problema suele producirse en dispositivos con pantallas grandes y plegables porque las aplicaciones asumen 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, puedes probar estas cuatro soluciones:

Solución 1: Jetpack CameraX (opción preferida) 

La solución más sencilla y sólida es usar la biblioteca CameraX de Jetpack. Su elemento de interfaz de usuario PreviewView se ha diseñado para gestionar 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 escalado
• PreviewView mantiene la relación de aspecto de la imagen de la cámara, normalmente centrándola y recortándola (FILL_CENTER).
• Puedes definir el tipo de escala en FIT_CENTER para añadir bandas 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 de Camera2, 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 usando un TextureView o un SurfaceView y aplicando todas las transformaciones necesarias (relación de aspecto, escala y rotación).

Para obtener más información, consulta la entrada de blog Presentamos el visor de la cámara y la guía para desarrolladores 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.
• Obtiene 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 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 la aplicación Cámara puede 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, la vista previa de la cámara se verá estirada.

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

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

Si no necesitas muchas funciones de la cámara, una solución sencilla es realizar acciones básicas de la cámara, como hacer una foto o grabar un vídeo, 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 cámara.

Evita que la interfaz de usuario se estire o que los botones sean inaccesibles

Si tu aplicación da por supuesta una orientación o una relación de aspecto de la pantalla específicas, puede que tenga problemas cuando se use en diferentes 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 en fillMaxWidth o match_parent.  En un teléfono, queda genial. Sin embargo, en una tablet o un dispositivo plegable en horizontal, los elementos de la interfaz de usuario se extienden por toda la pantalla grande. En Jetpack Compose, puedes usar el modificador widthIn para definir una anchura máxima de 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 aplicación en orientación horizontal en una tablet o un dispositivo plegable, es posible que los botones de acción, como Guardar o Iniciar sesión, situados en la parte inferior de la pantalla no se muestren. Si el contenedor no se puede desplazar, es posible que el usuario no pueda continuar. En Jetpack Compose, puedes añadir un modificador verticalScroll a tu componente:

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

Si combinas las restricciones de anchura máxima con el desplazamiento vertical, te aseguras de que tu aplicación siga funcionando y siendo usable, independientemente de la anchura o la altura de la ventana de la aplicación.

Consulta nuestra guía sobre cómo crear diseños adaptativos.

Conservar el estado con cambios de configuración

Si quitas las restricciones de orientación y relación de aspecto, el tamaño de la ventana de tu aplicación cambiará con mucha más frecuencia. Los usuarios pueden girar el dispositivo, plegarlo o desplegarlo, o cambiar el tamaño de tu aplicación 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 aplicación no gestiona 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 rellenados a medias se borrarán y se perderá el historial de navegación. Para ofrecer una experiencia adaptativa fluida, es fundamental que tu aplicación 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 en el tamaño de la ventana vuelvan a componer tu interfaz de usuario para reflejar la nueva cantidad de espacio disponible.

Consulta nuestra guía sobre cómo guardar el estado de la interfaz de usuario.

Orientación al nivel de API 37 antes de agosto del 2027

Si tu aplicación se había excluido de estos cambios al orientarse al nivel 36 de la API, solo se verá afectada por la eliminación de la opción de exclusión de Android 17 cuando se oriente al nivel 37 de la API. Para ayudarte a planificar y hacer los ajustes necesarios en tu aplicación, te indicamos el calendario de entrada en vigor de estos cambios:

• Android 17: los cambios descritos anteriormente serán la experiencia básica para los dispositivos con pantallas grandes (ancho de pantalla más pequeño > 600 dp) en las aplicaciones orientadas al nivel de API 37. Los desarrolladores no podrán inhabilitar esta opción.

Los plazos para orientar a un nivel de API específico varían en función de la tienda de aplicaciones. En Google Play, las aplicaciones nuevas y las actualizaciones deberán orientarse al nivel 37 de la API, por lo que este comportamiento será obligatorio para la distribución en agosto del 2027.

Preparación para Android 17

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

El futuro de Android es adaptativo, y estamos aquí para ayudarte a llegar a él. Mientras te preparas para Android 17, te recomendamos que consultes nuestras guías sobre cómo crear diseños adaptables y nuestras directrices de calidad para pantallas grandes. Estos recursos están diseñados para ayudarte a gestionar varios factores de forma y tamaños de ventana con confianza.

No esperes más: Empieza a prepararte para Android 17 hoy mismo