Configurer le sous système Windows pour Android

Ce guide s'adresse à qui doit faire tourner des applications Android sur une machine Windows 11 sans passer par un émulateur tiers. On part du principe que tu as déjà installé WSA depuis le Microsoft Store ou via le paquet MSIX sideloadé, et qu'il démarre — même mal.

Ce qu'il te faut avant de commencer

• Windows 11 22H2 (build 22621) ou plus récent. WSA ne fonctionne pas sur Windows 10, quelle que soit la version.
• Virtualisation matérielle activée dans le BIOS/UEFI (Intel VT-x ou AMD-V). Sans ça, rien ne démarre.
• La fonctionnalité « Plateforme d'ordinateur virtuel » activée dans Windows.
• Un compte administrateur local. La plupart des commandes ci-dessous passent par PowerShell en élévation.
• Le paquet WSA installé. Si tu l'as sideloadé, garde le `.msixbundle` sous la main : on va en avoir besoin pour réinstaller proprement.

Vérifie d'abord que la virtualisation est bien vue par le système :

```powershell Get-ComputerInfo -Property "HyperVRequirementVirtualizationFirmwareEnabled","HyperVisorPresent" ```

Les deux doivent renvoyer `True`. Si `HyperVRequirementVirtualizationFirmwareEnabled` est à `False`, tu perds ton temps à configurer WSA : il faut redémarrer dans le BIOS et activer VT-x ou SVM selon le fabricant du processeur.

Étape 1 — Activer les fonctionnalités Windows requises

WSA a besoin de deux fonctionnalités : `VirtualMachinePlatform` et `HypervisorPlatform`. La première fournit la couche d'abstraction, la seconde expose l'API Hyper-V aux applications tierces. Sans la seconde, WSA démarre mais reste bloqué sur l'écran de chargement.

```powershell Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All -NoRestart ```

Le `-NoRestart` est volontaire : on enchaîne d'autres commandes avant de redémarrer une seule fois. Un redémarrage par fonctionnalité, c'est trois quarts d'heure perdus pour rien.

Étape 2 — Vérifier que le service WSA est en démarrage automatique

Le service `WsaService` doit se lancer avec Windows. S'il est en manuel, WSA démarre à la première ouverture d'une appli Android, ce qui ajoute dix à quinze secondes de latence à chaque lancement à froid.

```powershell Set-Service -Name "WsaService" -StartupType Automatic Start-Service -Name "WsaService" Get-Service -Name "WsaService" | Select-Object Name, Status, StartType ```

Le `StartType` doit afficher `Automatic` et le `Status` `Running`. Si le service refuse de démarrer, c'est presque toujours un conflit avec un antivirus tiers qui bloque le chargement de la DLL de virtualisation. Dans ce cas, ajoute le dossier `C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForAndroid_*` aux exclusions.

Étape 3 — Ajuster la mémoire allouée au sous-système

Par défaut, WSA réclame 2 Go de RAM et peut monter jusqu'à la moitié de la mémoire physique. Sur une machine à 16 Go, ça laisse 8 Go pour Android — largement suffisant pour la plupart des applis, insuffisant pour un jeu 3D.

Le fichier de configuration se trouve dans le profil utilisateur :

```powershell notepad "$env:LOCALAPPDATA\Packages\MicrosoftCorporationII.WindowsSubsystemForAndroid_8wekyb3d8bbwe\LocalState\settings.json" ```

Cherche la clé `memoryMB`. Mets-la à `4096` pour un usage bureautique, `8192` si tu lances des jeux. Ne dépasse pas la moitié de ta RAM physique : au-delà, Windows commence à swapper et WSA devient plus lent qu'un émulateur classique.

Tu peux aussi fixer le nombre de cœurs alloués via `processorCount`. Quatre cœurs est un bon compromis. En mettre plus ne sert à rien si l'appli Android n'est pas multithreadée — et la plupart ne le sont pas.

Étape 4 — Activer le mode développeur et le débogage ADB

Le mode développeur ouvre le port 58526 en local pour `adb`. Sans lui, tu ne peux pas installer d'APK en dehors du Amazon Appstore, ni lire les logs.

```powershell $wsa = Get-AppxPackage -Name "MicrosoftCorporationII.WindowsSubsystemForAndroid" if ($wsa) { Start-Process "wsa://settings" } ```

