Il titolo è praticamente autoesplicativo: Android è un sistema operativo a 32 o 64 bit? Suppongo che sia l'uno o l'altro e non entrambi, poiché ciò costringerebbe i binari a 32 e 64 bit a essere ospitati su Google Play. So che questa è una domanda semplice, e che altre persone l'hanno posta, ma per la mia vita non sono stato in grado di trovare una risposta sul web, e sicuramente non ce n'è una su questa SE.

Nel regno dei chipset ARM, che è il fattore comune, l'intero stack Android, dal kernel quasi identico basato su Linux, è in realtà 32 bit, cross-compilato di solito da un ambiente host a 32 bit / 64 bit, l'ambiente host di solito è una delle distribuzioni di Linux. La distribuzione consigliata, da parte di Google, per la creazione e la compilazione incrociata di Android è Ubuntu .

La libreria di runtime di Android (media, grafica, filesystem, per citarne solo alcuni) ha anche 32 bit, ma quando raggiungiamo il livello di dalvikvm, il numero di bit diventa irrilevante com'è a questo punto, gli apk arrivano dal Google Play Store sono bytecode nativi (un "sottoprodotto" del codice Java generato compilato in un bytecode portatile) che ha come target il DalvikVM (Virtual Machine) che a sua volta interpreta e traduce il bytecode indirizzato al set di istruzioni ARM non elaborato.

Froyo è stato l'ultimo Android a consentire la compilazione in un ambiente ospitato a 32 bit in cui è stato compilato in modo incrociato per il chipset ARM.

Gingerbread è stato il primo del "futuro" Android, all'epoca circa, tre anni fa, a introdurre un requisito per l'utilizzo di un ambiente ospitato a 64 bit in cui era stato costruito. Ci sono stati molti hack per far costruire Gingerbread in un ambiente ospitato a 32 bit.

ICS e JB, e verso l'alto, ora richiedono sicuramente un ambiente a 64 bit per accelerare la compilazione e ridurre i tempi di risposta nella costruzione.

Quindi, per riassumere, ciò che vedi sul Play Store non ha alcuna influenza sul fatto che vengano utilizzati 32 bit o 64 bit e quindi irrilevanti.

Nota a margine: tipica distribuzione Linux da 16 GB RAM / Quad core / 64 bit, il tempo necessario per creare l'ICS da zero, impiega massimo 30 minuti, se si trattasse di una distribuzione Linux a 32 bit, ci sarebbe voluto più tempo, infatti, potrebbe causare un crollo della CPU in quanto non esiste semplicemente una potenza di elaborazione sufficiente per sfornare e far girare codice compilato, che è un processo molto impegnativo e faticoso!

Prova di ciò.

Inserisci qualsiasi binario ARM nativo trovato in /system/bino /system/xbin, ad esempio, /system/bin/dalvikvmquesto è il binario VM Dalvik che è responsabile dei livelli superiori di Java e APK.

Ora, esamina il binario emettendo questo comando: file dalvikvmche fornisce un riepilogo del tipo di file che è, l'output previsto sarebbe questo:

dalvikvm: eseguibile ELB LSB a 32 bit, ARM, versione 1 (SYSV), collegato dinamicamente (usa librerie condivise), rimosso

Notare il riferimento a ELF a 32 bit, compilato in modo incrociato con ARM ed è un eseguibile binario.

Bene, andando avanti, ispezioniamo una libreria condivisa nativa trovata /system/lib, ad esempio /system/lib/libandroid_runtime.so, ora in file libandroid_runtime.souscita, l'output previsto sarebbe questo:

libandroid_runtime.so: oggetto ELF LSB a 32 bit condiviso, ARM, versione 1 (SYSV), collegato dinamicamente, rimosso

Ancora una volta, notate, il suo ELF a 32 bit, compilato in modo incrociato per ARM ed è una libreria condivisa.

La chiave per la cross-compilazione del padrone di casa può essere trovato nella sorgente AOSP, cioè, di pan di zenzero costruzione ha avuto origine l'obbligo di essere costruita su un sistema host a 64 bit, ecco il newsgroup linky riferendosi a come correggere gli script per farlo costruire su Host a 32 bit che ha due patch, trovate qui, per build/core.mke build/main.mk( combinate ) sulla recensione Gerrit di AOSP.

