Android 64 bits et Android Runtime

0
409

Les systèmes Android 64 bits sont la nouvelle tendance du marché mobile. En septembre 2013, Apple a lancé l’iPhone 5 équipé d’un processeur A7 64 bits. C’est ainsi qu’a débuté la concurrence sur les technologies mobiles.

Il s’est avéré que le système Android, basé sur un noyau GNU/Linux supportait depuis longtemps les processeurs équipés de registres 64 bits. Ubuntu est un système « GNU/Linux » tandis qu’Android est un système « Dalvik/Linux ». Dalvik est le processus machine virtuelle (Process Virtual Machine, VM) intégré dans le système d’exploitation Android de Google, qui exécute spécifiquement des applications Android. De ce fait, Dalvik est considéré comme une partie intégrale d’Android Software Stack, qui est typiquement utilisé dans des terminaux mobiles comme les Smartphones ou les tablettes, et plus récemment d’autres machines comme les smart TV et les Wearables devices (Android Wear, la montre Android).

Néanmoins, tout utilisateur utilisant le NDK doivent recréer leurs programmes avec l’architecture la plus récente. Le niveau de difficulté de ce processus dépend des outils fournis par Google. De plus, Google doit garantir la rétrocompatibilité (exemple : Une application NDK 32 bits doit fonctionner sous un système Android 64 bits).

Les premiers processeurs Intel 64 bits destinés aux appareils mobiles ont été créés durant le 3ème trimestre de l’année 2013 et étaient les nouveaux System on a Chip (SoC) multicœurs puissants pour les terminaux mobiles et bureautiques. Cette nouvelle famille de SoC se compose des processeurs Intel® Atom™ pour les tablettes et les machines 2 en 1, des processeurs Intel® Celeron®  et des processeurs Intel® Pentium® pour les machines 2 en 1, les ordinateurs portables, les PC  bureautiques et les PC All in One.

En Octobre 2014, Google a lancé un aperçu de l’émulateur image de l’Android L 64 bits pour les développeurs. Cette image a permis aux développeurs de tester leurs applications et de réécrire leurs codes si nécessaire avant le lancement de l’OS. Dans le blog Google+, certains développeurs ont indiqué que les applications entièrement développées avec Java ne nécessitent pas une opération de portage. Ces applications ont été exécutées « telles qu’elles » dans la version « L » de l’émulateur, qui supportait une architecture 64 bits. Par contre, les applications développées avec d’autres langages, spécialement en C et C++, nécessitent certaines étapes additionnelles pour être créée sous le nouveau Android NDK. Les terminaux disposant d’une ancienne version Android 64 bits sont encore présents sur le marché, leurs fabricants devraient néanmoins les mettre à jour rapidement, car il risque d’avoir une carence au niveau des applications disponibles aux utilisateurs.

L’émulateur Android L 64 bits

En Juin 2014, Google a annoncé qu’Android supportera le 64 bits lors du lancement de la nouvelle version L. Une bonne nouvelle pour tous ceux qui souhaitent disposer d’une performance optimale de leurs terminaux et applications mobiles. La liste des avantages cités par Google dans cette mise à jour inclut un nombre plus important des registres, une augmentation de l’espace mémoire adressable et un ensemble de nouvelles instructions.

L’émulateur Android supporte plusieurs caractéristiques Hardware qu’on peut trouver dans les terminaux mobiles, dont :

  • Un processeur ARM v5 et son Memory Management Unit (MMU) correspondant
  • Un affichage LCD 16 bits
  • Un ou plusieurs claviers (Clavier Qwerty + boutons Dpad/Phone associés)
  • Une puce son avec support des opérations d’entrée et de sortie (Microphone/Haut Parleur)
  • Des partitions de mémoire Flash (Émulées à travers des fichiers images disque présents dans votre machine de développement)
  • Un modem GSM, avec la simulation d’une puce SIM
  • Une caméra qui utilise la webcam de votre machine de développement
  • Des capteurs (Accéléromètre, etc.) utilisant les données issus d’un terminal Android connecté via USB

