Especificidades del Testing en Android

Fundamentos del Testing en Android #

El ecosistema abierto de Android crea oportunidades y desafios para los testers. La libertad que permite a miles de fabricantes personalizar Android tambien crea el desafio de fragmentacion que define el QA en Android.

Ciclo de Vida del Activity #

El ciclo de vida del Activity es el concepto mas importante para testers Android. Los Activities (pantallas) pasan por transiciones de estado especificas que frecuentemente causan bugs.

Estados del Activity #

Created → Started → Resumed → Paused → Stopped → Destroyed

Cambios de Configuracion #

Cuando la configuracion del dispositivo cambia, Android destruye y recrea el Activity:

• Rotacion de pantalla (portrait ↔ landscape)
• Cambio de idioma
• Cambio de tamano de fuente
• Toggle de dark mode
• Modo multi-ventana entrar/salir

Esta es la fuente #1 de bugs especificos de Android. Prueba cada pantalla despues de:

1. Rotar el dispositivo durante una operacion
2. Cambiar el tamano de fuente en configuracion
3. Alternar dark mode
4. Entrar y salir del modo pantalla dividida

Herramientas de Testing Android #

ADB (Android Debug Bridge) #

ADB es la herramienta de linea de comandos para comunicarse con dispositivos Android:

# Gestion de dispositivos
adb devices                    # Listar dispositivos
adb install app.apk           # Instalar APK
adb install -r app.apk        # Reinstalar (mantener datos)
adb uninstall com.example.app # Desinstalar

# Screenshots y grabacion
adb shell screencap /sdcard/screen.png
adb pull /sdcard/screen.png ./
adb shell screenrecord /sdcard/video.mp4

# Gestion de apps
adb shell am start -n com.example/.MainActivity
adb shell am force-stop com.example
adb shell pm clear com.example

# Debugging
adb logcat                     # Ver logs
adb logcat *:E                 # Solo errores

Espresso #

Espresso es el framework de testing de UI in-process de Google:

@Test
fun testLoginFlow() {
    onView(withId(R.id.emailInput))
        .perform(typeText("user@example.com"), closeSoftKeyboard())

    onView(withId(R.id.passwordInput))
        .perform(typeText("password123"), closeSoftKeyboard())

    onView(withId(R.id.signInButton))
        .perform(click())

    onView(withText("Welcome"))
        .check(matches(isDisplayed()))
}

UI Automator #

UI Automator funciona fuera del proceso de la app, permitiendo interaccion a nivel de sistema:

@Test
fun testNotificationInteraction() {
    val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
    device.openNotification()

    val notification = device.findObject(UiSelector().text("New message"))
    notification.click()

    onView(withId(R.id.messageView))
        .check(matches(isDisplayed()))
}

Testing Especifico de Fabricantes #

Los fabricantes de Android agregan comportamientos custom que pueden romper apps:

Samsung (One UI) #

• Optimizacion agresiva de bateria mata apps en segundo plano
• Manejo custom de notificaciones
• Panel Edge con interacciones adicionales
• Secure Folder crea una instancia separada de la app

Xiaomi (MIUI) #

• Permiso “Autostart” requerido para procesos en segundo plano
• Gestor de permisos custom
• Gestion agresiva de RAM
• Comportamiento custom de la bandeja de notificaciones

Huawei (EMUI/HarmonyOS) #

• Sin Google Play Services (usa HMS)
• Sistema custom de push notifications
• Gestion agresiva de energia
• Lista de apps protegidas

Escenarios de Testing Especificos de Android #

Boton Atras y Navegacion #

El boton atras de Android debe probarse en cada pantalla:

Checklist:
□ Atras desde cada pantalla navega a la pantalla anterior esperada
□ Atras desde la primera pantalla sale de la app o muestra confirmacion
□ Atras durante una operacion (cargando, guardando) maneja correctamente
□ Atras despues de deep link abre la pantalla padre correcta
□ Navegacion por gestos funciona identicamente al boton

Testing Multi-Ventana y Plegables #

Escenarios:
□ App en modo pantalla dividida renderiza correctamente
□ App maneja redimensionamiento de ventana suavemente
□ Datos se preservan al entrar/salir de pantalla dividida
□ App en plegable: layout plegado vs desplegado
□ Drag and drop entre app y otra app en pantalla dividida

Testing de Intents y Deep Links #

# Probar deep link
adb shell am start -a android.intent.action.VIEW   -d "myapp://product/12345" com.example.app

# Probar intent de compartir
adb shell am start -a android.intent.action.SEND   --es android.intent.extra.TEXT "Contenido compartido"   -t text/plain com.example.app

Ejercicio: Caza de Fragmentacion Android #

Escenario: Tu app funciona perfectamente en un Google Pixel 8 pero los usuarios reportan problemas en Samsung y Xiaomi.

1. Push notifications no aparecen en dispositivos Xiaomi
2. Reproduccion de musica en segundo plano se detiene despues de 10 minutos en Samsung
3. App crashea en rotacion mientras se llena un formulario multi-paso

Tips Profesionales #

Tip 1: Mantiene ADB en tu PATH y usalo diariamente. Limpiar datos, simular condiciones de red y capturar logs via ADB es mas rapido que cualquier herramienta GUI.

Tip 2: Prueba en Samsung primero para Android. Samsung representa 30-40% del mercado Android. Si funciona en Samsung, cubriste tu segmento mas grande.

Tip 3: Siempre prueba rotacion con datos en pantalla. Rota mientras llenas un formulario, miras un video, en un chat o durante un flujo de pago.

Puntos Clave #

• El ciclo de vida del Activity y los cambios de configuracion son la fuente #1 de bugs especificos de plataforma
• ADB es una herramienta esencial — aprende los comandos clave
• Espresso prueba in-process para velocidad; UI Automator cruza limites de proceso
• Personalizaciones de fabricantes crean bugs especificos que Android stock no exhibe
• Siempre prueba rotacion, navegacion atras y modo multi-ventana