Entrevista de Desarrollador Android: preguntas y respuestas de ejemplo

Respuesta modelo

Lideré la migración de una app de banca con 1,8 millones de usuarios activos mensuales de Fragments con XML a Jetpack Compose. Empezamos por un flujo acotado y de bajo riesgo, el detalle de movimientos, para validar la interoperabilidad con ComposeView dentro de las pantallas antiguas. Definimos un sistema de diseño con Material 3 y componentes propios, y a partir de ahí impusimos la regla de que toda pantalla nueva nacía en Compose. En once meses migramos 142 de 203 pantallas, la capa de presentación quedó con un 24 % menos de código y no empeoramos la tasa de fallos en ningún momento porque cada tanda salía en despliegue escalonado. Lo que más me enorgullece no es la tecnología, sino que el equipo entero adoptó el nuevo enfoque sin parar la entrega de negocio.

Respuesta modelo

Parto de datos, no de intuiciones: en Play Console reviso la distribución real de mis usuarios por versión y por modelo antes de fijar el minSdk. En mi último proyecto el minSdk era 24 porque por debajo quedaba menos del 1,2 % de la base instalada, y el targetSdk lo mantenemos siempre en la última versión exigida por Google Play. Después uso las bibliotecas de AndroidX y las comprobaciones de versión para el comportamiento específico, por ejemplo el permiso POST_NOTIFICATIONS a partir de Android 13 o los tipos de servicio en primer plano en Android 14. Para probarlo tengo una matriz mínima de seis combinaciones en Firebase Test Lab, con al menos un Xiaomi y un Samsung de gama media, que son mayoría en España, y presto atención especial a las capas de fabricante que matan procesos en segundo plano.

Respuesta modelo

Trabajo con Clean Architecture ligera y MVI en la capa de presentación. Cada pantalla tiene un ViewModel que expone un único StateFlow con el estado inmutable y recibe intenciones del usuario; los efectos puntuales, como navegar o mostrar un aviso, van por un canal aparte para que no se repitan al rotar la pantalla. Debajo hay casos de uso en módulos de dominio sin dependencias de Android, lo que permite probarlos con JUnit puro y sin Robolectric. Elegí MVI sobre MVVM clásico porque en pantallas con muchos estados intermedios, como un formulario de transferencia con validaciones y errores del servidor, el estado único evita combinaciones imposibles. No lo aplico como dogma: en pantallas triviales un ViewModel con un par de flujos es suficiente y añadir ceremonia solo encarece el mantenimiento.

Respuesta modelo

Tengo el proceso muy sistematizado. En cada pull request se ejecutan detekt, ktlint, las pruebas unitarias con JUnit y MockK y las pruebas de flujos con Turbine; el merge a main genera un Android App Bundle firmado que GitHub Actions sube al track interno con Gradle Play Publisher. Ahí revisamos el informe previo al lanzamiento de Play Console, que detecta fallos y problemas de accesibilidad en dispositivos reales. Después pasa a pruebas cerradas con unos 250 probadores durante 48 horas y, si Crashlytics está limpio, sale en despliegue escalonado al 1 %, 10 %, 50 % y 100 %, con vigilancia de Android Vitals en cada escalón. Tenemos un criterio de detención escrito: si el porcentaje de usuarios sin fallos baja del 99,5 % o la tasa de ANR supera el 0,4 %, se detiene el despliegue y se publica una corrección.

Respuesta modelo

Sigo las notas de versión de Jetpack y el blog de Android Developers, que es donde primero aparecen los cambios de política de Google Play y los requisitos de targetSdk. Veo las sesiones de Android de Google I/O cuando salen y participo en la comunidad local: he asistido a charlas del GDG de Madrid y sigo a la comunidad hispana de Kotlin. Cuando aparece algo relevante, como Baseline Profiles o el gesto de retroceso predictivo, lo pruebo primero en una app personal que tengo publicada y solo después propongo llevarlo al producto, ya con una medición delante.

Respuesta modelo

Porque me interesa el detalle que solo se ve en la plataforma: el comportamiento del sistema al matar el proceso, el consumo de batería, los servicios en primer plano, la accesibilidad con TalkBack o el rendimiento de la recomposición en gama baja. He trabajado con módulos en Flutter y entiendo cuándo compensa, sobre todo si un equipo pequeño debe cubrir dos plataformas con pantallas de contenido. Pero en productos donde la aplicación es el canal principal, como banca o movilidad, la diferencia en arranque, en integraciones del sistema y en capacidad de diagnóstico es tangible, y ahí prefiero Kotlin nativo con Compose. También sigo con interés Kotlin Multiplatform para compartir la capa de dominio manteniendo la interfaz nativa.

