AVD Android : qu'est-ce que c'est, Android Virtual Device et comment configurer l'émulateur

Qu'est-ce que l'AVD

L'AVD (Android Virtual Device) est une configuration logicielle qui décrit un appareil Android virtuel. Contrairement à un téléphone physique, un AVD ne nécessite pas de matériel — il fonctionne sur un ordinateur via l'émulateur Android basé sur QEMU. Un développeur crée autant d'AVD que nécessaire pour les tests : pour différentes versions d'Android, tailles d'écran, capacités mémoire et densités de pixels.

Chaque AVD est lié à une SDK Platform spécifique. Cela signifie que pour créer un AVD avec Android 14 (API Level 34), vous devez d'abord installer la System Image de cette version via le SDK Manager. La System Image est une image du système d'exploitation qui inclut toutes les applications système, les services Google (si l'image Google APIs est sélectionnée) et les composants d'exécution. Google recommande d'utiliser les images Google APIs avec les services Google Play pour une compatibilité maximale avec les appareils réels.

L'AVD est indispensable au développement pour plusieurs raisons. Premièrement, il permet de tester l'application sur différentes versions d'Android sans acheter des dizaines d'appareils. Deuxièmement, l'AVD prend en charge les Snapshots — la sauvegarde de l'état du système, ce qui accélère le démarrage. Troisièmement, l'émulateur est intégré à Android Studio : l'installation d'APK, le débogage et la journalisation fonctionnent comme sur un appareil physique.

Types d'appareils virtuels

L'AVD prend en charge différents types d'appareils : téléphones, tablettes, montres Wear OS, Android TV et Android Automotive. Pour chaque type, l'AVD Manager fournit des profils prêts à l'emploi de Google : Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab et autres. Le profil de l'appareil définit la taille de l'écran, la résolution, la densité de pixels (dpi) et la navigation (gestes ou boutons).

De quoi est composé un AVD

Chaque AVD est un ensemble de fichiers de configuration et d'images. Le fichier de configuration principal est config.ini, qui stocke les paramètres de l'appareil virtuel : nom, type, niveau d'API, taille d'écran, RAM et taille du heap de la VM. Le fichier se trouve dans le répertoire $HOME/.android/avd/NomAVD.avd/ et peut être modifié manuellement, bien qu'il soit généralement édité via l'AVD Manager.

En plus de config.ini, le répertoire de l'AVD stocke : userdata.img (image des données utilisateur — applications, paramètres, fichiers), system.img (lien vers la System Image de la SDK Platform installée), cache.img (cache) et sdcard.img (image de carte SD). Lors de l'exécution de Wipe Data, userdata.img est supprimé et une nouvelle image vide est créée. Les Snapshots sont sauvegardés dans un dossier séparé snapshots/ à l'intérieur du répertoire de l'AVD.

La System Image est téléchargée séparément de l'AVD — une image peut être utilisée par plusieurs appareils virtuels. Les images système sont stockées dans le répertoire Android SDK : $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Types d'images : google_apis (avec services Google), google_apis_playstore (avec Google Play Store) et default (AOSP pur sans services Google).

Types de System Images

Création d'un AVD via l'AVD Manager

L'AVD Manager est un outil graphique dans Android Studio pour créer et gérer les appareils virtuels. On peut l'ouvrir via le menu Tools → Device Manager ou via l'icône de la barre d'outils. L'AVD Manager affiche la liste des appareils créés, leur statut (en cours d'exécution/arrêté), la version d'Android et les actions disponibles (démarrer, arrêter, effacer les données, modifier).

Pour créer un nouvel AVD, cliquez sur le bouton Create device. Sélectionnez un profil d'appareil dans la liste prête à l'emploi — Google fournit des profils pour tous les appareils populaires. Après avoir sélectionné un profil, spécifiez la System Image : la version d'Android et le type d'image. Pour les nouveaux projets, choisissez la dernière version stable avec l'image Google APIs. Ensuite, configurez le nom de l'AVD, l'orientation de l'écran, la RAM et la taille du heap de la VM. Après la création, l'AVD est prêt à être lancé.

Création pas à pas d'un AVD en ligne de commande

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

# 2. Installer System Image pour API 35 avec Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. Créer un AVD nommé pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Lancer l'AVD créé
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Lister tous les AVD
avdmanager list avd

Configuration des caractéristiques matérielles de l'AVD

L'AVD Manager permet une configuration détaillée des caractéristiques matérielles de l'appareil virtuel. Paramètres principaux : RAM (mémoire vive, valeur recommandée 2048–4096 Mo), VM heap (taille du heap de la machine virtuelle, 256–512 Mo), stockage interne (2–8 Go) et carte SD (carte SD virtuelle). Ces paramètres affectent les performances de l'application et son comportement en cas de mémoire insuffisante.

