Un appareil matériel 64 bits peut-il faire fonctionner une version 32 bits d'Android ?

Ce n'est pas clairement mentionné mais je suppose que vous parlez de l'architecture ARM. "Android 32-bit OS" signifie un noyau 32 bits et la collection de binaires et de bibliothèques ELF qui sont compilés pour fonctionner sur un processeur 32 bits. Cette pile d'intergiciels comprend notamment app_process binaire qui s'exécute avec le nom zygote et héberge le cadre applicatif complet d'Android. Il forge des machines virtuelles Java (pour chaque application) dans lesquelles Dalvik EXecutable ( .dex ) s'exécute un code qui n'est ni 32 ni 64 bits. Mais les JVM sont des processus natifs, 32 ou 64 bits, selon les bibliothèques JNI que l'application contient.

Nous pouvons exécuter un système d'exploitation 32 bits sur un appareil 64 bits s'il est 64 bits :

1. Le processeur prend en charge l'exécution de code 32 bits, ce qui est généralement le cas car la rétrocompatibilité est souhaitée, mais pas toujours.

2. Le noyau prend en charge l'exécution de code 32 bits car, contrairement aux hyperviseurs "bare-metal", nous - les processus d'Android - ne traitons pas directement avec le matériel.

BITNESS DU PROCESSEUR

La prise en charge de l'exécution 32 bits par tous les processeurs 64 bits n'est pas universelle. Par exemple, les SoCs Samsumg Exynos 9 Series 982x contiennent Cortex-A55 et A75 qui (sont basés sur ARMv8.x et ils) ont le support pour aarch64 y aarch32 . D'autre part, l'entreprise Qualcomm Centriq 2400 SoCs et de Cavium Tonnerre X2 Les SoC comprennent également des processeurs ARMv8.x, mais sans les éléments suivants aarch32 soutien.

Afin de trouver l'architecture du dispositif, nous pouvons lire /proc/cpuinfo dont expose des informations provenant de Registre d'identification principal du processeur.

~$ cat /proc/cpuinfo
...
CPU implementer : 0x41
CPU architecture: 8
...
CPU part        : 0xd03
...
Hardware        : Qualcomm Technologies, Inc MSM8953

Mais il n'y a pas d'information directe comme lm pour confirmer le support 32/64 bits. Nous devons donc obtenir les détails techniques du matériel. Selon le exigences de Google, CPU architecture: 8 indique qu'il s'agit d'un ARMv8 dispositif. Voir aussi cet engagement . Et aquí est la carte de décodage de l'hexagone vers l'humain qui lscpu utilise.

~$ lscpu | grep -E 'Vendor |Model '
Vendor ID:           ARM
Model name:          Cortex-A53

Autres moyens possibles d'obtenir des informations sur le SoC :

~$ cat /sys/firmware/devicetree/base/model
Qualcomm Technologies, Inc. MSM8953 + PMI8950 QRD SKU3

~$ cat /sys/devices/soc0/{vendor,family,machine}
Qualcomm
Snapdragon
MSM8953

Les spécifications techniques du Snapdragon 625 de Qualcomm ( MSM 8953 ) et Cortex-53 qu'il est basé sur l'architecture ARMv8, qui peut traiter les deux jeux d'instructions : aarch64 y aarch32 .

LE BITNESS DU NOYAU

Lorsque arm64 le soutien était ajouté au noyau Linux, le mode de compatibilité 32 bits a également été inclus. Si le noyau est construit avec IKCONFIG_PROC , confirmé par :

~# zcat /proc/config.gz | grep -E 'CONFIG_ARM64=|CONFIG_COMPAT=|BINFMT'
CONFIG_ARM64=y
CONFIG_COMPAT=y
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y

Ainsi les fichiers ELF 64 bits sont exécutés nativement avec binfmt_elf tandis que les fichiers ELF 32 bits sont exécutés avec compat_binfmt_elf . Voir les détails dans cette réponse.) .

Habituellement uname -m est utilisé pour trouver l'architecture du périphérique supporté par le noyau. Il montre la persoanlité ( domaine d'exécution ) du processus qui prend par défaut l'architecture primaire du noyau ( PER_LINUX ). Mais le noyau Linux prend en charge la modification persoanlité Cette approche peut donc prêter à confusion :

~$ uname -m
aarch64
~$ setarch linux32 uname -m
armv8l

Dans cette dernière commande uname est exécuté sous 32 bits personnalité compatible . La même chose se produirait si vous utilisiez une application, par exemple este - qui exécute con LINUX32 personnalité, peu importe même si le noyau et le uname Les binaires sont 64 bits. Pour plus de détails, voir este y este . lscpu confirme également les modes de fonctionnement du CPU en utilisant le même phénomène.

CODE D'UTILISATION BITNESS

Venons-en maintenant à l'espace utilisateur, init est le tout premier processus exécuté par le noyau. Vérifions son bitness. Si le 5ème octet est 1, c'est un fichier ELF 32 bits, si c'est 2, le binaire est 64 bits :