La Activity recorre onCreate, onStart y onResume al pasar a primer plano, y onPause, onStop y onDestroy al abandonarlo. Lo importante en la práctica son dos situaciones distintas. En un cambio de configuración, como una rotación, la Activity se destruye y se recrea, pero el ViewModel sobrevive porque está ligado al ViewModelStore, así que ahí no hay que hacer nada especial. Distinto es la muerte de proceso: si el sistema recupera memoria y mata el proceso, el ViewModel desaparece y al volver el usuario ve un estado vacío. Para eso uso SavedStateHandle en el ViewModel, o rememberSaveable en Compose, guardando solo lo mínimo e identificable, como el identificador del elemento seleccionado o el texto de un formulario, nunca objetos grandes. Lo pruebo forzando la muerte de proceso desde el botón de detener del perfilador de Android Studio o con la opción de desarrollador que limita los procesos en segundo plano. En Fragments añado una precaución más: observar siempre con viewLifecycleOwner y anular la referencia al binding en onDestroyView, porque el ciclo de vida de la vista es más corto que el del Fragment y es la causa clásica de fugas de memoria.

La recomposición es la reejecución de las funciones componibles cuyo estado leído ha cambiado. Compose intenta saltarse las que puede, pero solo lo consigue si los parámetros son estables. Los problemas más habituales que me he encontrado son tres: pasar listas mutables o clases de un módulo sin la anotación de estabilidad, con lo que Compose deja de saltarse el componible; leer el estado demasiado arriba en el árbol, lo que arrastra a recomponer una pantalla entera cuando solo cambia un contador; y crear lambdas nuevas en cada pase. Las soluciones que aplico son usar listas inmutables o persistentes de kotlinx.collections.immutable, bajar la lectura del estado al nivel más profundo posible o diferirla con una lambda, usar derivedStateOf cuando un valor se deriva de otro y solo interesan sus cambios discretos, y poner claves estables en los LazyColumn para que la reutilización sea correcta. Para medir no voy a ciegas: activo los informes de estabilidad del compilador de Compose, uso el contador de recomposiciones del inspector de diseño y confirmo el resultado con Macrobenchmark, mirando los fotogramas con jank en un dispositivo de gama media, no en el buque insignia.

LiveData es consciente del ciclo de vida y fue el estándar durante años, pero está atado a Android y su API es limitada. StateFlow es un flujo caliente con valor inicial que siempre conserva el último valor y distingue por igualdad, así que es lo que uso para el estado de la pantalla: el ViewModel expone un StateFlow del estado de la interfaz y la vista lo recoge con collectAsStateWithLifecycle, que detiene la recolección cuando la pantalla no está visible. SharedFlow no tiene valor inicial y permite configurar la memoria intermedia y las repeticiones; lo uso para eventos que no deben repetirse, como mostrar un aviso o navegar, aunque en muchos casos prefiero modelar el evento dentro del propio estado y consumirlo explícitamente. Un detalle que suele preguntarse es cómo convertir un flujo frío del repositorio en estado: uso stateIn con el ámbito del ViewModel y la política WhileSubscribed con un margen de cinco segundos, para que una rotación no cancele y reinicie la consulta a la base de datos o la petición de red.

Un ANR ocurre cuando el hilo principal no responde a un evento de entrada durante unos cinco segundos, o cuando un receptor o un servicio se pasa de su plazo. Lo primero es ir a Android Vitals en Play Console y ver el desglose por versión de la app, versión de Android y modelo, porque muchas veces el problema está concentrado en una capa de fabricante concreta. Después leo las trazas del ANR: interesa el estado del hilo principal en el momento del bloqueo y si hay un interbloqueo o una espera sobre otro hilo. Las causas que más veces he encontrado son E/S de disco o consultas a Room ejecutadas en el hilo principal, deserialización de respuestas grandes sin trasladar a Dispatchers.IO, transacciones de base de datos sincronizadas dentro de un bloqueo compartido y trabajo pesado en onCreate o en un BroadcastReceiver. Para reproducirlo uso Perfetto y el perfilador de la CPU, y activo StrictMode en las compilaciones de depuración para que el problema salte en desarrollo. La corrección típica es mover el trabajo a una corrutina con el despachador adecuado, o a WorkManager si es diferible, y añadir después una prueba de rendimiento que impida la regresión.

Cada cambio de esquema sube la versión de la base de datos y lleva su objeto Migration, o una migración automática si el cambio es simple y el esquema exportado está en el control de versiones. Mantengo activada la exportación del esquema JSON precisamente para eso y para poder escribir pruebas de migración con MigrationTestHelper, que abre la base de datos en la versión antigua, inserta datos representativos, aplica la migración y comprueba que la información se conserva. La regla que no rompo nunca es no usar la destrucción de la base de datos en migraciones fallidas en producción, porque equivale a perder los datos del usuario; en la app de banca eso habría significado borrar el histórico en caché de miles de personas. Para cambios complejos, como partir una tabla, hago la migración en pasos dentro de una transacción y ejecuto una prueba encadenada de la versión más antigua soportada hasta la actual. Además expongo las consultas como Flow, así la interfaz se actualiza sola tras la migración, y marco con @Transaction los métodos que hacen varias operaciones relacionadas.

