Dans le domaine des chipsets ARM qui est le facteur commun, toute la pile Android, issue du noyau presque identique basé sur Linux, sont en fait, 32 bits, compilés de manière croisée à partir dun environnement hôte 32 bits / 64 bits, lenvironnement hôte étant généralement lune des distributions de Linux. La distribution recommandée, par Google, pour la construction et la compilation croisée dAndroid est Ubuntu .

La bibliothèque dexécution dAndroid (médias, graphiques, système de fichiers, pour nen citer que quelques-uns) est également 32 bits, mais lorsque nous atteignons la couche du dalvikvm, alors le nombre de bits devient sans importance car à ce stade, les apks provenant du Google Play Store sont du bytecode natif (un « sous-produit » du code Java généré compilé en un bytecode portable) qui cible la DalvikVM (Virtual Machine) qui à son tour interprète et traduit le bytecode ciblant le jeu dinstructions ARM brut.

Froyo était le dernier Android qui a permis la compilation sous un environnement hébergé 32 bits dans lequel il a été compilé de manière croisée pour cibler le chipset ARM.

Gingerbread était le premier du « futur » Android, à lépoque environ, il y a trois ans, qui a introduit lobligation dutiliser un environnement hébergé 64 bits dans lequel il a été construit . Il y a eu de nombreux hacks pour que Gingerbread soit construit dans un environnement hébergé 32 bits.

ICS et JB, et les versions supérieures, nécessitent désormais un environnement 64 bits pour accélérer la compilation et réduire le temps de traitement lors de la construction.

Donc, pour résumer, ce que vous voyez sur le Play Store na aucune incidence sur le fait que 32 bits ou 64 bits sont utilisés et donc non pertinents.

Note latérale: 16 Go de RAM / Distribution Linux Quad core / 64 bits, le temps quil faut pour construire ICS à partir de zéro, prend 30 minutes maximum, sil sagissait dune distribution Linux 32 bits, cela aurait pris plus de temps, en fait, peut provoquer une fusion du processeur car il ny a tout simplement pas assez puissance de traitement pour générer et générer du code compilé de manière croisée, ce qui est un processus très exigeant et éprouvant!

Preuve de cela.

Récupère tout binaire ARM natif trouvé dans /system/bin ou /system/xbin , par exemple, /system/bin/dalvikvm, cest le binaire de la VM Dalvik qui est responsable des couches supérieures de Java et des APK.

Maintenant, examinez le binaire en émettant ceci commande: file dalvikvm qui donne un résumé du type de fichier dont il sagit, la sortie attendue serait la suivante:

dalvikvm: exécutable ELF 32 bits LSB, ARM, version 1 (SYSV), lié dynamiquement (utilise des bibliothèques partagées), supprimé

Notez la référence à lELF 32 bits, et est compilé de manière croisée avec ARM et est un exécutable binaire.

À droite, continuons, inspectons une bibliothèque partagée native trouvée dans /system/lib, par exemple, /system/lib/libandroid_runtime.so, maintenant publiée file libandroid_runtime.so, la sortie attendue serait la suivante:

libandroid_runtime.so: objet partagé ELF 32 bits LSB, ARM, version 1 (SYSV), lié dynamiquement, supprimé

Encore une fois, remarquez, son ELF 32 bits, compilé de manière croisée en ARM et est une bibliothèque partagée.

La clé de la compilation croisée de lhôte peut être trouvée dans la source AOSP, cest-à-dire que la construction de Gingerbread devait à lorigine être construite sur un système hôte 64 bits, voici le newsgroup linky faisant référence à comment patcher les scripts pour le faire construire sur un hôte 32 bits qui a deux correctifs, trouvés ici, pour build/core.mk et build/main.mk ( combinés ) sur la revue Gerrit dAOSP.

En tant que version ultérieure résultat, ce patch avait fait son chemin vers les scripts de construction dICS dans lesquels javais le privilège de compiler ICS sur une plate-forme 32 bits qui prenait 3 jours à construire ( cétait un port dICS pour le Zte Blade ). Maintenant, les exigences sont augmentées, vous do avez certainement besoin dun hôte 64 bits pour permettre la compilation croisée de la construction dAOSP à partir dICS: )

Commentaires

• Donc, vous voulez dire que la compilation et lexécution dun système dexploitation Android 32 bits prend plus de temps que 64 bits? Est-il obligatoire dêtre entièrement 64 bits pour les systèmes dexploitation Android modernes tels que Kitkat ou L ?
• Il existe désormais des appareils ARM 64 bits exécutant Android 64 bits.
• Je ‘ vote défavorable car la plupart des réponses concernent les environnements utilisés pour compiler Android, ce qui n’est absolument pas pertinent pour le question.
• @DanHulme Cette réponse a été postée il y a près de 4 ans … oui, le paysage a beaucoup changé depuis. 🙂
• Oui, cette ‘ est vraie, et je ‘ vais publier une nouvelle réponse sur le situation actuelle, mais lenvironnement de compilation a toujours été un hareng rouge.