Les paramètres supplémentaires incluent : caméra (émulée ou connexion webcam hôte), capteurs (accéléromètre, gyroscope), NFC, Bluetooth et batterie. Par exemple, pour tester des applications avec détection de position, on peut émuler la rotation de l'appareil via les boutons de contrôle de l'émulateur ou via ADB. L'émulation de capteurs permet de tester des scénarios difficiles à reproduire sur un appareil physique.

Paramètres clés de config.ini

Optimisation des performances de l'émulateur

La vitesse de l'AVD dépend directement de la virtualisation matérielle. Sous Windows, on utilise Windows Hypervisor Platform (WHPX), sous macOS — Hypervisor.Framework, sous Linux — KVM. Si la virtualisation est désactivée, l'AVD fonctionne en mode d'émulation purement logicielle, ce qui est 10 à 20 fois plus lent. Pour vérifier si la virtualisation est activée, exécutez l'émulateur avec le flag -accel-check.

Le deuxième facteur clé est le choix de l'architecture de la System Image. Les images x86_64 fonctionnent beaucoup plus rapidement que arm64-v8a sur les ordinateurs avec processeurs Intel et AMD, car elles ne nécessitent pas de traduction dynamique des instructions ARM. Utilisez toujours des images x86_64 pour le développement sous Windows et macOS avec des processeurs Intel. Sur les processeurs ARM Mac (Apple Silicon), utilisez des images natives arm64-v8a.

Flags de ligne de commande pour l'accélération

# Lancer avec virtualisation matérielle et accélération GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Vérifier le support de la virtualisation
emulator -accel-check

# Exécuter sans interface graphique (pour CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Utiliser les snapshots pour un démarrage rapide
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Conseils de performance de l'émulateur

Pour des performances maximales de l'AVD : allouez au moins 2–4 Go de RAM à l'émulateur, activez GPU Host (utilise la carte graphique de l'ordinateur pour le rendu), désactivez le son (flag -no-audio) si nécessaire, et utilisez les Snapshots pour revenir rapidement à un état propre. Les Snapshots sauvegardent l'état complet du système — le démarrage à partir d'un snapshot prend 2–5 secondes au lieu de 30–60 secondes pour un démarrage complet.

Il est également recommandé de stocker l'AVD sur un disque SSD — les opérations d'E/S lors du démarrage du système et de l'installation d'APK sont considérablement accélérées. Pour exécuter plusieurs AVD simultanément, augmentez la quantité totale de RAM sur l'ordinateur et utilisez le flag -read-only pour les émulateurs immuables.

Gestion des AVD en ligne de commande

Le contrôle total des AVD est possible en ligne de commande sans Android Studio. Les outils avdmanager et emulator font partie du SDK Android et effectuent toutes les opérations : création, suppression, lancement et configuration des AVD. La ligne de commande est particulièrement utile dans les pipelines CI/CD, où il n'y a pas d'interface graphique, et pour l'automatisation des tests.

Commandes de base de gestion des AVD

# Créer un AVD avec des paramètres personnalisés
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Supprimer un AVD
avdmanager delete avd -n test_device

# Cloner un AVD (en copiant les fichiers)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Réinitialiser les données de l'AVD
emulator -avd test_device -wipe-data

# Installer un APK sur un AVD en cours d'exécution
adb -s emulator-5554 install app-release.apk

ADB et AVD : commandes clés

Après avoir lancé un AVD, on peut travailler avec via ADB (Android Debug Bridge) comme avec un appareil physique. ADB permet d'installer des applications, de lancer des intents, d'émuler des événements (appels, SMS, GPS), de prendre des captures d'écran et d'enregistrer la vidéo de l'écran. Cela fait de l'AVD un environnement complet pour les tests automatisés.

# Lister les appareils connectés (y compris AVD)
adb devices

# Simuler un appel entrant
adb emu gsm call +15551234567

# Simuler des coordonnées GPS
adb emu geo fix -122.084 37.422

# Prendre une capture d'écran
adb exec-out screencap -p > screenshot.png

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

Vérification de l'émulateur dans le code de l'application

Parfois, le développeur doit déterminer dans le code si l'application s'exécute sur un émulateur ou sur un appareil physique. Cela peut être nécessaire pour désactiver l'analytique (pour ne pas polluer les données de production), activer la journalisation étendue ou désactiver les fonctions dépendantes du matériel qui ne fonctionnent pas sur l'émulateur. Google fournit des méthodes standard de vérification via la classe Build et les propriétés système.

Méthode de vérification via les propriétés 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")
    }
}

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

Vérification via les propriétés système

Une méthode supplémentaire consiste à lire les propriétés système via Build.getRadioVersion() et à vérifier ro.kernel.qemu. Sur l'émulateur, radio version renvoie null et la propriété qemu est définie sur 1. Cette méthode est plus fiable sur les anciennes versions d'Android où Build.FINGERPRINT peut être falsifié par le fabricant de l'appareil.

fun isRunningOnEmulator(): Boolean {
    // Vérification via radio version — sur émulateur toujours null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Vérification via les propriétés système
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}