Comment améliorer le support X86 des applications et bibliothèques sur Android

Depuis 2012, il y a plus encore que ces différents projets : vous pouvez trouver des smartphones et des tablettes x86 avec Android en vente libre. Le premier en France était le « Orange avec Intel Inside », et voici quelques autres exemples un peu plus actuels : Samsung Galaxy Tab 3 10.1′, Asus MemoPad FHD 10, Motorola Razr I… et bientôt l'Asus Fonepad Note 6 (déjà disponible chez nos voisins).

Les applications Android sont gérées par la machine virtuelle Dalvik (DVM), ou le projet émergent Android RunTime (ART). Ces technologies sont multiarchitectures par nature et marchent très bien sur x86 !

Néanmoins certaines applications (entre 40 % et 60 %) utilisent aussi des bibliothèques spécifiques au CPU… et dans de nombreux cas pour le moment, ces bibliothèques ne sont incluses que pour les architectures ARM.

Par « chance », les produits à architecture Intel qui sont dans le commerce embarquent tous un élément particulier appelé « NDK apps bridging technology » qui permet à ces binaires ARM de fonctionner à travers une couche de compatibilité. C'est pourquoi dans la pratique, vous pourriez vous-même avoir des difficultés à deviner si un produit est x86 ou non.

•« NDK Apps Bridging Technology » est la propriété d'Intel, vous ne la retrouverez pas forcément dans des produits tiers ;

•même si cette technologie marche très bien, une telle couche de compatibilité entraîne forcément une baisse de la performance et une hausse de la consommation par votre application - qui ne sont pas négligeables si vous faites des opérations un peu lourdes ;

•vous ne la contrôlez pas : les anciens modèles de smartphones embarquent une ancienne version de la technologie dont vous ne pouvez pas espérer un aussi bon fonctionnement que dans le cas des versions actuelles ;

•votre application pourra forcément mieux tourner si des versions x86 de vos bibliothèques sont incluses, et habituellement ce n'est pas une grosse charge de les compiler/obtenir et les intégrer.

La première chose à faire est de regarder si vous embarquez des bibliothèques natives dans votre application.

Bien sûr, cela n'arrive pas par hasard ! Si vous utilisez vous-même le NDK Android, vous savez déjà que votre application embarque des bibliothèques natives… Peut-être même que tout le code de votre application est écrit en C/C++ (ex. : vous utilisez native_app_glue.h).

Mais ces fichiers .so (shared object libraries) peuvent aussi être générés par des moteurs de jeu/frameworks ou inclus par des bibliothèques que vous utilisez.

L'emplacement habituel pour ces fichiers est dans libs/TARGET_ARCH_ABI où TARGET_ARCH_ABI peut être, à l'heure actuelle : armeabi (ARMv5), armeabi-v7a (ARMv7), mips ou x86.

Commencez par configurer APP_ABI:=all dans votre Makefile « jni/Application.mk » (et non Android.mk! vous aurez peut-être à le créer), pour changer la valeur par défaut qui est « armeabi ».

La prochaine fois que vous compilerez votre code, les bibliothèques seront générées pour toutes les architectures que le NDK supporte, dans libs/TARGET_ARCH_ABI/*.so :

Simple, non ?

Habituellement cela se passe très bien…mais utiliser une nouvelle chaîne de compilation peut mettre en lumière certains bogues ou erreurs latentes dans votre code. Un exemple simple est lorsque vous avez du code qui ne respecte pas le standard C/C++ : le résultat peut changer selon l'implémentation faite dans le compilateur.

La chose la plus évidente qui peut stopper la compilation x86 est d'avoir du code assembleur ARM quelque part… vous obtiendrez alors de telles erreurs :

Error: no such instruction: `ldr r12,[r0]'
Error: no such instruction: `smull %edx,%esi,%eax,%ecx'
Error: number of operands mismatch for `mov'
Error: impossible constraint in 'asm'

Habituellement, cela arrive avec des bibliothèques multiplateformes qui ont leurs variables de compilation configurées incorrectement pour Android - entraînant l'inclusion de code spécifique ARM - et vous avez seulement besoin de les corriger(1)

C'est le cas le plus courant que j'ai rencontré, je traiterai ce cas plus spécifiquement dans de prochains articles.

Les techniques classiques de débogage (gdb…) marchent toujours lorsque vous utilisez l'image x86 d'Android à travers l'émulateur du SDK (+HAXM/kvm) ou Genymotion.

C'est aussi une bonne idée d'utiliser ces outils régulièrement puisqu'ils sont bien plus rapides que l'émulateur du SDK Android dans sa configuration par défaut.

-O3 et -ffast-math sont les CFLAGS classiques que vous pouvez ajouter pour permettre un maximum d'optimisations par le compilateur lorsque vous visez n'importe quelle plate-forme.

Vous pouvez aussi spécifier des optimisations supplémentaires spécifiques aux plates-formes que vous visez. Dans le cadre d'une compilation x86, il est conseillé de spécifier ceci dans votre Makefile jni/Android.mk :

ifeq ($(TARGET_ARCH_ABI),x86)
    LOCAL_CFLAGS += -mtune=atom -mssse3 -mfpmath=sse
endif

Le jeu d'instructions SSSE3 est disponible sur tous les systèmes Android à base x86 donc vous pouvez l'utiliser directement. Vous pourrez aussi avoir une bonne hausse de performances (cela peut être aux alentours de 20 %), en passant du jeu d'instructions x87 à SSE pour les opérations en virgule flottante.

Nul besoin de sacrifier un dossier de bibliothèques natives si vous cherchez à réduire le poids de votre application. Vous pouvez scinder votre .apk pour en avoir une version par architecture tout en gardant une seule entrée dans le Google Play Store.

Commencez par passer du mode simple au mode avancé dans votre console développeur. Puis envoyez différents APK faits pour différentes architectures, avec pour chacun une valeur android:versionCode différente, configurées dans le fichier AndroidManifest.xml.

Si vous voulez que le bon APK aille sur le bon système, il n'y a qu'une seule règle à suivre :

Numéro de version x86 > Numéro de version ARMv7 > Numéro de version ARMv5

Car un unique système peut être compatible avec l'ensemble de ces architectures, auquel cas le Google Play Store servira l'APK compatible dont le nombre « android:versionCode » est le plus élevé.

Vous pouvez appliquer cette règle de la manière que vous le souhaitez, mais il est plus simple de le faire en suivant une convention telle que la suivante : préfixez votre numéro de version actuelle par un chiffre représentant l'architecture supportée.