AVD Android: qué es, Android Virtual Device y cómo configurar el emulador

Qué es AVD

AVD (Android Virtual Device) es una configuración de software que describe un dispositivo Android virtual. A diferencia de un teléfono físico, un AVD no requiere hardware — se ejecuta en un ordenador a través del emulador de Android basado en QEMU. Un desarrollador crea tantos AVD como necesite para probar: para diferentes versiones de Android, tamaños de pantalla, capacidades de memoria y densidades de píxeles.

Cada AVD está vinculado a una SDK Platform específica. Esto significa que para crear un AVD con Android 14 (API Level 34), primero debes instalar la System Image de esa versión a través del SDK Manager. La System Image es una imagen del sistema operativo que incluye todas las aplicaciones del sistema, los servicios de Google (si se selecciona la imagen de Google APIs) y los componentes de tiempo de ejecución. Google recomienda utilizar imágenes de Google APIs con servicios de Google Play para obtener la máxima compatibilidad con dispositivos reales.

AVD es indispensable en el desarrollo por varias razones. Primero, permite probar la aplicación en diferentes versiones de Android sin comprar decenas de dispositivos. Segundo, AVD admite Snapshots — guardar el estado del sistema, lo que acelera el inicio. Tercero, el emulador está integrado con Android Studio: la instalación de APK, la depuración y el registro funcionan igual que en un dispositivo físico.

Tipos de dispositivos virtuales

AVD admite varios tipos de dispositivos: teléfonos, tabletas, relojes Wear OS, Android TV y Android Automotive. Para cada tipo, AVD Manager proporciona perfiles prediseñados de Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab y otros. El perfil del dispositivo define el tamaño de la pantalla, la resolución, la densidad de píxeles (dpi) y la navegación (gestos o botones).

De qué está compuesto un AVD

Cada AVD es un conjunto de archivos de configuración e imágenes. El archivo de configuración principal es config.ini, que almacena los parámetros del dispositivo virtual: nombre, tipo, API Level, tamaño de pantalla, RAM y tamaño del heap de la VM. El archivo se encuentra en el directorio $HOME/.android/avd/NombreAVD.avd/ y se puede modificar manualmente, aunque normalmente se edita a través de AVD Manager.

Además de config.ini, el directorio del AVD almacena: userdata.img (imagen de datos de usuario — aplicaciones, configuraciones, archivos), system.img (enlace a la System Image de la SDK Platform instalada), cache.img (caché) y sdcard.img (imagen de la tarjeta SD). Al realizar Wipe Data, se elimina userdata.img y se crea una nueva imagen vacía. Los Snapshots se guardan en una carpeta separada snapshots/ dentro del directorio del AVD.

La System Image se descarga por separado del AVD — una imagen puede ser utilizada por múltiples dispositivos virtuales. Las imágenes del sistema se almacenan en el directorio de Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Tipos de imágenes: google_apis (con servicios de Google), google_apis_playstore (con Google Play Store) y default (AOSP puro sin servicios de Google).

Tipos de System Images

Creación de un AVD mediante AVD Manager

AVD Manager es una herramienta gráfica en Android Studio para crear y gestionar dispositivos virtuales. Se puede abrir a través del menú Tools → Device Manager o mediante el icono de la barra de herramientas. AVD Manager muestra la lista de dispositivos creados, su estado (ejecutándose/detenido), la versión de Android y las acciones disponibles (iniciar, detener, wipe data, editar).

Para crear un nuevo AVD, haz clic en el botón Create device. Selecciona un perfil de dispositivo de la lista prediseñada — Google proporciona perfiles para todos los dispositivos populares. Después de seleccionar un perfil, especifica la System Image: la versión de Android y el tipo de imagen. Para proyectos nuevos, elige la última versión estable con la imagen de Google APIs. Luego configura el nombre del AVD, la orientación de la pantalla, la RAM y el tamaño del heap de la VM. Después de la creación, el AVD está listo para iniciarse.

Creación paso a paso de un AVD desde la línea de comandos

# 1. Listar System Images disponibles
sdkmanager --list | grep system-images

# 2. Instalar System Image para API 35 con Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. Crear AVD con nombre pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Iniciar el AVD creado
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Listar todos los AVD
avdmanager list avd

Configuración de las características de hardware del AVD

AVD Manager permite configurar detalladamente las características de hardware del dispositivo virtual. Parámetros principales: RAM (memoria de acceso aleatorio, valor recomendado 2048–4096 MB), VM heap (tamaño del heap de la máquina virtual, 256–512 MB), Internal Storage (almacenamiento interno, 2–8 GB) y SD Card (tarjeta SD virtual). Estos parámetros afectan el rendimiento de la aplicación y su comportamiento ante la falta de memoria.

Las configuraciones adicionales incluyen: cámara (emulada o conexión de cámara web del host), sensores (acelerómetro, giroscopio), NFC, Bluetooth y batería. Por ejemplo, para probar aplicaciones con detección de ubicación, se puede emular la rotación del dispositivo mediante los botones de control del emulador o a través de ADB. La emulación de sensores permite probar escenarios que son difíciles de reproducir en un dispositivo físico.

Parámetros clave de config.ini

