În domeniul chipseturilor ARM care este factorul comun, întregul stack Android, din nucleul aproape identic bazat pe Linux, sunt, de fapt, pe 32 de biți, compilați încrucișat de obicei dintr-un mediu gazdă de 32 biți / 64 biți, mediul gazdă fiind de obicei una dintre distribuțiile Linux. Distribuția recomandată, de către Google, pentru construirea și compilarea încrucișată a Androidului este Ubuntu .

Biblioteca de rulare Android (media, grafică, sistem de fișiere, pentru a numi doar câteva) sunt de asemenea, pe 32 de biți, dar pe măsură ce ajungem la stratul dalvikvm, atunci numărul de biți devine irelevant, așa cum este în acest moment, apk-urile care vin din Magazinul Google Play sunt coduri secundare native (un „produs secundar” al codului Java generat compilat într-un bytecode portabil) care vizează DalvikVM (mașină virtuală) care la rândul său interpretează și traduce codul de bytec care vizează setul de instrucțiuni ARM brut.

Froyo a fost ultimul Android care a permis compilarea într-un mediu găzduit pe 32 de biți în care a fost compilat încrucișat, vizând chipset-ul ARM.

Gingerbread a fost primul „viitor” Android, pe atunci în urmă, în urmă cu trei ani, care a introdus cerința de a utiliza un mediu găzduit pe 64 de biți în care a fost construit . Au existat multe hack-uri pentru ca Gingerbread să fie construit în mediu găzduit pe 32 de biți.

ICS și JB, și în sus, acum necesită cu siguranță un mediu pe 64 de biți pentru a accelera compilarea și pentru a reduce timpul de schimb în clădire.

Deci, pentru a rezuma, ceea ce vedeți în Magazin Play nu are nicio influență asupra utilizării 32bit sau 64bit și, prin urmare, irelevante.

Notă laterală: RAM tipică de 16 GB / Distribuția Linux cu patru nuclee / 64 de biți, timpul necesar pentru a construi ICS de la zero, durează maxim 30 de minute, dacă aceasta ar fi o distribuție Linux pe 32 de biți, ar fi durat mai mult, de fapt, ar putea cauza o topire a procesorului, deoarece este pur și simplu, nu suficient puterea de procesare pentru a produce și scoate codul încrucișat, care este un proces foarte solicitant și impozitant!

Dovadă.

Trageți orice binar ARM nativ găsit în /system/bin sau /system/xbin , de exemplu, /system/bin/dalvikvm, acesta este binarul Dalvik VM care este responsabil pentru straturile superioare ale Java și APK-urilor.

Acum, examinați binele prin emiterea acestui comanda: file dalvikvm care oferă un rezumat al tipului de fișier care este, ieșirea așteptată ar fi aceasta:

dalvikvm: executabil ELS pe 32 de biți LSB, ARM, versiunea 1 (SYSV), legat dinamic (utilizează lib-uri partajate), dezbrăcat

Observați referința la ELF pe 32 de biți și este compilat încrucișat la ARM și este un executabil binar.

Dreapta, continuând, să inspectăm o bibliotecă partajată nativă găsită în /system/lib, de exemplu, /system/lib/libandroid_runtime.so, emite acum file libandroid_runtime.so, ieșirea așteptată ar fi aceasta:

libandroid_runtime.so: obiect partajat ELS pe 32 de biți LSB, ARM, versiunea 1 (SYSV), conectat dinamic, dezactivat

Din nou, observați, ELF pe 32 de biți, compilat încrucișat în ARM și este o bibliotecă partajată.

Cheia pentru compilația încrucișată a gazdei poate fi găsită în sursa AOSP, adică, versiunea Gingerbread avea inițial cerința de a fi construită pe un sistem gazdă pe 64 de biți, aici este grupul de știri linky referindu-se la cum să corecteți scripturile pentru a-l construi pe gazda de 32 biți care are două patch-uri, găsite aici, pentru build/core.mk și build/main.mk ( combinat ) în recenzia Gerrit de la AOSP.

rezultatul, acest patch sa îndreptat spre scripturile de construire ale ICS, în care am avut privilegiul de a compila ICS pe o platformă pe 32 de biți, care a durat 3 zile până la construire ( a fost un port al ICS pentru Zte Blade ). Acum, cerințele sunt crescute, faceți cu siguranță aveți nevoie de gazdă pe 64 de biți pentru a permite compilarea încrucișată a clădirii AOSP de la ICS în sus: )

Comentarii

• Deci, vrei să spui că compilarea și rularea unui sistem de operare Android pe 32 de biți durează mai lent decât în 64 de biți? Este o cerință generală să fie toate pe 64 de biți pentru sistemul de operare Android modern, cum ar fi Kitkat sau L ?
• Acum există dispozitive ARM pe 64 de biți rulează Android pe 64 de biți.
• Am ‘ negativ, deoarece majoritatea răspunsului se referă la ce medii sunt utilizate pentru compila Android, ceea ce este complet irelevant pentru întrebare.
• @DanHulme Acest răspuns a fost postat acum aproape 4 ani … da, peisajul s-a schimbat foarte mult de atunci. 🙂
• Da, ‘ este adevărat și voi ‘ voi posta un răspuns nou despre situația de astăzi, dar mediul de compilare a fost întotdeauna un hering roșu.

