AVD Android: o que é, Android Virtual Device e como configurar o emulador

O que é AVD

AVD (Android Virtual Device) é uma configuração de software que descreve um dispositivo Android virtual. Ao contrário de um telefone físico, um AVD não requer hardware — ele funciona num computador através do emulador Android baseado em QEMU. Um desenvolvedor cria quantos AVDs forem necessários para testar: para diferentes versões do Android, tamanhos de ecrã, capacidades de memória e densidades de píxeis.

Cada AVD está vinculado a uma SDK Platform específica. Isto significa que, para criar um AVD com Android 14 (API Level 34), primeiro é necessário instalar a System Image dessa versão através do SDK Manager. A System Image é uma imagem do sistema operativo que inclui todas as aplicações de sistema, serviços Google (se a imagem Google APIs for selecionada) e componentes de tempo de execução. A Google recomenda utilizar imagens Google APIs com serviços Google Play para máxima compatibilidade com dispositivos reais.

O AVD é indispensável no desenvolvimento por várias razões. Primeiro, permite testar a aplicação em diferentes versões do Android sem comprar dezenas de dispositivos. Segundo, o AVD suporta Snapshots — guardar o estado do sistema, o que acelera o arranque. Terceiro, o emulador está integrado com o Android Studio: instalação de APK, depuração e registo funcionam como num dispositivo físico.

Tipos de dispositivos virtuais

O AVD suporta vários tipos de dispositivos: telemóveis, tablets, relógios Wear OS, Android TV e Android Automotive. Para cada tipo, o AVD Manager fornece perfis prontos da Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab e outros. O perfil do dispositivo define o tamanho do ecrã, resolução, densidade de píxeis (dpi) e navegação (gestos ou botões).

Do que é composto um AVD

Cada AVD é um conjunto de ficheiros de configuração e imagens. O principal ficheiro de configuração é o config.ini, que armazena os parâmetros do dispositivo virtual: nome, tipo, API Level, tamanho do ecrã, RAM e tamanho do heap da VM. O ficheiro encontra-se no diretório $HOME/.android/avd/NomeAVD.avd/ e pode ser modificado manualmente, embora seja normalmente editado através do AVD Manager.

Além do config.ini, o diretório do AVD armazena: userdata.img (imagem de dados do utilizador — aplicações, configurações, ficheiros), system.img (ligação para a System Image da SDK Platform instalada), cache.img (cache) e sdcard.img (imagem do cartão SD). Ao realizar Wipe Data, o userdata.img é eliminado e é criada uma nova imagem vazia. Os Snapshots são guardados numa pasta separada snapshots/ dentro do diretório do AVD.

A System Image é descarregada separadamente do AVD — uma imagem pode ser usada por múltiplos dispositivos virtuais. As imagens de sistema são armazenadas no diretório do Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Tipos de imagem: google_apis (com serviços Google), google_apis_playstore (com Google Play Store) e default (AOSP puro sem serviços Google).

Tipos de System Images

Criação de um AVD através do AVD Manager

AVD Manager é uma ferramenta gráfica no Android Studio para criar e gerir dispositivos virtuais. Pode ser aberto através do menu Tools → Device Manager ou através do ícone na barra de ferramentas. O AVD Manager mostra a lista de dispositivos criados, o seu estado (em execução/parado), a versão do Android e as ações disponíveis (iniciar, parar, wipe data, editar).

Para criar um novo AVD, clique no botão Create device. Selecione um perfil de dispositivo da lista pronta — a Google fornece perfis para todos os dispositivos populares. Após selecionar um perfil, especifique a System Image: versão do Android e tipo de imagem. Para novos projetos, escolha a versão estável mais recente com a imagem Google APIs. Em seguida, configure o nome do AVD, orientação do ecrã, RAM e tamanho do heap da VM. Após a criação, o AVD está pronto para ser iniciado.

Criação passo a passo de um AVD a partir da linha de comandos

# 1. Listar System Images disponíveis
sdkmanager --list | grep system-images

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

# 3. Criar AVD com nome pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Iniciar o AVD criado
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Listar todos os AVDs
avdmanager list avd

Configuração das características de hardware do AVD

O AVD Manager permite configurar detalhadamente as características de hardware do dispositivo virtual. Parâmetros principais: RAM (memória de acesso aleatório, valor recomendado 2048–4096 MB), VM heap (tamanho do heap da máquina virtual, 256–512 MB), Internal Storage (armazenamento interno, 2–8 GB) e SD Card (cartão SD virtual). Estes parâmetros afetam o desempenho da aplicação e o seu comportamento em condições de pouca memória.

