Android x86 : Intel publie une image pour Android 4.0.4 et ses sources

L'émulateur est-il plus rapide étant donné que c'est du x86?

Je dirais que oui, vu que tu n'as pas besoin d'émuler.
Et surtout, au pire, tu peux coller ça dans une machine virtuelle :)

Une machine virtuelle qui reboot tout seul au lancement d'un apk de test, ça, c'est fait.
Soit y'a un bug, soit y'a un truc que je comprends pas....

On peut s'amuser à faire booter ça sur une machine réelle?

Euh... dans tous les cas, ça reste du Java !
Certes, il y a le NDK, mais il me semble qu'Intel a développé un émulseur ARM pour x86 pour que les applis faisant appel au NDK fonctionnent.
Faut que je retrouve la source cependant...

Je dirais que tu auras des problèmes de drivers, mais ça a déjà été fait, il existe un portage x86 d'android qui tourne bien sur netbook et/ou virtualbox.


Ouais mais d'habitude tu émules de l'ARM qui fait tourner une machine virtuelle Java. Et c'est lent. Là c'est juste que tu fais tourner un programme x86 classique qui contient une JVM, c'est beaucoup moins lourd de suite.
Quand au NDK tu peux peut être l'émuler mais le plus simple c'est tout simplement de recompiler le code natif pour x86, android est prévu pour ça même si peu d'applications proposent leur partie native pour les x86.

Encore des idées fausses sur la "lenteur" de Java.
Si on va par là, le C# est lent, le Python est lent, etc... Tout simplement parce qu'ils reposent sur le même fonctionnement, ie: une machine virtuelle avec un garbage collector.

Là, c'est lent parce que ça émule un processeur ARM et que pour ne pas aider, ça n'est pas optimisé pour diverses raisons (temps, utilité, ne fait pas tout (accéléromètre, etc))...

Je ne critiquais pas Java (même si ce n'est pas l'envie qui m'en manque :-p). Ce que je voulais dire, c'est que ça soit un simulateur ou en VM, ça ne changeait pas grand chose, vu que c'était du bitcode Java.
Du coup, aucune utilité d'émuler de l'ARM, SAUF pour le NDK.
Dans ce cas, j'espère qu'Intel a bien fait les choses : une VM Java x86, qui, lors des appels à des .so natif "ARM", fait appel à son traducteur de code ARM-->x86.

PS: Eclipse est quand même vachement lourd... ET lent. Sans parler de netbeans.

Sauf pour Mme Michu qui ne comprendra jamais de quoi tu parles.
Avec tout le respect que je dois à cette dame, elle ne va pas comprendre pourquoi ça ne fonctionne pas alors qu'avec sont précédent smartphone, ça fonctionnait.

Du coup, au niveau compatibilité, il est quand même judicieux d'avoir une émulation du code ARM.
Après, charge à Google d'imposer que lors de l'upload de l'apk, les .so natifs soient compilés pour ARM, x86 et MIPS. (sans compter la différence entre ARMv6 et ARMv7)

Le market est bien foutu tu sais, il existe des filtres qui font que si l'APK ne gère pas le x86 il ne sera pas proposé pour ces terminaux. Donc Mme Michu aura juste beaucoup moins de choix sur son market au départ.
Mais si les smartphones x86 commencent vraiment à arriver sur le marché en plus ou moins grande masse, ne t'en fais pas, les éditeurs compileront pour x86, ça ne devrait pas rajouter d'étape de dev supplémentaire la compilation c'est juste appuyer sur un bouton de plus.
C'est exactement le même principe que lors de la sortie d'une nouvelle version majeure comme ICS, sur le market au début il y avait beaucoup d'applications en moins. Mais trois mois plus tard toutes les applis y sont et tout fonctionne à merveille.