Escenario
Eres responsable de una aplicación de Android que combina Views heredadas, Jetpack Compose y SDKs de terceros. Para las aplicaciones que apuntan a Android 16+, windowOptOutEdgeToEdgeEnforcement se elimina, por lo que la aplicación debe manejar los insets de ventana correctamente. Explica cómo identificarías riesgos, cambiarías diseños, validarías factores de forma de dispositivos y controlarías el riesgo de lanzamiento.
Qué evalúa el entrevistador
- Separar "ejecutar de forma compatible en Android 16" de "aumentar targetSdkVersion a 16".
- Verificar sistemáticamente barras del sistema, IME, recortes (cutouts), áreas de gestos y contenedores con scroll.
- Cubrir combinaciones de Views, Compose, bibliotecas y SDKs.
- Diseñar alternadores (toggles) de compatibilidad, versiones canary y reversión (rollback) observable.
Preguntas aclaratorias
Confirma los SDKs de destino y compilación, las versiones de Android compatibles, la división entre View y Compose, la cobertura de modo vertical/horizontal y dispositivos plegables, y el uso de cámara a pantalla completa, mapas o WebView. Pregunta por las líneas base de pruebas de capturas de pantalla, fallos (crashes) y quejas de diseño, y si los SDKs de terceros documentan soporte para edge-to-edge.
Respuesta de 30 segundos
Utilizaría dos fases. Primero, expondría los cambios de comportamiento en Android 16 sin aumentar el target, separando luego las correcciones de insets de la actualización del target. Verificaría diseños raíz, barras, IME, áreas de gestos y desplazamiento a lo largo de Views y Compose. Enviaría una compilación solo de compatibilidad a una cohorte pequeña y monitorearía fallos, quejas de oclusión y la finalización de flujos clave. Aumentaría el target solo después de que pasen las pruebas de regresión por capturas de pantalla y la matriz de dispositivos. Mantendría los cambios de target separados de funciones grandes para que un diseño defectuoso pueda revertirse limpiamente.
Razonamiento paso a paso
1. Separar la compatibilidad de la actualización del target
La guía de migración de Android recomienda probar primero la aplicación existente en Android 16; muchas correcciones no requieren un cambio inmediato de target. Luego, aborda los cambios de comportamiento para aplicaciones que apuntan a Android 16, manteniendo clara la causa de las regresiones.
2. Construir una lista de verificación de insets
Verifica si la raíz consume los insets de las barras del sistema y si las barras de herramientas, la navegación inferior, el último elemento de la lista, los campos de entrada y los cuadros de diálogo quedan ocultos. Establece una única convención de insets para Compose y evita el padding duplicado en Views heredadas. Prueba pantallas de cámara, mapas y WebView con sus propias reglas de área segura (safe-area).
3. Usar herramientas de compatibilidad para acotar el alcance
Los alternadores de compatibilidad de Android 16 pueden habilitar comportamientos específicos sin cambiar targetSdkVersion. Agrégalos a una matriz de dispositivos automatizada que cubra páginas de 4 KB/16 KB, orientación, navegación por tres botones/gestos, plegables y escalado de fuentes. Registra los IDs de cambio y las diferencias en capturas de pantalla.
4. Canary y reversión
Envía una compilación de compatibilidad solo para el diseño, luego aumenta el target en beta y en el 1% del tráfico de producción. Monitorea fallos al inicio, ANRs, éxito de toques en páginas clave, quejas de oclusión inferior y errores de SDK. Mantén aislada la migración de target; revierte a la compilación anterior o deshabilita el punto de entrada afectado cuando sea necesario.
Respuesta de muestra de alta calidad
Establecería una línea base de compatibilidad instalando la compilación de producción actual en emuladores y dispositivos reales con Android 16, ejecutando cada flujo y capturando las regiones de los bordes. Luego, habilitaría únicamente el comportamiento edge-to-edge a través de los alternadores de compatibilidad para identificar si el problema lo causa el diseño raíz, un SDK o los cambios de target. Crearía una capa de manejo de insets, asignaría explícitamente el consumo superior, inferior y del IME, y evitaría el doble padding entre View/Compose; la cámara, el mapa, WebView y los diálogos recibirían pruebas de área segura independientes. Enviaría las correcciones de compatibilidad sin cambiar el target. Después de que pasen las pruebas de capturas de pantalla, accesibilidad, orientación, plegables e IME, aumentaría el target como un cambio aislado: primero en beta, luego en un canary al 1%. Rastrearía fallos, ANRs, conversión principal y comentarios de oclusión; revertiría o deshabilitaría el nuevo punto de entrada ante cualquier regresión. Esto satisface el cambio de plataforma mientras se preserva una atribución clara y la capacidad de reversión.
Errores comunes
- Aumentar targetSdkVersion de inmediato y perder la atribución de regresiones.
- Corregir únicamente la barra de estado pasando por alto la navegación, el IME, plegables, extremos de listas y diálogos.
- Consumir insets en múltiples capas y crear doble padding.
- Probar solo en emuladores omitiendo SDKs, dispositivos reales y escalado de fuentes.
- Agrupar la migración de edge-to-edge con una función grande, perdiendo una reversión independiente.
Preguntas de seguimiento y respuestas
"¿Debe targetSdkVersion cambiarse a 16 inmediatamente?"
No. Prueba el target actual en Android 16 y corrige primero la compatibilidad. Actualiza el target por separado según los requisitos de Play y los tiempos del producto.
"¿Cómo manejas los SDKs de terceros?"
Haz un inventario de ellos y pruébalos en dispositivos reales con alternadores de compatibilidad. Da preferencia a versiones que documenten soporte para edge-to-edge; de lo contrario, agrega un contenedor de área segura o aísla la pantalla afectada.
"¿Cómo demuestras que las versiones anteriores de Android siguen funcionando?"
Ejecuta la misma matriz de capturas de pantalla y flujos críticos en la versión mínima compatible, Android 15 y Android 16 en diferentes orientaciones, modos de navegación y escalas de fuente. Compara las regiones que reciben toques y la oclusión, no solo el éxito al iniciar.