[new:30/06/2014]L’émulateur Android rapide de Intel (HAXM) accélère grandement les tests et le débogue des applications Xamarin, mais HAXM ne s’installe pas quand Hyper-V est activé et ce dernier l’est forcément pour déboguer des applications Windows Phone 8.x ! Une solution, le multiboot…
Des émulateurs qui ne s’aiment pas
Le mieux disons le tout de suite cela serait que HAXM fonctionne avec Hyper-V, le problème c’est que lorsque ce dernier est lancé (au démarrage de l’OS donc impossible à couper ou remettre à tout moment) il brouille l’écoute – contrepèterie justifiée – et empêche HAXM de détecter le mode de virtualisation VT-x des processeurs Intel. Or, VT-x est obligatoire pour HAXM, normal c’est un support de virtualisation et HAXM est un accélérateur d’émulateur Android.
On pourrait se dire que HAXM est bogué. Ca serait bizarre qu’un logiciel Intel ne fonctionne pas avec un processeur Intel mais parfois… Si on utilise d’autres logiciels Intel comme ProcID qui permet de détecter le processeur, sa vitesse, son type et toutes ses caractéristiques le même problème se révèle : le support de VT-x est rapporté comme inexistant sur le processeur même si bien entendu il s’agit d’un processeur possédant le support de VT-x.
Il y a donc peu de chance que cela vienne de HAXM et de tous les utilitaires Intel. C’est donc Hyper-V qui joue les troubles fête.
Une solution raisonnable mais pas très pratique
Comme je le disais plus haut, Hyper-V est obligatoire pour déboguer des applications Windows Phone 8.x.
Si vous ne développez jamais d’applications de ce type, alors désinstaller Hyper-V ! C’est simple mais pas forcément sans conséquence… Assurez-vous que cela n’empêchera pas d’autres logiciels installés sur votre machine de fonctionner.
En revanche si vous êtes comme moi et que vous développez des applications cross-plateformes, alors il devient indispensable de trouver une solution. Quand on travaille sur une application Android au sein d’un projet important il n’est pas normal d’avoir un émulateur qui se traine et qui fait perdre du temps. Pas plus qu’il puisse être envisageable de désinstaller Hyper-V et de rendre le travail sur Windows Phone impossible… Cornélien ? oui. Sans le côté dramatique (n’exagérons rien) c’est un peu le Choix de Sophie.
Seulement voilà, des solutions je n’en ai pas trouvées… En tout cas pas de valables qui résoudraient vraiment le problème. Seul Microsoft en corrigeant Hyper-V ou en le modifiant pourrait apporter une vraie solution. Les bidouilles ne passent pas.
Alors, puisqu’il faut bien trouver un moyen de travailler, je vous propose une solution à deux eurocents qui a l’avantage d’être techniquement simple. Mais elle n’est pas parfaite et, forcément, apporte son lot de contraintes.
L’idée de base consiste à se dire que puisque Hyper-V démarre avec l’OS il suffit d’avoir un double (ou triple ou quadruple peu importe) boot qui reproduise le boot Windows courant, celui que vous utilisez tout le temps, mais sans l’activation de Hyper-V…
Je sais, cela demande de redémarrer le PC pour travailler avec ou sans Hyper-V. C’est Hyper…Lourdingue.
Je l’admets, mais c’est Hyper-V qui impose cette lourdeur. Pour une fois Microsoft n’a techniquement pas fait très fort. Les autres émulateurs du marché, même l’excellent VirtualBox de Oracle – que je n’aime pourtant pas, surtout leur boss et leurs produits en général - fonctionne comme un charme, en se lançant et en s’arrêtant à volonté. Il y a donc quelque part comme une envie de bloquer les produits identiques à Hyper-V chez Microsoft qui oblige en plus sa présence pour développer en Windows Phone. En tout cas il voudrait faire du mauvaise esprit qu’ils ne pourraient pas trouver mieux. Mais c’est nuisible pour WP.
En dehors de l’enregistrement de la device, étape stupide et inutile, ce genre de tracas techniques expliquent aussi pourquoi il y a si peu d’apps pour Windows Phone, c’est comme si Microsoft ne voulait pas qu’on puisse faire ça facilement. Un paradoxe auquel je n’ai pas de réponse et qu’il faut supporter et accepter tel quel.
Donc la seule solution potable consiste à avoir un boot supplémentaire qui soit une copie du boot actif habituel (on ne va pas réinstaller un OS et perdre une clé de licence…) mais juste sans Hyper-V.
Le côté casse-pieds de la chose est difficile à éviter. Mais cela a l’avantage d’être simple et de fonctionner correctement. D’un point de vue pratique on aime bien parfois sauter de l’exécution d’une app en mode WP8 à Android afin de voir si ce qu’on vient de changer dans un ViewModel fonctionne correctement par exemple. Tout n’est pas perdu puisqu’en mode avec Hyper-V on peut toujours lancer les émulateurs Android de Google qui sont assez lents mais qui marchent bien quand même (sans réclamer eux non plus un truc qui bloque et qui doit démarrer avec l’OS…).
En revanche dans le mode sans Hyper-V pas question d’émuler du Windows Phone. C’est comme ça. Du WinRT oui, mais pas du Windows Phone. Ca serait trop simple.
Donc pour les phases de développement où passer d’un émulateur à l’autre est indispensable, il faut rester en mode Hyper-V. Mais si on doit déboguer longuement la mise en page ou le code d’une app Android, alors là il est bien plus intéressant de redémarrer le PC en mode sans Hyper-V.
Heureusement Windows 8 démarre très vite, c’est un gros avantage.
Reste à savoir comment mettre en place l’astuce…
Mise en œuvre d’un boot sans Hyper-V
Nous allons utiliser bcdedit, l’utilitaire en ligne de commande de Windows qui permet de manipuler le boot.
Pour cela il faut lancer une console de commande en mode administrateur.
Première étape, vérification des lieux
Avant de modifier quoi que ce soit il est préférable de regarder les boots existants.
(cliquez pour voir une image de plus haute résolution)
Cette machine n’a qu’un seul boot en Windows 8.1 x64. On part donc d’une situation très simple. Si vous avez plusieurs boot repérez celui qui est votre boot de travail pour développer.
Seconde étape, copier le boot actuel
Si vous n’avez pas booté dans votre partition de développement, redémarrez et placez-vous en condition “normale” de travail. Car nous allons copier le boot courant, celui qui fonctionne en ce moment sur la machine. La manipulation peut se faire sans avoir démarré dans le boot en question mais c’est plus sujet à erreur. Mieux vaut une manipulation simple.
Dans mon exemple la machine ne possède qu’un seul boot, je ne risque pas de me tromper…
Nous sommes donc dans le boot que nous voulons copier.
Il faut taper la commande suivante pour créer une copie de ce boot :
bcdedit /copy {current} /d "W8-64 NO Hyper-V"
Vous remarquerez que pour éviter de le confondre avec les fraises de bois (c’est la saison en plus) il est possible et vivement conseillé d’entrer une description de ce boot. Ici il s’agit du texte en fin de commande (on tape aussi les guillemets) que vous personnaliserez selon vos gouts cela tombe sous le sens.
On tape à nouveau bcdedit sans paramètre pour inspecter le résultat :
On voit apparaitre une nouvelle entrée en plus de “current”. Pour l’instant la ligne de l’hyperviseur indique toujours un démarrage automatique. En copiant le boot courant nous avons copié toutes ses caractéristiques, y compris le démarrage de Hyper-V.
Dernière étape : couper Hyper-V
Il faut bien prendre note de l’identificateur de la partition que nous avons créée et que nous allons modifier. Je vous conseille de faire un clic droit et de copier le GUID car la commande qui suit va réclamer de saisir ce dernier.
On tape donc maintenant :
bcdedit /set {8259aaac-eab6-11e3-808c-d43d7e01bb9f} hypervisorlaunchtype off
Vous l’avez compris, le GUID à taper n’est pas celui indiqué ci-dessus mais celui du boot créé à l’étape précédente que je vous ai conseillé de copier pour justement le coller dans cette commande…
Une dernière vérification par bcdedit sans paramètre :
Le nouveau boot possède bien “hypervisorlaunchertype” à Off, coupé, éteint, plus rien. Ouf !
Redémarrer
Maintenant il suffit de redémarrer la machine et de choisir le nouveau boot sans Hyper-V. Vous pouvez alors installer HAXM.
Dans ce mode vous pourrez aussi lancer les images Android de l’émulateur Intel bien plus rapide que celui de Google. Le débogue sous Visual Studio sera grandement amélioré.
Of course il faudra redémarrer pour travailler en Windows Phone 8. Mais si vous n’avez rien à faire dans ce mode, inutile de vous compliquer la vie : nous avons copié le boot courant, nous n’avons pas créé de nouvelles partition. De fait la machine sur laquelle on se trouve d’un point physique comme logique est exactement la même. On peut installer des logiciels, travailler normalement, ce qu’on fait dans un boot sera présent dans l’autre. Nous avons juste rendu le démarrage de Hyper-V optionnel et sélectable…
Conclusion
C’est sportif, relativement peu élégant même si c’est propre techniquement et pas super pratique.
C’est vrai.
Mais sinon il faut travailler avec l’émulateur Android de base et c’est très enquiquinant. A vous de voir quand redémarrer le PC est moins pénalisant que de travailler lentement sans HAXM…
En tout cas cette solution est propre, ne duplique rien, ne réclame pas de bricoler la registry ni rien d’autre. Le boot créé peut être détruit sans problème on ne perd rien, sauf le paramétrage d’un démarrage sans Hyper-V.
Développer réclame autant de ruse que de technicité. Je parle souvent technique, ici c’est par la ruse et l’astuce qu’on obtient un environnement de travail plus puissant.
Reste à espérer qu’un jour HAXM et Hyper-V seront compatibles, surtout lorsque Microsoft et Xamarin se rapprochent comme en ce moment et que travailler en Android et en Windows Phone simultanément ne peut que booster ce dernier. C’est tout l’intérêt de Microsoft de trouver une solution. Mais en attendant je vous ai montré comment se passer de cette dernière.
Je fais comme le gouvernement, selon Coluche donc ce n’est pas récent, “dites moi de quoi vous avez besoin et je vous expliquerai comment vous en passer” 
Stay Tuned !