À lorigine, Android a été écrit pour les processeurs 32 bits uniquement: et plus particulièrement les processeurs ARM 32 bits. Plus tard, Intel et MIPS ont beaucoup investi pour que Android prenne également en charge leurs architectures: mais toujours seulement des processeurs 32 bits. Ils ont pu le faire sans (nombreux) problèmes de compatibilité, car la plupart des applications ne sont pas livrées sous forme de fichiers binaires. Écrites en Java, elles sont à la place livrées sous forme de bytecode , qui est une machine virtuelle sur le téléphone se compile à larchitecture du téléphone lorsque lapplication est exécutée. Certaines applications incluent des composants natifs , qui sont livrés sous forme de binaire. Ceci est fait pour rendre certains types dapplications plus rapides (en particulier les jeux) ou pour permettre à lapplication daccéder à des bibliothèques C qui ne sont pas disponibles en Java. Ces applications peuvent inclure plusieurs binaires pour les parties de code natives, pour leur permettre de sexécuter sur différentes architectures. Néanmoins, la majorité des applications sont uniquement Java, donc elles ne fonctionnent que sur nimporte quelle architecture.

Tout cela était vrai à lépoque où cette question (et la plupart des autres réponses) était écrit, mais plus. Lollipop a introduit la prise en charge des nouveaux processeurs ARM 64 bits ( ARMv8 ) ainsi que des processeurs x86_64 dIntel et dAMD, ce qui signifie quAndroid prend désormais en charge les processeurs 32 bits et Processeurs 64 bits. Le Nexus 9 a été le premier appareil Android 64 bits phare. En plus de donner accès à de nouvelles extensions de jeu dinstructions, la prise en charge 64 bits signifie que les applications peuvent utiliser plus de 4 Go de RAM. La plupart des applications nen auront pas besoin, mais les jeux haut de gamme et les logiciels de création de photos / vidéos peuvent certainement en profiter: faire dAndroid une plate-forme pour les jeux de qualité console (y compris les jeux VR) et pour créer du contenu. Applications Java Vous navez pas besoin dêtre mis à jour pour en profiter, car la machine virtuelle les compile toujours selon larchitecture du téléphone, mais les applications avec du code natif le seront.

Parce que ARMv8 est rétrocompatible avec 32- code bit (de la même manière que x86_64 peut toujours exécuter du code x86), même les applications qui incluent du code natif pour les processeurs 32 bits peuvent toujours sexécuter sur Android 64 bits. Ainsi, une application ne doit être compilée pour 64 bits que si elle contient du code natif code et il souhaite profiter de la limite de RAM plus élevée ou des nouvelles fonctionnalités de larchitecture.

Toutes les puces ARM sont actuellement 32 bits. Pour cette raison, Android exécute actuellement tout le code dans un environnement 32 bits.

Processeurs 64 bits devraient être lancés en 2014 .

Commentaires

• Ce ‘ nest pas exactement une source fiable car il sagissait de serveurs, pour citer  » Le smartphone est un peu plus éloigné « , a déclaré Forsyth. , nous ‘ parlons dARM dans le contexte dAndroid / Smartphones / Tablettes.

Android est-il un système dexploitation 32 ou 64 bits? Je suppose que cest lun ou lautre et non les deux, car cela forcerait les binaires 32 et 64 bits à être hébergés sur Google Play.

Ni en fait. Android est un système dexploitation basé sur une VM Dalvik et Google Play héberge des applications Dalvik. La machine virtuelle Dalvik elle-même, comme la machine virtuelle Java, est toujours 32 bits quel que soit le bitness de la machine physique.

Comme vous le soupçonniez, les applications livrées avec des binaires natifs et des applications NDK doivent être livrées avec des binaires compilés pour toutes les architectures il est destiné à fonctionner à. Larchitecture la plus courante sur laquelle tourne Android est ARM 32 bits; cependant il y a aussi des appareils qui fonctionnent sur x86 et MIPS.

Je ne fais que deviner mais je pense que cela lexplique aussi juste Facile. Cela dépend de lappareil que vous utilisez, il y a quatre types dos qui sont ARM, ARM 64, X84 et X84_64. LARM est la plate-forme 32 bits populaire, ARM 64 est également la plate-forme populaire mais 64 bits, X84 est la plate-forme peu commune et utilisée sur Zenfones, tout comme X84_64, elle est rare et utilisée sur les émulateurs Android. Jai obtenu ces informations sur Open Gapps