AVD Android: cos'è, Android Virtual Device e come configurare l'emulatore

Cos'è l'AVD

L'AVD (Android Virtual Device) è una configurazione software che descrive un dispositivo Android virtuale. A differenza di un telefono fisico, un AVD non richiede hardware — funziona su un computer tramite l'emulatore Android basato su QEMU. Uno sviluppatore crea tutti gli AVD necessari per i test: per diverse versioni di Android, dimensioni dello schermo, capacità di memoria e densità di pixel.

Ogni AVD è legato a una SDK Platform specifica. Ciò significa che per creare un AVD con Android 14 (API Level 34), è necessario prima installare la System Image di quella versione tramite SDK Manager. La System Image è un'immagine del sistema operativo che include tutte le applicazioni di sistema, i servizi Google (se viene selezionata l'immagine Google APIs) e i componenti runtime. Google raccomanda di utilizzare immagini Google APIs con i servizi Google Play per la massima compatibilità con i dispositivi reali.

L'AVD è indispensabile nello sviluppo per diversi motivi. Primo, consente di testare l'applicazione su diverse versioni di Android senza acquistare dozzine di dispositivi. Secondo, l'AVD supporta gli Snapshot — il salvataggio dello stato del sistema, che accelera l'avvio. Terzo, l'emulatore è integrato con Android Studio: l'installazione di APK, il debug e la registrazione funzionano come su un dispositivo fisico.

Tipi di dispositivi virtuali

L'AVD supporta vari tipi di dispositivi: telefoni, tablet, orologi Wear OS, Android TV e Android Automotive. Per ogni tipo, AVD Manager fornisce profili pronti all'uso di Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab e altri. Il profilo del dispositivo definisce la dimensione dello schermo, la risoluzione, la densità di pixel (dpi) e la navigazione (gesti o pulsanti).

Di cosa è composto un AVD

Ogni AVD è un insieme di file di configurazione e immagini. Il file di configurazione principale è config.ini, che memorizza i parametri del dispositivo virtuale: nome, tipo, API Level, dimensione dello schermo, RAM e dimensione dell'heap della VM. Il file si trova nella directory $HOME/.android/avd/NomeAVD.avd/ e può essere modificato manualmente, sebbene di solito venga modificato tramite AVD Manager.

Oltre a config.ini, la directory dell'AVD memorizza: userdata.img (immagine dei dati utente — applicazioni, impostazioni, file), system.img (collegamento alla System Image della SDK Platform installata), cache.img (cache) e sdcard.img (immagine della scheda SD). Quando si esegue Wipe Data, userdata.img viene eliminato e viene creata una nuova immagine vuota. Gli Snapshot vengono salvati in una cartella separata snapshots/ all'interno della directory dell'AVD.

La System Image viene scaricata separatamente dall'AVD — un'immagine può essere utilizzata da più dispositivi virtuali. Le immagini di sistema sono memorizzate nella directory Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Tipi di immagini: google_apis (con servizi Google), google_apis_playstore (con Google Play Store) e default (AOSP puro senza servizi Google).

Tipi di System Images

Creazione di un AVD tramite AVD Manager

AVD Manager è uno strumento grafico in Android Studio per creare e gestire dispositivi virtuali. Può essere aperto tramite il menu Tools → Device Manager o tramite l'icona della barra degli strumenti. AVD Manager mostra l'elenco dei dispositivi creati, il loro stato (in esecuzione/fermo), la versione di Android e le azioni disponibili (avvia, ferma, wipe data, modifica).

Per creare un nuovo AVD, fare clic sul pulsante Create device. Selezionare un profilo dispositivo dall'elenco predefinito — Google fornisce profili per tutti i dispositivi popolari. Dopo aver selezionato un profilo, specificare la System Image: la versione di Android e il tipo di immagine. Per i nuovi progetti, scegliere l'ultima versione stabile con l'immagine Google APIs. Quindi configurare il nome dell'AVD, l'orientamento dello schermo, la RAM e la dimensione dell'heap della VM. Dopo la creazione, l'AVD è pronto per essere avviato.

Creazione passo passo di un AVD dalla riga di comando

# 1. Elencare System Images disponibili
sdkmanager --list | grep system-images

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

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

# 4. Avviare l'AVD creato
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Elencare tutti gli AVD
avdmanager list avd

Configurazione delle caratteristiche hardware dell'AVD