Inițial, Android a fost scris numai pentru procesoare pe 32 de biți: și în mod special, procesoare ARM pe 32 de biți. Mai târziu, Intel și MIPS au investit mult în a face ca Android să își sprijine și arhitecturile: dar totuși doar procesoare pe 32 de biți. Au reușit să facă acest lucru fără (multe) probleme de compatibilitate, deoarece majoritatea aplicațiilor nu sunt livrate ca binare. Scrise în Java, ele sunt livrate în schimb ca bytecode , care este o mașină virtuală pe telefon se compilează cu arhitectura telefonului atunci când aplicația este rulată. Unele aplicații includ componente native , care sunt livrate ca binare. Acest lucru se face pentru a face unele tipuri de aplicații mai rapide (în special jocuri) sau pentru a permite aplicației să acceseze bibliotecile C care nu sunt disponibile în Java. Aceste aplicații pot include mai multe binare pentru părțile de cod native, pentru a le permite să ruleze pe diferite arhitecturi. Chiar și așa, majoritatea aplicațiilor sunt numai Java, deci funcționează doar pe orice arhitectură.

Cele de mai sus erau adevărate în momentul în care această întrebare (și majoritatea celorlalte răspunsuri) era scris, dar nu mai este. Lollipop a introdus suport pentru noile procesoare ARM pe 64 de biți ( ARMv8 ), precum și pentru procesoarele x86_64 Intel și AMD, ceea ce înseamnă că Android acceptă acum atât pe 32 de biți, cât și pe Procesoare pe 64 de biți. Nexus 9 a fost primul dispozitiv Android pe 64 de biți. Pe lângă faptul că oferă acces la noi extensii de seturi de instrucțiuni, suportul pe 64 de biți înseamnă că aplicațiile pot utiliza mai mult de 4 GB RAM. Majoritatea aplicațiilor nu au nevoie de atât de mult, dar jocurile de ultimă generație și software-ul de creare de fotografii / video pot folosi cu siguranță: împingerea Android către a fi o platformă pentru jocuri de calitate pentru consolă (inclusiv jocuri VR) și pentru crearea de conținut. Aplicații Java Nu trebuie să fiți actualizat pentru a profita de acest lucru, deoarece mașina virtuală le compilează întotdeauna în arhitectura telefonului, dar aplicațiile cu cod nativ o vor face.

Deoarece ARMv8 este compatibil cu 32- cod de biți (în același mod în care x86_64 poate rula în continuare codul x86), chiar și aplicațiile care includ cod nativ pentru procesoare pe 32 de biți pot rula în continuare pe Android pe 64 de biți. Prin urmare, o aplicație trebuie să fie compilată doar pentru 64 de biți dacă conține conținut nativ cod și vrea să profite de limita RAM mai mare sau de noile caracteristici ale arhitecturii.

Toate cipurile ARM sunt în prezent pe 32 de biți. Din această cauză, Android execută în prezent tot codul într-un mediu pe 32 de biți.

Procesoare pe 64 de biți setate să fie lansate în 2014 .

Comentarii

• Că ‘ nu este tocmai o sursă de încredere, deoarece se vorbea despre servere, pentru a cita „ Smartphone-ul este puțin mai departe ”, a spus Forsyth. , ‘ vorbim despre ARM în contextul Android / Smartphone-uri / Tablete.

Este Android un sistem de operare pe 32 sau 64 de biți? Presupun că este unul sau altul și nu ambele, întrucât acest lucru ar obliga forțele binare de 32 și 64 de biți să fie găzduite pe Google Play.

Nici de fapt. Android este un sistem de operare bazat pe Dalvik VM, iar Google Play găzduiește aplicații Dalvik. Dalvik VM în sine, la fel ca Java VM, este întotdeauna pe 32 de biți, indiferent de bititatea mașinii fizice.

După cum ați bănuit, aplicațiile livrate cu binare native și aplicații NDK trebuie livrate cu binare compilate pentru fiecare arhitectură. este destinat să ruleze la. Cea mai obișnuită arhitectură pe care rulează Android este ARM pe 32 de biți; totuși, există și dispozitive care rulează pe x86 și MIPS.

Bănuiesc, dar cred că și asta explică simplu. Depinde de dispozitivul pe care îl utilizați, există patru tipuri de sisteme de operare, care sunt ARM, ARM 64, X84 și X84_64. ARM este platforma populară pe 32 de biți, ARM 64 este, de asemenea, platforma populară, dar pe 64 de biți, X84 este platforma neobișnuită și este utilizată pe Zenfones, la fel ca X84_64 este neobișnuită și utilizată pe emulatoarele Android. Am obținut aceste informații despre sistemul de operare Open Gapps