Cet émulateur représente un avantage important pour le développement de nos applications et terminaux favoris. Malheureusement, nous devons attendre la sortie d’Android L avant de bénéficier de ces nouvelles améliorations de performance. Quelques semaines après le lancement de Android L, la Révision 10 du Native Development Kit (NDK) devrait être publiée avec support des 3 architectures 64 bits qui pourront faire fonctionner la nouvelle version Android : arm64-v8&, x86_64 et mips64. Si vous avez développé une application en Java, votre code sera automatiquement plus performant dans la nouvelle architecture x86 64 bits. Google a mis à jour le NDK Révision 10b et a ajouté une image émulateur que les développeurs pourraient utiliser pour préparer leurs applications et les rendre fonctionnelles sous des machines munis de processeurs Intel 64 bits.

Gardez dans votre esprit que le NDK est uniquement destiné pour des applications natives, et non celles développées en Java en utilisant le Android SDK standard. Si vous cherchez à faire fonctionner vos applications sous 64 bits ou si vous avez besoin de mettre à jour votre NDK vers la dernière version, rendez-vous sur le portail de Développement pour la télécharger.

Développez avec Android NDK x86_64

Le Native Development Kit (NDK) est un ensemble d’outils qui permet d’implémenter des parties de votre applications en utilisant du code natif écrit avec des langages tels que C et C++. Pour certains types d’applications, le NDK peut être très utile, car il permet la réutilisation des librairies existantes écrites dans ces langages, mais l’Android NDK n’est pas forcément utilisé pour toutes les applications. Vous devez faire un comparatif entre les bénéfices de l’utilisation d’un NDK et les inconvénients. Plus particulièrement, développer des applications Android avec du code natif n’inclut pas généralement une amélioration de performance, mais augmentera toujours la complexité de l’application. Vous devez donc utiliser le NDK uniquement si c’est essentiel pour votre application, et non pour vos préférences pour le C/C++ en matière de choix du langage de programmation.

Vous pouvez télécharger la dernière version de Android NDK via ce lien.

Dans cette section, nous allons revoir comment compiler une application modèle en utilisant le Android NDK.

Nous utiliserons l’application modèle san-angeles, qui se trouve dans le répertoire Android NDK samples :

$ANDROID_NDK/samples/san-angeles

Le code natif est situé dans le dossier  jni/

$ANDROID_NDK/samples/san-angeles/jni

Le code natif est compilé pour une/des architecture(s) CPU particulière(s). Les applications Android peuvent contenir des librairies pour plusieurs architectures au sein d’un fichier APK unique.

Pour configurer une architecture cible, vous devez créer un fichier Application.mk au sein du dossier jni/. La ligne suivante compilera toutes les librairies natives pour toutes les architectures supportées :

APP_ABI := all

Parfois, il vaudrait mieux spécifier une liste des architectures ciblées. Cette ligne compilera les librairies pour les architectures x86 et ARM :

APP_ABI := x86 armeabi armeabi-v7a

Puisque nous sommes en train de développer une application 64 bits, nous devons compiler les librairies pour les architectures x86_64.

APP_ABI := x86_64

Exécutez la ligne de commande suivante dans le répertoire des modèles pour créer les librairies :

Cd $ANDROID_NDK/samples/san-angeles

Après la création réussite de l’opération, ouvrez le modèle dans Eclipse (As an Android Application) et cliquez sur “Run”. Sélectionnez l’émulateur ou le terminal Android connecté suivant votre choix pour l’exécution de l’application.

Pour supporter tous les terminaux disponibles vous devez compiler l’application pour toutes les architectures. Si le fichier apk avec les librairies compatibles pour toutes les architectures devient trop volumineux, vous pouvez suivre les instructions présentes dans le Google Play Multiple APK Support pour préparer un fichier apk pour chaque plateforme.

Vérifier les architectures supportées

Vous pouvez utiliser cette commande pour vérifier quelles architectures sont incluses dans le fichier apk :