Di conseguenza, questa patch si è fatta strada verso gli script di build di ICS in cui avevo il privilegio di compilare ICS su una piattaforma a 32 bit che impiegava 3 giorni per essere costruito ( era una porta di ICS per Zte Blade ). Ora, i requisiti sono dilagato, si fanno sicuramente bisogno di accoglienza a 64 bit per consentire cross-compilazione di costruzione AOSP da ICS verso l'alto :)

Inizialmente, Android era scritto solo per processori a 32 bit: e in particolare, processori ARM a 32 bit. Successivamente, Intel e MIPS hanno investito molto nel far sì che Android supportasse anche le loro architetture: ma ancora solo processori a 32 bit. Sono stati in grado di farlo senza (molti) problemi di compatibilità, poiché la maggior parte delle app non viene distribuita come binaria. Scritti in Java, vengono invece spediti come bytecode , che una macchina virtuale sul telefono compila all'architettura del telefono quando l'app viene eseguita. Alcune app includono nativecomponenti, che vengono spediti come binari. Questo viene fatto per rendere più veloci alcuni tipi di app (in particolare i giochi) o per consentire all'app di accedere alle librerie C che non sono disponibili in Java. Tali app possono includere più di un file binario per le parti di codice native, per consentire l'esecuzione su architetture diverse. Anche così, la maggior parte delle app sono solo Java, quindi funzionano solo su qualsiasi architettura.

Quanto sopra era tutto vero al momento in cui questa domanda (e la maggior parte delle altre risposte) è stata scritta, ma non più. Lollipop ha introdotto il supporto per i nuovi processori ARM a 64 bit ( ARMv8) nonché per i processori x86_64 di Intel e AMD, il che significa che Android ora supporta processori sia a 32 che a 64 bit. Il Nexus 9 è stato il primo dispositivo Android a 64 bit di punta. Oltre a consentire l'accesso a nuove estensioni del set di istruzioni, il supporto a 64 bit significa che le app possono utilizzare più di 4 GB di RAM. La maggior parte delle app non avrà bisogno di così tanto, ma i giochi di fascia alta e il software di creazione di foto / video possono sicuramente farne uso: spingere Android verso una piattaforma per giochi di qualità console (inclusi i giochi VR) e per creare contenuti. Non è necessario aggiornare le app Java per trarne vantaggio, perché la macchina virtuale le compila sempre nell'architettura del telefono, ma le app con codice nativo lo faranno.

Poiché ARMv8 è retrocompatibile con il codice a 32 bit (allo stesso modo in cui x86_64 può ancora eseguire codice x86), anche le app che includono codice nativo per processori a 32 bit possono comunque essere eseguite su Android a 64 bit. Pertanto, un'app deve essere compilata per 64 bit solo se contiene codice nativo e desidera sfruttare il limite RAM più elevato o le nuove funzionalità dell'architettura.

Tutti i chip ARM sono attualmente a 32 bit. Per questo motivo, Android attualmente esegue tutto il codice in un ambiente a 32 bit.

I processori a 64 bit verranno lanciati nel 2014 .

Android è un sistema operativo a 32 o 64 bit? Suppongo che sia l'uno o l'altro e non entrambi, poiché ciò costringerebbe i binari a 32 e 64 bit a essere ospitati su Google Play.

Nemmeno in realtà. Android è un sistema operativo basato su VM Dalvik e Google Play ospita applicazioni Dalvik. La stessa VM Dalvik, come Java VM, è sempre a 32 bit indipendentemente dal testimone della macchina fisica.

Come sospettavi, le applicazioni fornite con file binari nativi e applicazioni NDK devono essere fornite con file binari compilati per tutte le architetture per le quali è prevista l'esecuzione. L'architettura più comune su cui gira Android è ARM 32-bit; tuttavia ci sono anche dispositivi che funzionano su x86 e MIPS.

Sto solo indovinando, ma penso che questo spieghi anche semplicemente. Dipende dal dispositivo che stai utilizzando, ci sono quattro tipi di sistemi operativi che sono ARM, ARM 64, X84 e X84_64. ARM è la popolare piattaforma a 32 bit, ARM 64 è anche la piattaforma popolare ma a 64 bit, X84 è la piattaforma non comune e utilizzata su Zenfones, come X84_64 è rara e utilizzata su emulatori Android. Ho ricevuto queste informazioni sul sistema operativo su Open Gapps