Optimización del rendimiento del emulador

La velocidad del AVD depende directamente de la virtualización de hardware. En Windows se utiliza Windows Hypervisor Platform (WHPX), en macOS — Hypervisor.Framework, en Linux — KVM. Si la virtualización está desactivada, el AVD funciona en modo de emulación puramente software, que es de 10 a 20 veces más lento. Para comprobar si la virtualización está activada, ejecuta el emulador con el flag -accel-check.

El segundo factor clave es la elección de la arquitectura de la System Image. Las imágenes x86_64 funcionan significativamente más rápido que arm64-v8a en ordenadores con procesadores Intel y AMD, ya que no requieren traducción dinámica de instrucciones ARM. Utiliza siempre imágenes x86_64 para el desarrollo en Windows y macOS con procesadores Intel. En procesadores ARM de Mac (Apple Silicon), utiliza imágenes nativas arm64-v8a.

Flags de línea de comandos para aceleración

# Iniciar con virtualización de hardware y aceleración GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Verificar soporte de virtualización
emulator -accel-check

# Ejecutar sin interfaz gráfica (para CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Usar snapshots para inicio rápido
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Consejos de rendimiento del emulador

Para obtener el máximo rendimiento del AVD: asigna al emulador al menos 2–4 GB de RAM, activa GPU Host (utiliza la tarjeta gráfica del ordenador para el renderizado), desactiva el sonido (flag -no-audio) si no es necesario, y utiliza Snapshots para volver rápidamente a un estado limpio. Los Snapshots guardan el estado completo del sistema — el inicio desde una instantánea toma de 2 a 5 segundos en lugar de 30 a 60 segundos de una carga completa.

También se recomienda almacenar el AVD en un disco SSD — las operaciones de E/S durante el inicio del sistema y la instalación de APK son significativamente más rápidas. Para ejecutar varios AVD simultáneamente, aumenta la cantidad total de RAM en el ordenador y utiliza el flag -read-only para emuladores inmutables.

Gestión de AVD desde la línea de comandos

El control completo sobre los AVD es posible desde la línea de comandos sin Android Studio. Las herramientas avdmanager y emulator forman parte de Android SDK y realizan todas las operaciones: crear, eliminar, iniciar y configurar AVD. La línea de comandos es especialmente útil en pipelines de CI/CD, donde no hay interfaz gráfica, y para la automatización de pruebas.

Comandos básicos de gestión de AVD

# Crear AVD con parámetros personalizados
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Eliminar AVD
avdmanager delete avd -n test_device

# Clonar AVD (copiando archivos)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Restablecer datos del AVD
emulator -avd test_device -wipe-data

# Instalar APK en el AVD en ejecución
adb -s emulator-5554 install app-release.apk

ADB y AVD: comandos clave

Después de iniciar un AVD, se puede trabajar con él a través de ADB (Android Debug Bridge) igual que con un dispositivo físico. ADB permite instalar aplicaciones, lanzar intents, emular eventos (llamadas, SMS, GPS), hacer capturas de pantalla y grabar vídeo de la pantalla. Esto convierte a AVD en un entorno completo para pruebas automatizadas.

# Listar dispositivos conectados (incluyendo AVD)
adb devices

# Simular llamada entrante
adb emu gsm call +15551234567

# Simular coordenadas GPS
adb emu geo fix -122.084 37.422

# Tomar captura de pantalla
adb exec-out screencap -p > screenshot.png

# Enviar SMS
adb emu sms send +15551234567 "Hello from AVD"

Verificación del emulador en el código de la aplicación

A veces el desarrollador necesita determinar en el código si la aplicación se ejecuta en un emulador o en un dispositivo físico. Esto puede ser necesario para desactivar la analítica (para no contaminar los datos de producción), activar el registro ampliado o desactivar funciones dependientes del hardware que no funcionan en el emulador. Google proporciona métodos estándar de verificación a través de la clase Build y las propiedades del sistema.

Método de verificación mediante propiedades de Build

object EmulatorDetector {
    fun isEmulator(): Boolean {
        return (Build.BRAND.startsWith("generic") &&
                Build.DEVICE.startsWith("generic")) ||
                Build.FINGERPRINT.startsWith("generic") ||
                Build.FINGERPRINT.startsWith("unknown") ||
                Build.HARDWARE.contains("goldfish") ||
                Build.HARDWARE.contains("ranchu") ||
                Build.MODEL.contains("google_sdk") ||
                Build.MODEL.contains("Emulator") ||
                Build.MODEL.contains("Android SDK")
    }
}

// Uso
if (EmulatorDetector.isEmulator()) {
    Log.d("App", "Running on emulator — enable debug mode")
}

Verificación mediante propiedades del sistema

Un método adicional es la lectura de propiedades del sistema a través de Build.getRadioVersion() y la comprobación de ro.kernel.qemu. En el emulador, radio version devuelve null y la propiedad qemu está establecida en 1. Este método es más fiable en versiones antiguas de Android donde Build.FINGERPRINT puede ser falsificado por el fabricante del dispositivo.

fun isRunningOnEmulator(): Boolean {
    // Verificar mediante radio version — en emulador siempre null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Verificar mediante propiedades del sistema
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}