aapt dump badging file.apk

La ligne suivante liste toutes les architectures :

Native-code : ‘armeabi’, ‘armeabi-v7a’, ‘x86’, ‘x86_64’

Vous pouvez également faire cette vérification d’une autre manière, en ouvrant le fichier apk en tant qu’archive Zip et en vérifiant les sous-dossiers présents dans le dossier lib/

Optimisation des applications 64 bits
Réduction de la mémoire consommée par une application

Quand un programme est compilé en mode 64, il consomme beaucoup plus de mémoire qu’un programme compilé en 32 bits. Cette augmentation est souvent non détectée, mais la consommation de mémoire peut dans certains cas doubler par rapport aux applications 32 bits. La quantité de mémoire consommée est déterminée par les facteurs suivants :

  • L’existence de certains objets, tels les pointeurs, qui nécessitent des grandes quantités de mémoire
  • L’alignement et le rembourrage de la structure de données
  • La consommation excessive de la mémoire à pile

Les systèmes 64 bits disposent d’une plus grande quantité de mémoire disponibles aux utilisateurs par rapport aux systèmes 32 bits. Par exemple, si un programme consomme 300 Mbytes sur un système 32 bits avec 2 Gbytes de mémoire mais nécessite 400 Mbytes sur un système 64 bits avec 8 Gbytes de mémoire, le programme consommera relativement 3 fois moins de mémoire sur un système 64 bits. Le seul inconvénient réside dans la perte de performance. En effet, bien que les applications 64 bits soient plus rapides, l’extraction d’une plus grande quantité de données de la mémoire peut annuler tous les avantages, voire même réduire la performance. Le transfert de données entre la mémoire vive et la mémoire cache du microprocesseur est en effet coûteuse.

Réduire la consommation de mémoire est possible. Pour cela, il faut optimiser les structures de données. D’autre part, l’utilisation de types de données qui économisent la mémoire est possible. Par exemple, si nous avons besoin d’enregistrer un grand nombre de variables de types entier et que nous savons que leurs valeurs ne dépasseraient jamais UINT_MAX, nous pouvons utiliser le type « unsigned » au lieu de « size t », comme le montre la section suivante.

Utilisation des types memsize dans l’adresse arithmétique

L’utilisation des types « ptrdiff_t » et de « size t » dans l’adresse arithmétique peut vous faire bénéficier d’un gain de performance supplémentaire, en plus de rendre le code plus sécurisé. Par exemple, utiliser le type « int », chez qui la taille peut différer selon la capacité du pointeur en tant qu’index peut résulter des commandes de conversions de données supplémentaires en code binaire. Vous pouvez avoir du code 64 bits, une taille de pointeur 64 bits, mais la taille du type « int » sera la même, c’est-à-dire 32 bits.

Il n’est pas aisé de donner des exemples montrant la supériorité du « size t » par rapport au « unsigned ». Pour avoir la certitude, il faut utiliser les capacité d’optimisation du compilateur. Néanmoins, l’utilisation des 2 variantes du code optimisé peut aboutir à des résultats tellement différents qu’il devient moins facile de démontrer leurs différences. Nous avons œuvré pour créer ce qui pourrait être un exemple simple après 6 essais. Mais cet exemple ne peut en aucun cas être un cas idéal parce que, au lieu d’avoir un code qui contient les conversions de types de données inutiles discutées précédemment, cet exemple nous montre que le compilateur peut compiler un code plus efficient en utilisant le « size_t ». Vous pouvez prendre ce code, qui réorganise les items de type array dans un ordre inversé, en considération.

1

Les variables « arraySize » et « i » de l’exemple sont de type « unsigned ». Vous pouvez facilement les remplacer par le type « size_t » et comparer un fragment du code assembleur figuré dans le Tableau 1.

2

Tableau 1 : Comparaison d’un fragment de code assembleur 64 bits utilisant les types « unsigned » et « size_t »

