Le titre est assez explicite: Android est-il un système d'exploitation 32 ou 64 bits? Je suppose que c’est l’un ou l’autre et non les deux, car cela obligerait les fichiers binaires 32 et 64 bits à être hébergés sur Google Play. Je sais que la question est simple et que d'autres personnes l'ont posée, mais je n'ai pas réussi à trouver de réponse sur le Web et il n'y en a certainement pas sur cette SE.

Dans le domaine des chipsets ARM, qui est le facteur commun, toute la pile Android, du noyau quasi identique basé sur Linux, est en fait 32 bits, compilée de manière croisée à partir d'un environnement hôte 32 bits / 64 bits, l'environnement hôte est généralement l'une des distributions de Linux. La distribution recommandée par Google pour la construction et la compilation croisée d'Android est Ubuntu .

La bibliothèque d'exécution d'Android (médias, graphiques, système de fichiers, pour n'en nommer que quelques-uns) est également en 32 bits, mais à mesure que nous atteignons la couche du dalvikvm, le nombre de bits devient alors inutile, comme c'est le cas à présent, les apks arrivant sur le Google Play Store sont des bytecodes natifs (un "sous-produit" de code Java généré compilé en un bytecode portable) qui cible la DalvikVM (machine virtuelle) qui interprète et traduit à son tour le bytecode visant le jeu d'instructions ARM brutes.

Froyo était le dernier Android à avoir permis la compilation dans un environnement hébergé de 32 bits dans lequel il était compilé de manière croisée en visant le chipset ARM.

Gingerbread était le premier du "futur" Android, il y a trois ans environ, qui imposait l'utilisation d'un environnement hébergé à 64 bits dans lequel il était construit. Il y avait beaucoup de choses à faire pour que Gingerbread soit construit dans un environnement hébergé 32 bits.

ICS et JB, et les versions ultérieures, requièrent désormais un environnement 64 bits pour accélérer la compilation et réduire les délais d'exécution.

Donc, pour résumer, ce que vous voyez sur le Play Store n'a pas d'incidence sur le fait d'utiliser 32 bits ou 64 bits et donc non pertinent.

Note latérale: Une distribution Linux typique de 16 Go de RAM / Quad core / 64 bits, le temps nécessaire à la création d'un ICS à partir de rien prend 30 minutes au maximum. Si cela avait été une distribution Linux 32 bits, cela aurait pris plus de temps, ce qui pourrait provoquer une panne du processeur. comme il n’ya tout simplement pas assez de puissance de traitement pour produire du code compilé, ce qui est un processus très exigeant et exigeant!

Preuve de cela.

Extrayez n'importe quel binaire ARM natif trouvé dans /system/binou /system/xbin, par exemple, /system/bin/dalvikvmc'est le binaire Dalvik VM qui est responsable des couches supérieures de Java et des APK.

Maintenant, examinez le binaire en lançant cette commande: file dalvikvmqui donne un résumé du type de fichier, la sortie attendue serait la suivante:

dalvikvm: exécutable ELB 32 bits ELF, ARM, version 1 (SYSV), lié de manière dynamique (utilise des bibliothèques partagées), supprimé

Notez la référence à ELF 32 bits et est compilée de manière croisée dans ARM. Il s'agit d'un exécutable binaire.

Passons à autre chose. Inspectons une bibliothèque partagée native trouvée dans /system/lib, par exemple, le /system/lib/libandroid_runtime.soproblème file libandroid_runtime.so, le résultat attendu serait le suivant:

libandroid_runtime.so: objet partagé ELB 32 bits ELF, ARM, version 1 (SYSV), lié de manière dynamique, supprimé

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

La clé de la compilation croisée de l' hôte se trouve dans la source de PSBA, à savoir, construire Gingerbread avait à l' origine une exigence d'être construit sur un système hôte 64 bits, voici le newsgroup linky se référant à comment patcher les scripts pour l' obtenir pour construire sur Hôte 32 bits qui possède deux correctifs, trouvés ici, pour build/core.mket build/main.mk( combinés ) dans l'examen Gerrit de l'AOSP.

Par la suite, ce correctif s’est retrouvé dans les scripts de compilation d’ICS, dans lesquels j’ai eu le privilège de compiler ICS sur une plate-forme 32 bits dont la construction a pris 3 jours ( c’était un port d’ICS pour le Zte Blade ). Maintenant, les exigences sont ont accéléré, vous ne certainement besoin d' hôte 64 bits pour permettre la compilation croisée de la construction PSBA à partir ICS vers le haut :)

À l'origine, Android était conçu pour les processeurs 32 bits uniquement: et plus précisément pour les processeurs ARM 32 bits. Ultérieurement, Intel et MIPS ont beaucoup investi pour que Android prenne également en charge leurs architectures: mais toujours des processeurs 32 bits. Ils ont pu le faire sans (beaucoup) problèmes de compatibilité, car la plupart des applications ne sont pas fournies sous forme de fichiers binaires. Écrit en Java, ils sont plutôt expédiés en tant que bytecode , qu'une machine virtuelle du téléphone compile dans l'architecture du téléphone lors de l'exécution de l'application. Certaines applications incluent natifcomposants, qui sont livrés en tant que binaire. Ceci est fait pour rendre certains types d'applications plus rapides (en particulier les jeux), ou pour permettre aux applications d'accéder aux bibliothèques C qui ne sont pas disponibles en Java. Ces applications peuvent inclure plusieurs binaires pour les parties de code natif, afin de leur permettre de s'exécuter sur différentes architectures. Même dans ce cas, la majorité des applications sont exclusivement Java, elles ne fonctionnent donc que sur toutes les architectures.

Ce qui précède était tout à fait vrai à l'époque où cette question (et la plupart des autres réponses) était écrite, mais plus maintenant. Lollipop a introduit le support pour les nouveaux processeurs ARM 64 bits ( ARMv8), ainsi que pour les processeurs x86_64 d’Intel et d’AMD, ce qui signifie qu’Android prend désormais en charge les processeurs 32 bits et 64 bits. Le Nexus 9 était le premier appareil Android 64 bits phare. En plus de donner accès à de nouvelles extensions de jeux d'instructions, la prise en charge 64 bits signifie que les applications peuvent utiliser plus de 4 Go de RAM. La plupart des applications n'en auront pas besoin autant, mais les jeux haut de gamme et les logiciels de création photo / vidéo peuvent certainement s'en servir: pousser Android à devenir une plate-forme pour les jeux de qualité console (y compris les jeux de réalité virtuelle) et pour la création de contenu. Les applications Java n'ont pas besoin d'être mises à jour pour tirer parti de cette situation, car la machine virtuelle les compile toujours selon l'architecture du téléphone, contrairement aux applications avec code natif.

ARMv8 étant rétrocompatible avec le code 32 bits (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 s'exécuter sur Android 64 bits. Ainsi, une application doit uniquement être compilée pour 64 bits si elle contient du code natif et si elle souhaite tirer parti de la limite de RAM supérieure ou des nouvelles fonctionnalités de l'architecture.

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

Les processeurs 64 bits devraient être lancés en 2014 .

Android est-il un système d'exploitation 32 ou 64 bits? Je suppose que c’est l’un ou l’autre et non les deux, car cela obligerait les fichiers binaires 32 et 64 bits à être hébergés sur Google Play.

Ni réellement. Android est un système d'exploitation basé sur une machine virtuelle Dalvik et Google Play héberge les applications Dalvik. La machine virtuelle Dalvik, comme la machine virtuelle Java, est toujours en 32 bits, quelle que soit la qualité de bits de la machine physique.

Comme vous le supposiez, les applications livrées avec des fichiers binaires natifs et les applications NDK doivent être livrées avec des fichiers binaires compilés pour chaque architecture sur laquelle il est destiné à être exécuté. L'architecture la plus courante sur laquelle Android s'exécute est ARM 32 bits. Cependant, il existe également des périphériques fonctionnant sous x86 et MIPS.

Je ne fais que deviner, mais je pense que cela explique aussi que c'est simple. Cela dépend de l'appareil que vous utilisez, il y a quatre types d'OS qui sont ARM, ARM 64, X84 et X84_64. ARM 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, son inhabituel et utilisé sur les émulateurs Android. J'ai cette information os sur Open Gapps