~# hexdump -n5 /proc/1/exe
0000000 457f 464c 0002

Ou utilisez file commandement :

~# file /proc/1/exe
/proc/1/exe: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked ...

De même, vérifiez le bitness des autres binaires/bibliothèques vitales du système d'exploitation :

~$ file /system/lib*/libc.so
/system/lib/libc.so:   ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked ...
/system/lib64/libc.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked ...

~$ file /system/bin/linker*
/system/bin/linker:        ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked ...
/system/bin/linker64:      ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked ...

Le système d'exploitation maintient les bibliothèques et l'éditeur de liens dynamiques 64 bits et 32 bits, car les applications peuvent contenir les deux types de code binaire (même si la majeure partie doit être du bytecode Java/Dalvik). Par exemple, la bibliothèque dnsmasq qui sert de serveur DHCP sur le hotspot est un binaire 64 bits alors que Google Play Services utilise une bibliothèque 32 bits :

~# readelf -a /system/bin/dnsmasq
  Class:                             ELF64
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
      [Requesting program interpreter: /system/bin/linker64]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]

~# readelf -a /data/data/com.google.android.gms/app_vision/ocr/libs/armeabi-v7a/libocr.so
  Class:                             ELF32
  Type:                              DYN (Shared object file)
  Machine:                           ARM
      [Requesting program interpreter: /system/bin/linker]
 0x00000001 (NEEDED)                     Shared library: [libc.so]

De même, il n'est pas rare d'avoir des blobs binaires 32 bits provenant d'OEM ou de fournisseurs de SoC sur des ROM 64 bits. Même certains composants de base de l'AOSP ne sont pas supportés en 64 bits. Prenez l'exemple de audioserver .
Pour voir tous les processus s'exécutant en mode 32 bits :

~# for p in $(ps -p 2 --ppid 2 --deselect -o pid=); do grep -qE '^.{8}[^-]' /proc/$p/maps || echo $p; done | xargs ps f -o pid,cmd -p
  PID CMD
 3359 /system/bin/mediaserver
 3358 /system/bin/cameraserver
 3357 /system/bin/audioserver
 3356 zygote
 5081  \_ webview_zygote
20824  |   \_ com.android.webview:sandboxed_process0
18609  \_ it.colucciweb.vpnclient
 3354 /vendor/bin/hw/android.hardware.audio@2.0-service
 2665 /vendor/bin/hw/android.hardware.camera.provider@2.4-service
 2335 /vendor/bin/mm-qcamera-daemon
 2278 /vendor/bin/wifidisplayhalservice
 2277 media.codec hw/android.hardware.media.omx@1.0-service
 2244 /system/bin/drmserver
  777 /vendor/bin/hw/android.hardware.drm@1.1-service.widevine
  773 /vendor/bin/hw/android.hardware.cas@1.0-service

Parmi ceux-ci, un seul est une application VPN, les autres sont des processus du système d'exploitation.

CONCLUSION

Il est donc clair que même si le système d'exploitation principal est 64 bits, il est possible qu'un grand nombre de processus s'exécutent en 32 bits, bien que chaque processus et ses bibliothèques liées doivent être homogènes ; soit 32, soit 64 bits. Et il n'y a aucune contrainte si le système d'exploitation n'inclut pas du tout de code 64 bits, mais vous ne trouverez pas beaucoup de cas parce que les OEM livrent des appareils 64 bits avec du code binaire 64 bits. Il s'agit plus d'une question d'affaires que de performances ; c'est pour cela que l'utilisateur paie. Cependant, il existe des exceptions où l'aspect commercial n'est pas si important : Le Raspberry Pi 3 a un processeur 64 bits, mais un système d'exploitation Raspbian 32 bits . Les exemples de téléphones Android du passé comprennent le Galaxy E5, le LG G Stylo, le Moto G5 Plus, le Lenovo A6000 Plus et les appareils MT6735. Mais aujourd'hui, Android est déménagement vers le 64 bits et certains appareils peuvent tomber Prise en charge progressive du 32 bits.

Le même cas se produit-il pour Android ? Existe-t-il une version 32 bits et une version 64 bits pour le même appareil 64 bits ?

Oui, prenez l'exemple de Moto G4 Plus .

RELATION : Applications Android pour l'architecture "armeabi-v7a" et "x86" : SoC vs. processeur vs. ABI

La réponse est oui. Vous pouvez faire fonctionner Android 32 bits sur des chipsets 64 bits sans trop de problèmes. Mais la version que vous utilisez n'a pas vraiment d'importance car, à l'heure actuelle, 90 % des applications disponibles sont en 32 bits et n'utilisent pas le matériel en 64 bits.

Oui, vous pouvez. En fait, certains des premiers appareils faisaient exactement ça. C'est similaire à ce que nous avons dans le domaine de l'informatique de bureau. Le Moto E2 est un exemple de processeur 64 bits exécutant un système d'exploitation 32 bits.