Le compilateur a pu compiler un code plus concis en utilisant des registres 64. Nous ne voulons pas dire que le code créé en utilisant le type « unsigned » (Colonne 1) sera plus lent que son équivalent avec le type « size_t » (Colonne 2). En effet, la comparaison entre les vitesses d’exécution du code est difficile chez les processeurs actuels. Mais cet exemple montre clairement que le compilateur a compilé un code plus concis et plus rapide en utilisant les types 64 bits.

Voici un exemple qui montre les avantages des types « ptrdiff_t » et « size_t » en terme de performance. Pour les besoins de cet exemple, nous avons choisi un algorithme simple qui calcule le chemin le plus court.

La fonction « FindMinPath32 » est écrite dans un style 32 bits classique, utilisant les types « unsigned ». La fonction « FindMinPath64 » diffère uniquement dans l’utilisation des types « size_t » au lieu des types « unsigned ». Voici la comparaison des temps d’exécution entre les 2 fonction (Tableau 2)

3

Tableau 2 – Temps d’exécution des fonctions « FindMinPath32 » et « FindMinPath64 »

Le Tableau 2 montre un temps réduit relativement à la vitesse d’exécution de la fonction FindMinPath32 sur un système 32 bits. Ce tableau a été développé dans un but de clarté, c’est-à-dire que, supposant que la vitesse d’opération d’une fonction FindMinPath32 sur un système 32 bits est égale à 1, nous choisissons ce temps comme unité de mesure.

La 2ème ligne nous montre que la vitesse d’opération de la fonction FindMinPath64 est également égale à 1 sur un système 32 bits. Logique, vu que le type « unsigned » coincide avec le type « size_t » sur un système 32 bits, et que nulle différence n’existe entre les fonctions FindMinPath32 et FindMinPath64. La déviation minime (1.002) est uniquement due à une petite erreur de mesure.

Dans la 3ème ligne, nous remarquons un gain de performance de 7%. Ce résultat est attendu vu la recompilation du code sur un système 64 bits.

La quatrième ligne est certainement la plus important pour nous. En effet, il s’agit d’un gain de performance de 15%. En utilisant tout simplement le type « size_t » au lieu de « unsigned », le compilateur a crée un code plus effectif, et qui s’exécutera 8% plus rapidement.

Cet exemple simple et évident montre que les données qui ne sont pas égales aux tailles des mots d’un microprocesseur peuvent ralentir la performance d’un algorithme. Utiliser les types « ptrdiff_t » et « size_t » au lieu de « unsigned » peut engendrer un gain de performance significatif. Ce résultat s’applique dans tous les cas où ces types de données sont utiliser pour l’indexation des tableaux (arrays ), dans l’adresse arithmétique et pour la réorganisation des boucles.

Note : PVS-Studio est un outil d’analyse de programmes statiques commercial pour C, C++ et C++11. Bien qu’il ne soit pas conçu spécialement pour optimiser les programmes, il pourrait être d’une grande aide pour retravailler le code, et donc rendre le code plus efficient. Par exemple, vous pouvez utiliser les types memsize quand vous corrigez certaines erreurs potentielles relatives à l’adresse arithmétique, ce qui permettra au compilateur de produire un code plus optimisé.

Fonctions intrinsèques

Les fonctions intrinsèques représentent des fonctions spéciales dépendantes du systèmes qui réalisent des opérations qui ne peuvent être réalisées au niveau du code C/C++ ou qui réalisent ces opérations de manière plus efficace. Actuellement, ils permettent de se débarrasser de certains fragments de code assembleur inutiles ou inutilisé.

Les programmes peuvent utiliser des fonctions intrinsèques pour créer un code plus rapide, et ce grâce la faible consommation de l’entête lors de l’opération d’appel de ces fonctions. Par contre, le code sera naturellement plus long. MSDN donne une liste de fonctions qui peuvent être remplacés par leurs équivalents intrinsèques. A titre d’exemple, nous citons memcpy, strcmp, etc.