AVD Manager consente una configurazione dettagliata delle caratteristiche hardware del dispositivo virtuale. Parametri principali: RAM (memoria ad accesso casuale, valore consigliato 2048–4096 MB), VM heap (dimensione dell'heap della macchina virtuale, 256–512 MB), archiviazione interna (2–8 GB) e scheda SD (scheda SD virtuale). Questi parametri influenzano le prestazioni dell'applicazione e il suo comportamento in condizioni di memoria insufficiente.

Le impostazioni aggiuntive includono: fotocamera (emulata o connessione webcam host), sensori (accelerometro, giroscopio), NFC, Bluetooth e batteria. Ad esempio, per testare applicazioni con rilevamento della posizione, è possibile emulare la rotazione del dispositivo tramite i pulsanti di controllo dell'emulatore o tramite ADB. L'emulazione dei sensori consente di testare scenari difficili da riprodurre su un dispositivo fisico.

Parametri chiave di config.ini

Ottimizzazione delle prestazioni dell'emulatore

La velocità dell'AVD dipende direttamente dalla virtualizzazione hardware. Su Windows viene utilizzato Windows Hypervisor Platform (WHPX), su macOS — Hypervisor.Framework, su Linux — KVM. Se la virtualizzazione è disabilitata, l'AVD funziona in modalità di emulazione puramente software, che è 10–20 volte più lenta. Per verificare se la virtualizzazione è abilitata, eseguire l'emulatore con il flag -accel-check.

Il secondo fattore chiave è la scelta dell'architettura della System Image. Le immagini x86_64 funzionano significativamente più velocemente di arm64-v8a su computer con processori Intel e AMD, poiché non richiedono la traduzione dinamica delle istruzioni ARM. Utilizzare sempre immagini x86_64 per lo sviluppo su Windows e macOS con processori Intel. Su processori ARM Mac (Apple Silicon), utilizzare immagini native arm64-v8a.

Flag della riga di comando per l'accelerazione

# Avviare con virtualizzazione hardware e accelerazione GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Verificare il supporto della virtualizzazione
emulator -accel-check

# Eseguire senza interfaccia grafica (per CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Usare snapshot per avvio rapido
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Suggerimenti per le prestazioni dell'emulatore

Per le massime prestazioni dell'AVD: allocare all'emulatore almeno 2–4 GB di RAM, abilitare GPU Host (utilizza la scheda grafica del computer per il rendering), disabilitare l'audio (flag -no-audio) se non necessario e utilizzare gli Snapshot per tornare rapidamente a uno stato pulito. Gli Snapshot salvano lo stato completo del sistema — l'avvio da uno snapshot richiede 2–5 secondi invece di 30–60 secondi per un avvio completo.

Si consiglia inoltre di archiviare l'AVD su un'unità SSD — le operazioni di I/O durante l'avvio del sistema e l'installazione di APK sono notevolmente più veloci. Per eseguire più AVD simultaneamente, aumentare la quantità totale di RAM sul computer e utilizzare il flag -read-only per gli emulatori immutabili.

Gestione degli AVD dalla riga di comando

Il controllo completo sugli AVD è possibile dalla riga di comando senza Android Studio. Gli strumenti avdmanager e emulator fanno parte di Android SDK e eseguono tutte le operazioni: creazione, eliminazione, avvio e configurazione degli AVD. La riga di comando è particolarmente utile nelle pipeline CI/CD, dove non è presente un'interfaccia grafica, e per l'automazione dei test.

Comandi di base per la gestione degli AVD

# Creare AVD con parametri personalizzati
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Eliminare AVD
avdmanager delete avd -n test_device

# Clonare AVD (copiando file)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Reimpostare dati AVD
emulator -avd test_device -wipe-data

# Installare APK su AVD in esecuzione
adb -s emulator-5554 install app-release.apk

ADB e AVD: comandi chiave

Dopo aver avviato un AVD, è possibile lavorarci tramite ADB (Android Debug Bridge) come con un dispositivo fisico. ADB consente di installare applicazioni, lanciare intent, emulare eventi (chiamate, SMS, GPS), fare screenshot e registrare video dello schermo. Questo rende l'AVD un ambiente completo per i test automatizzati.

# Elencare dispositivi connessi (incluso AVD)
adb devices

# Simulare chiamata in arrivo
adb emu gsm call +15551234567

# Simulare coordinate GPS
adb emu geo fix -122.084 37.422

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

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

Verifica dell'emulatore nel codice dell'applicazione

A volte lo sviluppatore deve determinare nel codice se l'applicazione è in esecuzione su un emulatore o su un dispositivo fisico. Ciò può essere necessario per disabilitare l'analisi (per non contaminare i dati di produzione), abilitare la registrazione estesa o disabilitare le funzioni dipendenti dall'hardware che non funzionano sull'emulatore. Google fornisce metodi standard di verifica attraverso la classe Build e le proprietà di sistema.

Metodo di verifica tramite proprietà 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")
    }
}

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

Verifica tramite proprietà di sistema

Un metodo aggiuntivo è la lettura delle proprietà di sistema tramite Build.getRadioVersion() e la verifica di ro.kernel.qemu. Sull'emulatore, radio version restituisce null e la proprietà qemu è impostata su 1. Questo metodo è più affidabile sulle versioni precedenti di Android dove Build.FINGERPRINT può essere falsificato dal produttore del dispositivo.

fun isRunningOnEmulator(): Boolean {
    // Verifica tramite radio version — su emulatore sempre null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Verifica tramite proprietà di sistema
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}