As configurações adicionais incluem: câmara (emulada ou ligação à webcam do hospedeiro), sensores (acelerómetro, giroscópio), NFC, Bluetooth e bateria. Por exemplo, para testar aplicações com deteção de localização, pode-se emular a rotação do dispositivo através dos botões de controlo do emulador ou via ADB. A emulação de sensores permite testar cenários difíceis de reproduzir num dispositivo físico.

Parâmetros chave do config.ini

Otimização do desempenho do emulador

A velocidade do AVD depende diretamente da virtualização de hardware. No Windows utiliza-se Windows Hypervisor Platform (WHPX), no macOS — Hypervisor.Framework, no Linux — KVM. Se a virtualização estiver desativada, o AVD funciona em modo de emulação puramente por software, que é 10 a 20 vezes mais lento. Para verificar se a virtualização está ativada, execute o emulador com o flag -accel-check.

O segundo fator chave é a escolha da arquitetura da System Image. As imagens x86_64 funcionam significativamente mais rápido que arm64-v8a em computadores com processadores Intel e AMD, pois não requerem tradução dinâmica de instruções ARM. Utilize sempre imagens x86_64 para desenvolvimento em Windows e macOS com processadores Intel. Em processadores ARM Mac (Apple Silicon), utilize imagens nativas arm64-v8a.

Flags de linha de comandos para aceleração

# Iniciar com virtualização de hardware e aceleração GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Verificar suporte de virtualização
emulator -accel-check

# Executar sem interface gráfica (para CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

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

Dicas de desempenho do emulador

Para máximo desempenho do AVD: atribua ao emulador pelo menos 2–4 GB de RAM, ative GPU Host (usa a placa gráfica do computador para renderização), desative o som (flag -no-audio) se não for necessário, e utilize Snapshots para voltar rapidamente a um estado limpo. Os Snapshots guardam o estado completo do sistema — o arranque a partir de uma instantânea leva 2–5 segundos em vez de 30–60 segundos de uma inicialização completa.

Recomenda-se também armazenar o AVD num disco SSD — as operações de E/S durante o arranque do sistema e instalação de APK são significativamente mais rápidas. Para executar vários AVDs simultaneamente, aumente a quantidade total de RAM no computador e utilize o flag -read-only para emuladores imutáveis.

Gestão de AVD a partir da linha de comandos

O controlo total sobre os AVDs é possível a partir da linha de comandos sem o Android Studio. As ferramentas avdmanager e emulator fazem parte do Android SDK e realizam todas as operações: criar, eliminar, iniciar e configurar AVDs. A linha de comandos é especialmente útil em pipelines CI/CD, onde não há interface gráfica, e para automação de testes.

Comandos básicos de gestão de AVD

# Criar AVD com 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 ficheiros)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Restaurar dados do AVD
emulator -avd test_device -wipe-data

# Instalar APK no AVD em execução
adb -s emulator-5554 install app-release.apk

ADB e AVD: comandos chave

Após iniciar um AVD, pode-se trabalhar com ele através do ADB (Android Debug Bridge) tal como com um dispositivo físico. O ADB permite instalar aplicações, lançar intents, emular eventos (chamadas, SMS, GPS), tirar screenshots e gravar vídeo do ecrã. Isto torna o AVD um ambiente completo para testes automatizados.

# Listar dispositivos conectados (incluindo AVD)
adb devices

# Simular chamada recebida
adb emu gsm call +15551234567

# Simular coordenadas GPS
adb emu geo fix -122.084 37.422

# Tirar screenshot
adb exec-out screencap -p > screenshot.png

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

Verificação do emulador no código da aplicação

Por vezes, o desenvolvedor precisa de determinar no código se a aplicação está a ser executada num emulador ou num dispositivo físico. Isto pode ser necessário para desativar a analítica (para não poluir os dados de produção), ativar o registo alargado ou desativar funcionalidades dependentes de hardware que não funcionam no emulador. A Google fornece métodos padrão de verificação através da classe Build e das propriedades do sistema.

Método de verificação através de propriedades 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")
}

Verificação através de propriedades do sistema

Um método adicional é a leitura de propriedades do sistema através de Build.getRadioVersion() e a verificação de ro.kernel.qemu. No emulador, radio version retorna null e a propriedade qemu está definida como 1. Este método é mais fiável em versões antigas do Android onde Build.FINGERPRINT pode ser falsificado pelo fabricante do dispositivo.

fun isRunningOnEmulator(): Boolean {
    // Verificar através de radio version — no emulador sempre null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Verificar através de propriedades do sistema
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}