En plus du remplacement automatique de ces fonctions standards par leurs équivalents intrinsèques, vous pouvez utiliser des fonctions intrinsèques explicitement dans votre code. Ceci peut être bénéfique, vu que :

  • L’assembleur inline n’est pas pris en charge par le compilateur Visual C++ en 64 bits, à l’inverse du code intrinsèque qui l’est.
  • Les fonctions intrinsèques sont plus faciles à utiliser vu qu’elles ne nécessitent pas une connaissance particulière des registres ou de tout autre composant bas-niveau similaire.
  • Les fonctions intrinsèques sont mises à jour dans les compilateurs, tandis que le code assembleur doit être mis à jour manuellement
  • Le code assembleur ne peut pas exécuter des optimiseurs embarqués
  • Le code intrinsèque est plus facilement portable que le code assembleur.

L’utilisation des fonctions intrinsèques en mode automatique (A l’aide du switch compilateur) vous permettra d’avoir un gain de performance, et l’utilisation du mode Manuel augmentera ce gain. C’est pour cela que l’utilisation des fonctions intrinsèques est très bénéfique.

L’alignement

L’alignement des structures de données consiste en la manière par laquelle les données sont organisées et accessibles dans la mémoire de l’ordinateur de l’ordinateur. Elle consiste en 2 concepts indépendants mais reliés entre eux : L’alignement des données (Data Alignment) et le rembourrage de la structure de données (Data Structure Padding). Quand un ordinateur moderne réalise une opération de lecture ou d’écriture sur une adresse mémoire, il le fera en portions de taille équivalent à celle d’un word, ou mot informatique (Par exemple, une portion de 4 bytes sur un système 32 bits) ou plus. Le Data Alignment signifie que la mise des données en mémoire offset est égale à des types ayant des tailles multiples de celle du type word, ce qui améliore la performance du système, grâce notamment à la manière dont le CPU se charge de la mémoire. Pour aligner les données, il serait nécessaire d’insérer certains bytes négligeables entre la fin de la dernière structure de données et le début de la structure suivante, ce qui signifie le Data Structure Padding.

Par exemple, quand la taille d’un mot informatique est de 4 bytes (Ce qui veut dire qu’elle est égale à 8 bytes sur la plupart des machines, mais qu’elle pourrait être différente sur certains systèmes), la donnée à lire devrait être placé sur une mémoire offset d’une taille égale à un multiple de 4. Si ce n’est pas le cas, c’est-à-dire, à titre d’exemple la donnée commence à partir du 14 byte au lieu du 16ème, la machine devrait lire 2 portion de 4 bytes et devrait réaliser certaines opérations de calculs avant la lecture de la donnée en question, ou cela conduirait à une erreur d’alignement. Même si la structure de données précédentes se termine au 13ème byte, la structure de donnée suivante devrait commencer au 16ème bytes. 2 bytes de rembourrage sont insérés entre les 2 structures de données pour aligner la structure de données suivante au 16ème byte.

Bien que l’alignement des structures de données soit un concept fondamental pour toutes les machines modernes, plusieurs langages informatiques et plusieurs variations de ces langages supportent l’alignement de données de manière automatique.

Dans certains cas, vous pouvez aider le compilateur à augmenter la performance en définissant manuellement l’alignement des données. Par exemple, les données Streaming SIMF Sextensions (SSE) doivent être alignées à une limite 16 bytes. Vous pouvez réaliser cet alignement avec le code suivant :

4

Android Runtime

Les applications Android Runtime (ART) ont été développés par Google, pour remplacer Dalvik. Ce Runtime offre une panoplie de nouvelles fonctionnalités qui améliorent la performance et la souplesse de la plateforme et des applications Android. ART a été introduit dans la version Android 4.4 Kitkat ; Il remplacera entièrement Dalvik dans la version 5.0. Contrairement à Dalvik, ART utilise (En exécution) un compilateur Just-In-Time (JIT), ce qui veut dire qu’ART compile une application lors de l’étape d’installation, ce qui résulte une exécution plus rapide du programme, et par conséquent une augmentation du temps de vie de la batterie.