Primero mido en lugar de suponer: uso Macrobenchmark con StartupTimingMetric en un dispositivo de gama media y saco una traza de Perfetto para ver qué ocurre entre la creación del proceso y el primer fotograma dibujado. Los culpables habituales son la inicialización de bibliotecas en Application.onCreate, los inicializadores de ContentProvider que arrastran las dependencias, la lectura sincronizada de preferencias y las peticiones de red lanzadas antes de tiempo. Las medidas que aplico son trasladar todo lo que no sea imprescindible a App Startup con inicialización perezosa o a una corrutina posterior al primer dibujado, retirar bibliotecas que se inicializan solas, y evitar pantallas de arranque artificiales usando la API de SplashScreen. La palanca más rentable en mi experiencia han sido los Baseline Profiles: al incluir el perfil generado con Macrobenchmark en el App Bundle, el código crítico se compila anticipadamente y el arranque mejoró alrededor de un 30 %, de 2,4 a 1,3 segundos. Después vigilo la métrica de tiempo de arranque en Android Vitals para confirmar que la mejora se sostiene en el parque real y no solo en el laboratorio.

Lo primero, detener el despliegue en Play Console para que no siga alcanzando usuarios; eso es cuestión de minutos y no requiere ninguna decisión compleja. A continuación abro Crashlytics para identificar el fallo dominante, en qué versión de Android y en qué modelos se concentra, y qué porcentaje de sesiones afecta. Si el origen está en la configuración remota, muchas veces se resuelve sin publicar nada: desactivo la funcionalidad con Remote Config y los usuarios afectados se recuperan en la siguiente sesión. Si es un fallo de código, preparo la corrección con una prueba que lo reproduzca, la publico en el track interno y la subo por escalones vigilando Android Vitals. En paralelo aviso a producto y a atención al cliente con una estimación honesta, porque son quienes reciben las valoraciones negativas en la ficha. Después hago un análisis sin culpables: en el último caso que viví, el fallo venía de un campo nulo que el backend empezó a enviar y que no cubríamos, y la conclusión fue añadir pruebas de contrato y una serialización tolerante a campos desconocidos.

No lo planteo como un no rotundo, sino como un dato. Implemento un prototipo y lo mido con Macrobenchmark en un dispositivo representativo de nuestra base, normalmente un Samsung de gama A o un Xiaomi Redmi, y enseño los fotogramas con jank y el efecto en la batería. Con esa evidencia delante busco alternativas con diseño: simplificar la transición, usar la animación solo cuando el dispositivo la soporte con holgura, o respetar la preferencia de reducción de movimiento del sistema, que además mejora la accesibilidad. En una ocasión acabamos manteniendo la animación completa en dispositivos por encima de cierto umbral y una transición sencilla en el resto, algo que en Compose se resuelve limpiamente. Lo importante es que la conversación deja de ser una opinión contra otra y pasa a ser una decisión de producto informada.

Empiezo por acotarlo con los datos de Crashlytics y Play Console: versión de Android, versión de la capa del fabricante, memoria disponible y si ocurre tras volver de segundo plano. Muchos de estos casos tienen que ver con la gestión agresiva de procesos y con las restricciones de batería propias de MIUI, así que compruebo si estamos ante una muerte de proceso mal gestionada o un trabajo en segundo plano cancelado. Para reproducirlo uso Firebase Test Lab, que ofrece dispositivos físicos de esos fabricantes, y le añado registro remoto o un rastro personalizado en Crashlytics para capturar la secuencia. Si sigo sin verlo, publico una versión con más instrumentación en el track cerrado con probadores que tengan ese modelo. Y si la causa es la política de batería del fabricante, la solución suele estar en usar WorkManager con reintentos, un servicio en primer plano cuando la tarea lo justifica y explicar al usuario, desde la propia app, cómo excluirla de la optimización de batería.

Lo trato como una fecha innegociable, porque si no se cumple no se pueden publicar actualizaciones. Primero subo el targetSdk en una rama y ejecuto la batería completa de pruebas para tener el inventario real de lo que se rompe; después leo los cambios de comportamiento de esa versión y marco los que nos afectan, por ejemplo los tipos de servicio en primer plano, el acceso a almacenamiento o los permisos nuevos. Con eso preparo una lista priorizada por riesgo y la negocio con producto: normalmente aparto un porcentaje de la capacidad del sprint durante tres o cuatro sprints en lugar de parar la entrega de negocio. Lo saco en tandas pequeñas al track interno para no acumular todo el riesgo al final, y reservo la última semana como colchón. En los tres ciclos que he gestionado así llegamos siempre con margen y sin regresiones.

Preparo el caso con datos en lugar de discutir en abstracto. En un proyecto reciente, la propuesta obligaba a la app a hacer cuatro llamadas encadenadas para pintar la pantalla principal, lo que en una red móvil de calidad media suponía más de dos segundos de espera y complicaba el manejo de errores parciales. Lo medí, lo enseñé con la traza y propuse una alternativa concreta: un único punto de entrada agregado para esa pantalla. Backend tenía sus propias restricciones de plazo, así que acordamos una solución en dos fases: yo implementaba la agregación en el cliente con corrutinas en paralelo y caché en Room para no bloquear la entrega, y ellos incorporaban el punto agregado en el trimestre siguiente. Lo dejamos escrito en un registro de decisión de arquitectura para que la deuda técnica quedara visible y no se olvidara.