260826-Secure Virtual Machine et Emulateur Android
Mise en place d'un émulateur Android sur le poste julie pour faire tourner des applications de presse (The Guardian, Le Monde) et d'autres APK. Séance du 2026-08-26.
Trois obstacles se sont enchaînés, chacun avec un diagnostic trompeur : la virtualisation matérielle absente, un pilote d'accélération dont l'installation échoue en silence, et un faux écran noir. Cette page retient surtout les pièges, parce que chacun a coûté plusieurs allers-retours.
Contexte et matériel
julie — MSI A320M-A PRO (MS-7C51), BIOS E7C51AMS.140 du 12/08/2020
CPU
AMD Ryzen 5 2600X, 6 cœurs / 12 threads
RAM
16 Go
GPU
Radeon RX 6500 XT, pilote du 18/01/2022 (voir page 249)
Écran
dalle 4K 3840x2160, bureau logique 2560x1440 (mise à l'échelle 150 %)
OS
Windows 10 19045, firmware UEFI, démarrage rapide actif
1. Activer la virtualisation (SVM)
Le symptôme
systeminfo répondait Virtualisation activée dans le microprogramme : Non, alors que le CPU est parfaitement capable de SVM. Sans virtualisation, aucun émulateur Android ne fonctionne — BlueStacks, LDPlayer, MEmu, Nox, Genymotion et l'AVD d'Android Studio sont tous des machines virtuelles x86. Changer d'émulateur ne contourne pas le problème.
Vérification préalable qu'aucune cause logicielle n'était en jeu :
Get-CimInstance Win32_ComputerSystem | Select-Object HypervisorPresent # False
(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
-ClassName Win32_DeviceGuard).VirtualizationBasedSecurityStatus # 0
Aucun hyperviseur actif, pas de VBS : ni Hyper-V ni l'isolation du noyau ne confisquaient la virtualisation. La cause était donc bien dans le firmware.
Le chemin dans le BIOS
Ce poste a l'ancienne interface MSI Click BIOS à onglets horizontaux, pas la version récente à tuiles. Donc ni EZ Mode, ni touche F7, ni OC Explore Mode à chercher — toutes indications que l'on trouve partout en ligne et qui ne s'appliquent pas ici.
Touche d'entrée dans le BIOS sur cette machine : F11. Plus fiable, le démarrage rapide étant actif : Paramètres → Mise à jour et sécurité → Récupération → Démarrage avancé → Redémarrer maintenant → Dépannage → Options avancées → Changer les paramètres du microprogramme UEFI.
Chemin réel du réglage :
Overclocking → (section Other Setting, tout en bas) → Caractéristique du CPU → SVM Mode
Caractéristique du CPU est la traduction française de CPU Features.
Piège n°1 — deux sous-menus qui se ressemblent
La section Other Setting du menu Overclocking contient trois entrées :
CPU Specifications -> INFORMATIONS, lecture seule
MÉMOIRE-Z -> informations RAM
Caractéristique du CPU -> LES RÉGLAGES
CPU Specifications → CPU Technology Support affiche une fiche technique :
Secure Virtual Machine YES
Ce « YES » ne signifie pas que SVM est activé — seulement que le processeur en est capable. C'est une page de consultation.
Règle pour distinguer d'un coup d'œil : dans ce BIOS, un réglage modifiable est toujours entre crochets (A-XMP [Désactivé], NX Mode [Activé], SVM Mode [Activé]). Une valeur en texte nu (YES, N/A, 3.60GHz) est informative.
Piège n°2 — la vraie cause : il faut couper le secteur
Contenu réel de Overclocking\Caractéristique du CPU :
Simultaneous Multi-Threading [AUTO]
Global C-state Control [AUTO]
Opcache Control [AUTO]
IOMMU [AUTO]
Spread Spectrum [AUTO]
Relaxed EDC throttling [AUTO]
AMD Cool'n'Quiet [Activé]
NX Mode [Activé]
SVM Mode [Activé] <-- déjà correct
Power Supply Idle Control [AUTO]
Le réglage était déjà bon, et Windows répondait pourtant Non.
Ce qui a débloqué : le débranchement de la prise pendant 10 secondes. Après quoi :
Virtualisation activée dans le microprogramme : Oui
VirtualizationFirmwareEnabled : True
Sur cette carte, un
SVM Modecorrectement réglé peut rester invisible du système tant qu'il n'y a pas eu de vraie coupure secteur. Un redémarrage, et même un arrêt Windows normal, ne suffisent pas — le démarrage rapide maintient un état résiduel. Débrancher d'abord, diagnostiquer ensuite.
Ne pas toucher aux autres lignes, en particulier laisser IOMMU et Simultaneous Multi-Threading sur [AUTO].
Fiche pas-à-pas réutilisable : Jux-scripts/PC-Health/bios_svm_a320m.md.
2. Android Studio
winget install -e --id Google.AndroidStudio --accept-package-agreements --accept-source-agreements
Version installée : 2026.1.3.7, 3,29 Go dans C:\Program Files\Android\Android Studio.
Installation en mode Custom pour accéder aux composants. Composants retenus :
adb
Android SDK Command-line Tools
23.0.0
avdmanager, diagnostics
Android Emulator hypervisor driver
2.2.0
accélération AMD — voir section suivante
Symptôme si le pilote manque : l'assistant marque Android Virtual Device comme indisponible, et n'installe ni l'émulateur ni les platform-tools. Ce n'est pas un échec du BIOS — il manque juste la couche d'accélération.
Note : sdkmanager est déprécié et son remplaçant android est encore incomplet (android sdk list ne liste que l'installé). Passer par l'interface pour tout ce qui touche aux images système.
3. Le pilote AEHD — installation manuelle
Pourquoi ce pilote
Sur un CPU AMD sous Windows, l'émulateur a besoin de l'un des deux mécanismes suivants :
Piège n°3 — le SDK Manager échoue et efface ses traces
Sortie observée :
Installing Android Emulator hypervisor driver (installer) in ...\extras\google\Android_Emulator_Hypervisor_Driver
"Install Android Emulator hypervisor driver (installer) v.2.2.0" complete.
Failed to update status to COMPLETE
"Install Android Emulator hypervisor driver (installer) v.2.2.0" failed.
Le paquet se télécharge et s'extrait, puis l'étape d'installation du pilote échoue faute d'élévation, et le gestionnaire annule l'extraction : extras\google se retrouve vide. Il ne reste donc rien à réparer sur place — il faut repartir du paquet d'origine.
La réparation
New-Item -ItemType Directory -Force 'D:\temp_aehd' | Out-Null
Invoke-WebRequest -Uri 'https://dl.google.com/android/repository/aehd-windows_v2.2.zip' `
-OutFile 'D:\temp_aehd\aehd.zip'
Expand-Archive 'D:\temp_aehd\aehd.zip' -DestinationPath 'D:\temp_aehd\x' -Force
Start-Process -FilePath 'cmd.exe' -Verb RunAs -Wait -ArgumentList `
'/c','"cd /d D:\temp_aehd\x && silent_install.bat > D:\temp_aehd\out.txt 2>&1"'
Piège MSIX — utiliser
D:et non le dossier temporaire habituel. Claude Code tourne dans un conteneur MSIX : ce qu'il écrit sous%LOCALAPPDATA%atterrit en réalité dans…\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\. Un installeur lancé en élevé sort du conteneur et ne verrait pas ces fichiers. Même famille de piège que le home Syncthing (voir la section « Poste Windows julie » duCLAUDE.md).
Contenu du paquet : aehd.Sys (403 Ko), aehd.cat, aehd.Inf, silent_install.bat. Le script installe via RUNDLL32 SETUPAPI.DLL,InstallHinfSection puis lance le service. Désinstallation : silent_install.bat -u.
Résultat :
SERVICE_NAME: aehd
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
Vérification
& 'C:\Users\julie\AppData\Local\Android\Sdk\emulator\emulator.exe' -accel-check
Attendu : AEHD (version 2.2) is installed and usable. et code de retour 0.
4. L'AVD
Choix retenus
Profil Pixel Tablet en paysage : l'écran du PC est large, et Guardian comme Le Monde ont de vraies mises en page tablette (multi-colonnes). Un profil téléphone donnerait une colonne étroite au milieu d'un grand écran.
Ce qui déclenche la mise en page tablette, c'est la largeur en dp, pas en pixels : 1600 / (320/160) = 800 dp, au-delà du seuil de 600 dp.
Si aucun profil tablette ne porte l'icône Play Store, ne pas se rabattre sur un téléphone : prendre un profil téléphone avec Play Store, puis régler dans Edit une résolution de 1920x1200 en 240 dpi (soit 800 dp). On garde le Play Store et la mise en page large.
Image système
system-images\android-35\google_apis_playstore_tablet\x86_64
Android 15, API 35
La variante « Google Play » est indispensable pour installer les applications depuis le Store. C'est une build de production : adb root y est impossible, mais adb install fonctionne normalement.
Traduction ARM confirmée — point décisif pour les APK récupérés ailleurs :
ro.product.cpu.abilist = x86_64,arm64-v8a
Les images x86_64 en API 30 et plus traduisent l'ARM 64 bits à la volée. Sans cela, un APK ARM échoue sur INSTALL_FAILED_NO_MATCHING_ABIS.
Piège n°4 — les réglages avancés ne s'appliquent pas à la création
Valeurs demandées dans l'assistant, valeurs réellement écrites :
hw.ramSize
4096
2048
6144
vm.heapSize
—
192
512
disk.dataPartition.size
16 Go
10 Go
10 Go (suffisant)
hw.cpu.ncore
4
4
4
Plus simple que de rechercher le Device Manager dans l'interface : éditer directement, émulateur arrêté (il réécrit son fichier en quittant).
C:\Users\julie\.android\avd\Pixel_Tablet.avd\config.ini
hw.ramSize=6144
vm.heapSize=512
hw.cpu.ncore=4
disk.dataPartition.size=10G
hw.gpu.mode=auto
vm.heapSize est le réglage sous-estimé : c'est le plafond mémoire par application, distinct de la RAM totale. À 192 Mo, une application de presse chargeant beaucoup d'images se fait tuer sans message. C'était le vrai goulet d'étranglement, davantage que les 2 Go de RAM.
Sauvegarde : config.ini.bak-260826. Vérification côté invité : MemTotal: 6072156 kB — l'écart avec 6144 Mo est la part réservée par le noyau, c'est normal.
Augmenter le stockage après coup impose un effacement des données. C'est le seul réglage à ne pas rater à la création.
5. Piège n°5 — le faux écran noir
Le symptôme
Après quelques minutes, écran entièrement noir. La capture prise depuis l'intérieur d'Android était noire elle aussi — ce qui semblait exclure un simple problème de fenêtre Windows et accusait la pile graphique, d'autant que le journal de l'émulateur contenait :
UpdateLayeredWindowIndirect failed ... (Un périphérique attaché au système ne fonctionne pas correctement)
avec un pilote AMD de janvier 2022 comme suspect tout désigné.
La vraie cause
mWakefulness=Dozing
L'écran s'était simplement mis en veille, comme sur une vraie tablette. Et le volet de notifications était resté déployé par-dessus (mCurrentFocus=NotificationShade), ce qui gardait l'affichage noir même après réveil.
Aucune erreur graphique dans logcat. Le pilote AMD était hors de cause.
Méthode de diagnostic, dans cet ordre
$adb = 'C:\Users\julie\AppData\Local\Android\Sdk\platform-tools\adb.exe'
& $adb devices # le système répond-il ?
& $adb shell getprop sys.boot_completed # 1 = démarrage fini
& $adb shell dumpsys power | Select-String mWakefulness # Dozing / Asleep / Awake
& $adb shell dumpsys window | Select-String mCurrentFocus # quelle fenêtre au premier plan
Dozing ou Asleep → simple veille, réveiller
Awake et écran noir → là seulement, suspecter le rendu graphique
Réveil et retour à l'accueil :
& $adb shell input keyevent 224 # KEYCODE_WAKEUP
& $adb shell input keyevent 4 # BACK, referme le volet de notifications
& $adb shell input keyevent 3 # HOME
Indice utile : le poids de la capture d'écran. 23 Ko = écran noir, ~3 Mo = interface réellement dessinée.
& $adb shell screencap -p /sdcard/s.png; & $adb pull /sdcard/s.png D:\s.png
Le correctif
& $adb shell settings put global stay_on_while_plugged_in 7
& $adb shell settings put system screen_off_timeout 1800000
stay_on_while_plugged_in = 7 couvre secteur + USB + sans-fil. L'émulateur se déclarant toujours « en charge », l'écran ne s'éteint plus jamais. Le réglage persiste au redémarrage (il vit sur la partition de données).
Aide-mémoire
Chemins
Android Studio C:\Program Files\Android\Android Studio
SDK C:\Users\julie\AppData\Local\Android\Sdk
adb ...\Sdk\platform-tools\adb.exe
emulator ...\Sdk\emulator\emulator.exe
AVD C:\Users\julie\.android\avd\Pixel_Tablet.avd
Raccourci C:\Users\julie\Desktop\Tablette Android.lnk
Commandes
# Démarrer (le raccourci du bureau fait la même chose)
& '...\Sdk\emulator\emulator.exe' -avd Pixel_Tablet
# Démarrage propre, si un boot se passe mal
& '...\Sdk\emulator\emulator.exe' -avd Pixel_Tablet -no-snapshot-load
# Lister les AVD / arrêter proprement
& '...\Sdk\emulator\emulator.exe' -list-avds
& '...\adb.exe' -s emulator-5554 emu kill
# Installer un APK (ou glisser-déposer le fichier sur la fenêtre)
& '...\adb.exe' install monapp.apk
& '...\adb.exe' install-multiple base.apk split_config.arm64_v8a.apk split_config.xxhdpi.apk
Les dépôts type APKMirror servent souvent des .xapk / .apkm : ce sont des archives ZIP de plusieurs APK. adb install échoue dessus, il faut les décompresser et utiliser install-multiple.
Premier démarrage : 2 à 3 minutes, sans aucune fenêtre visible pendant une bonne partie du temps. Ne pas conclure trop vite que le raccourci ne marche pas — vérifier le processus :
Get-Process emulator,qemu-system-x86_64 -ErrorAction SilentlyContinue
Les démarrages suivants réutilisent l'instantané, environ 20 secondes.
Limites connues
Presse, lecture, productivité et utilitaires : sans problème.
Voies écartées
/dev/kvm, kvm_intel.nested=Y) — mais 2,7 Gio de RAM disponibles seulement, swap déjà à moitié plein, aucun GPU, et usage interactif à travers le réseau. Redroid exigerait en plus un changement de noyau : le noyau cloud n'a pas CONFIG_ANDROID_BINDER_IPC
BlueStacks / LDPlayer / MEmu / Nox
Mêmes prérequis de virtualisation, plus publicité et télémétrie
Genymotion
Dépend de VirtualBox, déjà impliqué dans le dossier écrans bleus (page 249)
Waydroid sur l'Ubuntu 25.10
Reste une bonne solution de repli : conteneur LXC, aucun besoin de VT-x/AMD-V. Aurait été retenu si SVM était resté inaccessible
scrcpy + tablette existante
Écarté ici, mais pertinent : recopie l'écran d'une Lenovo Tab K11 ou d'une SM-T720 sur le PC, sans virtualisation ni émulateur
Points restés ouverts
UpdateLayeredWindowIndirect du journal de l'émulateur en sont un symptôme de plus, même si elles n'ont pas empêché le fonctionnement.
Le Virtual Device Manager n'apparaissait pas dans More Actions de l'écran d'accueil d'Android Studio. Contourné en éditant config.ini directement. Depuis un projet ouvert, il est accessible par Tools → Device Manager.
Voir aussi
julie, écrans bleus, pilote AMD
Jux-scripts/PC-Health/bios_svm_a320m.md — fiche BIOS pas à pas
CLAUDE.md, section « Poste Windows julie » — piège MSIX, outillage du poste