Pour des raisons de rétrocompatibilité, ART utilise le même code byte que Dalvik.

En plus de l’augmentation potentielle en vitesse, l’utilisation d’ART peut engendrer un 2ème bénéfice important. Puisque ART exécute les applications en code machine directement (Exécution native), il n’affecte pas le CPU aussi brutalement qu’une compilation Just In Time avec Dalvik. Une utilisation moindre du CPU est synonyme d’une consommation moindre des ressources de la batterie, ce qui représente un avantage pour les terminaux mobiles en général.

Pourquoi ART n’a-t-il pas été implémenté précédemment ?  Pour connaître les raisons, nous devons connaître les inconvénients d’une compilation Ahead Of time (AOT). En premier lieu, le code machine généré nécessite plus d’espace que le code byte existant. Ensuite, le code est précompilé au moment d’installation, ce qui augmente le temps d’installation. Enfin, cela correspond également à une plus grande trace mémoire au moment de l’exécution. Ceci signifie que seuls quelques applications pourront s’exécuter de manière concurrentielle. La première machine Android disposait, en effet, d’une mémoire et d’une capacité de stockage très réduite, et présentait ce qui était connu par l’effet goulot de bouteille, en terme de performance. C’est pour cette raison que l’approche JIT avait été favorisée. De nos jours, la mémoire est beaucoup plus abordable et beaucoup plus abondante, même sur des machines bas de gamme, ce qui rend le choix de l’approche ART logique.

Dans ce qui est considéré comme l’un des meilleurs de ses avantages, ART compile dorénavant l’application en code machine natif quand il est installé sur une machine utilisateur. Appelé Compilation Ahead Of Time, vous pouvez remarquer des gains de performance énormes, puisque les compilateurs sont configurés pour des architectures spécifiques (Telles ARM, x86 ou MPIS). Ceci élimine tout besoin d’une compilation Just In time à chaque exécution d’une application. Certes, la compilation AOT augmentera le temps d’installation de l’application, mais démarrera plus rapidement, étant donné que plusieurs tâches exécutées sur Dalvik VM, comme la vérification des classes et méthodes, sont déjà mises en place.

Ensuite, l’équipe ART a œuvré pour optimiser le Garbage Collector (GC). Au lieu des 2 pauses totalisant 10ms pour chaque GC sur Dalvik, vous n’observerez qu’une seule pause, inférieure à 2ms. L’équipe a également parallélisé des portions d’exécution du GC et optimisé la collection des stratégies pour être informé des états de la machine. Par exemple, un GC plein s’exécutera uniquement quand le téléphone est verrouillé, et quand l’interaction utilisateur n’est plus importante. Ceci représente une amélioration majeure pour les applications sensibles aux sauts de trames (Dropping Frame). De plus, les prochaines versions d’ART devraient inclure un collecteur compact qui déplacerai les portions de mémoire allouée dans des blocs contigus pour réduire la fragmentation et le besoin de terminer (kill) d’autres applications pour allouer des vastes régions de mémoire.

Dernièrement, ART utilise un tout nouveau allocateur de mémoire appelé « Rosalloc » (Allocateur Runs of slots). La plupart des systèmes modernes utilisent des allocateurs mémoire basés sur le design Doug Lea, qui dispose d’un unique verrou de mémoire global. Dans un environnement orienté objet multi thread, ceci créera des interférences avec le Garbage collector et les autres opérations mémoire. Avec Rosalloc, les petits objets communs en Java sont alloués dans une région thread local sans aucun verrou et les objets les plus larges disposeront de leurs propres verrous. Ainsi, quand vos applications essaieront d’allouer de la mémoire pour un nouvel objet, il ne serait plus nécessaire d’attendre que le Garbage Collector vide un espace mémoire non relié.