Dans la fenêtre qui s'ouvre, va dans System → Developer et active Developer mode. Note l'adresse IP affichée : c'est `127.0.0.1:58526` sur la plupart des installations.

Connecte-toi ensuite avec `adb` (fourni par les platform-tools Android) :

```bash adb connect 127.0.0.1:58526 adb devices ```

La sortie doit lister `127.0.0.1:58526 device`. Si tu vois `offline`, c'est que le mode développeur n'a pas encore fini de s'initialiser — attends trente secondes et relance `adb connect`.

Étape 5 — Installer un APK en ligne de commande

C'est la raison principale pour laquelle on active ADB. Le sideload via l'Explorateur Windows ne fonctionne que pour les paquets signés avec un certificat reconnu par WSA, ce qui exclut la majorité des APK qu'on veut tester.

```bash adb install -r -g /chemin/vers/appli.apk ```

`-r` réinstalle en gardant les données. `-g` accorde toutes les permissions runtime d'un coup — pratique en test, à ne pas faire en production.

Pour un bundle d'APK (format `.apks` ou `.xapk`), il faut passer par `bundletool` :

```bash java -jar bundletool.jar build-apks --bundle=appli.aab --output=appli.apks --mode=universal unzip appli.apks -d appli_extracted adb install -r -g appli_extracted/universal.apk ```

Étape 6 — Rediriger les dossiers partagés

WSA expose par défaut le dossier `C:\Users\\` sous `/sdcard/Windows` dans Android. Pratique, mais ça donne à chaque appli Android un accès en lecture à ton profil Windows entier.

Pour restreindre, ouvre `wsa://settings`, va dans System → Files et désactive Share user folders. Tu peux ensuite monter un dossier précis via `wsa://` avec un chemin restreint.

L'alternative est de pousser les fichiers via ADB quand tu en as besoin :

```bash adb push ./fichier.pdf /sdcard/Download/ adb shell ls -la /sdcard/Download/ ```

C'est plus lent, mais l'appli Android ne voit que ce que tu lui envoies explicitement.

Étape 7 — Vérifier la configuration réseau

WSA utilise un NAT interne. Les applis Android ne voient pas ton réseau local directement, sauf si tu actives le mode bridge.

```powershell Get-NetAdapter | Where-Object {$_.Name -like "WSA"} | Select-Object Name, Status, MacAddress ```

Si l'adaptateur n'apparaît pas, c'est que le service réseau de WSA ne s'est pas attaché. Redémarre le service :

```powershell Restart-Service -Name "WsaService" -Force ```

Pour accéder à un serveur sur ton LAN depuis Android, il faut passer par l'IP de la machine hôte, pas par `localhost`. Android tourne dans une VM, `localhost` pointe vers la VM elle-même.

Vérification finale

Lance une appli Android, puis depuis PowerShell :

```powershell Get-Process -Name "WsaClient" | Select-Object Name, Id, WorkingSet64, CPU adb shell getprop ro.build.version.release ```

La première commande doit montrer un processus actif avec une empreinte mémoire cohérente (au moins 1,5 Go). La seconde doit renvoyer la version Android, typiquement `13` sur les builds WSA récents. Si `adb shell` répond mais que l'appli plante, le problème est dans l'appli, pas dans WSA.

Problèmes courants

WSA démarre puis se ferme immédiatement. Vérifie que `HypervisorPlatform` est bien activé — c'est la fonctionnalité qu'on oublie le plus souvent. `Get-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform` doit renvoyer `Enabled`.

`adb connect` refuse la connexion. Le mode développeur s'est désactivé après une mise à jour de WSA. Repasse par `wsa://settings` et réactive-le. Le port change parfois après une mise à jour majeure : relis l'adresse affichée.

Les applis ne voient pas les fichiers poussés via `adb push`. Le média scanner d'Android n'a pas encore indexé le fichier. Force-le :

```bash adb shell am broadcast -a android.intent.action.MEDIA_SCANNER_SCAN_FILE -d file:///sdcard/Download/fichier.pdf ```

WSA reste un sous-système en développement actif. Les builds changent tous les deux à trois mois, et certaines clés de `settings.json` disparaissent sans préavis. Garde une copie du fichier avant chaque mise à jour — la restaurer est plus rapide que de retrouver les bons paramètres à tâtons.