Actuellement, Dalvik est disponible par défaut sur les terminaux Android, et ART est disponible en option sur quelques terminaux Android 4.4, comme les smartphones Nexus édition Google Play, les Motorola Android et d’autres. ART est actuellement en cours de développement, et recherche des développeurs et des avis utilisateurs. ART pourrait éventuellement remplacer Dalvik dès le lancement d’une version stable. En attendant, les utilisateurs disposant de terminaux compatibles pourraient migrer de Dalvik vers ART s’ils sont intéressés par cette nouvelle fonctionnalité et s’ils souhaitent la tester et expérimenter ses performances.

Pour migrer ou activer ART, votre terminable doit être sous Android 4.4 Kitkat et doit être compatible avec ART. Vous pouvez activer l’exécution ART via « Paramètres » -> « Options Développeur » -> « Option d’exécution » (Note : Si vous ne trouvez pas « Options Développeur » dans les paramètres, allez vers « A propos du téléphone » scroller en bas jusqu’à trouver le numéro du build et tapotez dessus 7 fois pour activer les Options Développeur »). Le smartphone redémarrera et commencera l’optimisation des applications pour ART, ce qui devrait prendre environ 15-20 minutes suivant le nombre d’applications installées sur votre smartphone. Vous remarquerez également que la taille des applications installées a augmenté après l’activation d’ART.

Note : Après la migration vers ART, en redémarrant le smartphone pour la première fois, ART optimisera encore une fois les applications, ce qui peut être gênant.

Etant donné que Dalvik est le mode d’exécution par défaut sur les machines Android, certaines applications pourraient ne pas fonctionner sur ART, bien que la plupart sont compatibles avec ART et devraient fonctionner correctement. Mais, dans le cas où vous rencontriez des bugs ou des crashs d’application, il serait plus judicieux de réutiliser Dalvik.

Migrer vers ART sur des terminaux nécessite de connaître comment effectuer ce changement. Google l’a caché quelque part dans les Paramètres. Heureusement, il existe une astuce qui permet d’activer ART sur les terminaux disposant d’Android 4.4 Kitkat.

Clause de non responsabilité : Avant d’essayer d’activer ART, vous devez effectuer une sauvegarde de vos données. Intel ne sera pas tenue responsable si votre terminal devient endommagé (Démarrage impossible quelle que soit la démarche). Essayez à vos risques et périls !

  • Nécessite le Root
  • A ne pas essayer si des outils WSM sont installés, ces derniers ne sont pas compatibles avec ART

Pour activer ART, suivez minutieusement ces étapes :

  1. Assurez-vous que votre terminal est « rooté »
  2. Installez « ES File Explorer » du Play Store
  3. Exécutez ES File Explorer, tapez sur l’icône du menu situé dans le coin haut gauche et sélectionnez « Tools ». Dans le menu tools, activez l’option « Root Explorer »  et garantissez un accès total pour le ES explorer lors de l’affichage de la fenêtre prompt de validation
  4. Dans le ES Explorer, ouvrez le répertoire Device (/) à partir de Menu -> Local -> Device. Allez vers le dossier /data/property. Ouvrez le fichier persist.sys.dalvik.vm.lib en tant que fichier texte et sélectionnez l’éditeur de texte ES note
  5. Editez le fichier en sélectionnant « edit » au coin haut droite. Remplacez la ligne contenant libdvm.so par libart.so
  6. Revenez vers le fichier persist.sys.dalvik.vm.lib et sélectionnez « Yes » pour l’enregistrer. Ensuite, redémarrez votre smartphone
  7. Le smartphone redémarrera et commencera l’optimisation de vos applications vers ART. le redémarrage peut prendre du temps suivant le nombre d’applications installées.

Dans le cas où vous voulez revenir vers Dalvik, suivez les mêmes étapes édictées précédemment et remplacez le texte dans le fichier persist.sys.dalbik.vm.lib par libdvm.so

Conclusion

Google a lancé une image d’émulateur 64 bits pour son tant attendu Android L, mais uniquement pour des microprocesseurs Intel x86. Le nouvel émulateur devrait permettre aux développeurs de développer et optimiser leurs anciennes applications pour être compatibles avec le nouveau systèmes Android L et sa nouvelle architecture 64 bits. Migrer vers le 64 bits augmente l’espace mémoire adressable, et offre un plus grands nombre de registres et de nouveaux jeux d’instructions aux développeurs. Ceci ne veut néanmoins pas dire que les applications 64 bits soient plus rapides.

Les applications Java bénéficieraient automatiquement des avantages du 64 bits, dû au fait que leurs codes seront interprétés par le nouvel ART VM 64 bits. Ceci implique également qu’aucune changement en Java natif n’est nécessaire. Les applications compilées sous Android NDK nécessiteraient par contre d’être optimisées pour inclure la cible du build x86_64. Intel peut porter conseil sur la manière de porter le code qui cible l’ARM vers le x86/x64. En utilisant le nouvel émulateur, les développeurs seront capables de créer des applications pour des processeurs basés sur Intel® Atom™.

Intel fournissait au développeurs des outils et un très bon support système Android, en particulier son Gestionnaire Intel® HAXM, et une panoplie d’images d’OS Intel Atom. Plusieurs développeurs Android testent régulièrement sur des architectures Intel émulés, bien que la plupart de leurs développement est destinée à des machines basées ARM. En plus du nouvel émulateur, une mise à jour 64 bits de l’accélérateur HAXM devrait rendre l’utilisation de ce dernier encore plus attractive. Voici ce qu’a déclaré Intel :

« Cet engagement est évident. Non seulement dans le fait qu’il s’agit de la livraison industrielle de la première image d’un émulateur 64 bitss pour des architectures Intel, ainsi qu’Intel HAXM 64 bits avec le SDK Android L Developer Preview, mais également car il accompagne plusieurs autre innovations telles le premier noyau 64 bits pour Android Kitkat, le NDK 64 bits et plusieurs autres avancées en 64 bits tout au long de la décennie précédente. »

Se pourrait-il qu’un changement vers une architecture Intel pourrait faire partie d’un changement de la téléphonie 32 bits à la téléphone 64 bits?

Le SDK Android inclut un émulateur machine virtuelle dans votre ordinateur. L’émulateur vous permet de prototyper, développer et tester les applications Android sans utiliser une machine physique. L’émulateur Android mime toutes les fonctionnalités Software et Hardware d’un terminal mobile classique, sauf pour le cas des appels, où il est impossible d’effectuer des appels sous l’émulateur. L’émulateur met à disposition une variété d’actions de navigation et de clés de contrôles, actions déclenchées avec les souris ou les claviers pour générer des évènements pour l’application. Le SDK offre également une fenêtre d’émulation dans laquelle votre application est affichée, en parallèle avec d’autres applications.

Pour vous permettre de modéliser et de tester votre application plus facilement, l’émulateur utilise les configurations AVD. AVD vous permet de définir certains aspects matériels de votre téléphone émulé et vous permet de créer plusieurs configurations pour tester plusieurs plateformes Android et plusieurs permutations matériels. Dès l’exécution de vos applications sur l’émulateur, ce dernier peut utiliser les services de la plateforme Android pour invoquer d’autres applications, accéder au réseau, lire des fichiers audio et vidéo, sauvegarder et récupérer des données, notifier les utilisateurs et afficher un rendu pour les transitions graphiques et les thèmes.

Ressources et articles connexes:
  • Restez informer et télécharger Android NDK, Revision 10d ici.
  • Trouvez plus d’information sur Android Lollipop 5.0 ici.
  • En savoir plus sur le développement des applications Android KitKat* 4.4 en utilisant l’émulateur x86 ici.
A propos de l’auteur

Egor Filimonov travaille dans le groupe des logiciels et services chez Intel Corporation. Il est un étudiant à l’Université d’État de Lobatchevski à Nijni Novgorod, en Russie. Il est excellent en mécanique et en mathématiques. Ses spécialités sont les mathématiques et l’informatique appliquée. Son intérêt principal est HPC (High Performance Computing) et les technologies mobiles.

AUCUN COMMENTAIRE

LAISSER UN COMMENTAIRE

one × five =