I området til ARM-brikkesettene som er den vanlige faktoren, hele Android-stakken, fra den nesten identiske kjernen basert på Linux, er faktisk 32bit, krysskompilert fra vanligvis enten et 32bit / 64bit vertsmiljø, vertsmiljøet er vanligvis en av distribusjonene av Linux. Anbefalt distribusjon av Google for å bygge og krysskompilere Android er Ubuntu .

Android-kjøretidsbiblioteket (media, grafikk, filsystem, for å nevne noen få) er også 32bit, men når vi når laget av dalvikvm, så blir antall biter irrelevante som det er på dette punktet, apkene som kommer fra Google Play Store er innfødte bytekoder (Et «biprodukt» av generert Java-kode samlet inn i en bærbar bytecode) som retter seg mot DalvikVM (Virtual Machine) som igjen tolker og oversetter bytecode som målretter det rå ARM instruksjonssettet.

Froyo var den siste Android som muliggjorde kompilering under et 32-bit vertsmiljø der det var kryss-kompilert målretting mot ARM-brikkesettet.

Pepperkaker var den første av «fremtidige» Android, den gang for rundt tre år siden, som innførte et krav om å bruke et 64-biters vertsmiljø der det ble bygget. . Det var mange hacks for å få pepperkaker til å bygges under 32-biters miljø.

ICS og JB, og oppover, krever nå definitivt et 64-biters miljø for å fremskynde kompilering og for å redusere dreietiden i bygningen.

Så for å oppsummere, det du ser på Play Store har ingen betydning for om 32bit eller 64bit brukes og dermed irrelevant.

Sideanmerkning: Typisk 16 GB RAM / Quad core / 64bit Linux-distribusjon, tiden det tar å bygge ICS fra bunnen av, tar maksimalt 30 minutter, hadde dette vært en 32-biters Linux-distribusjon, ville det tatt lengre tid, faktisk, kan føre til en CPU-nedsmelting da det ganske enkelt er, ikke nok prosessorkraft for å churn og sveive ut krysskompilert kode, som er en veldig krevende og beskattende prosess!

Bevis på dette.

Trekk inn hvilken som helst naturlig ARM-binær som finnes i /system/bin eller /system/xbin , for eksempel /system/bin/dalvikvm, dette er Dalvik VM-binær som er ansvarlig for de øvre lagene av Java og APK-er.

Undersøk nå binæren ved å utstede dette kommando: file dalvikvm som gir et sammendrag av filtypen det er, den forventede utgangen vil være denne:

dalvikvm: ELF 32-bit LSB-kjørbar, ARM, versjon 1 (SYSV), dynamisk koblet (bruker delte biblioteker), strippet

Legg merke til referansen til 32-bit ELF, og er krysskompilert til ARM og er en binær kjørbar.

Høyre, videre, la oss inspisere et eget delt bibliotek funnet i /system/lib, for eksempel /system/lib/libandroid_runtime.so, utgir nå file libandroid_runtime.so, forventet utgang ville være dette:

libandroid_runtime.so: ELF 32-bit LSB delt objekt, ARM, versjon 1 (SYSV), dynamisk koblet, strippet

Igjen, legg merke til at dens 32-bit ELF, krysskompilert til ARM og er et delt bibliotek.

Nøkkelen til vertens kryss-kompilering kan bli funnet i AOSP-kilden, dvs. at pepperkakebygging opprinnelig hadde et krav om å bli bygget på et 64-bit vertssystem, her er nyhetsgruppen linky med henvisning til hvordan du lapper skriptene for å få det til å bygge på 32-bit vert som har to oppdateringer, funnet her, for build/core.mk og build/main.mk ( kombinert ) på AOSPs Gerrit-gjennomgang.

Som en påfølgende resultatet hadde denne oppdateringen gjort veien til ICSs byggeskripter der jeg hadde privilegiet å kompilere ICS på en 32-biters plattform som det tok 3 dager å bygge ( det var en port av ICS for Zte Blade ). Nå økes kravene, du gjør absolutt 64bit-vert for å muliggjøre kryss-kompilering av å bygge AOSP fra ICS og oppover: )

Kommentarer

• Så du mener at det å samle og kjøre et på 32-biters Android OS tar langsommere enn i 64-bit? Er det et generelt krav at alle 64-biters for moderne Android OS som Kitkat eller L ?
• Det er nå 64-biters ARM-enheter kjører 64-biters Android.
• Jeg ‘ nedstemmer fordi det meste av svaret handler om hvilke miljøer som brukes til å kompilere Android, noe som er helt irrelevant for spørsmål.
• @DanHulme Dette svaret ble lagt ut for nær 4 år siden … ja, landskapet har endret seg mye siden den gang. 🙂
• Ja, at ‘ er sant, og jeg ‘ skal legge ut et nytt svar om situasjonen i dag, men kompilasjonsmiljøet har alltid vært en rød sild.

Opprinnelig ble Android skrevet bare for 32-biters prosessorer: og spesielt 32-biters ARM-prosessorer. Senere investerte Intel og MIPS mye i å få Android til å støtte arkitekturen også: men fortsatt bare 32-biters prosessorer. De klarte å gjøre dette uten (mange) kompatibilitetsproblemer, fordi de fleste apper ikke sendes som binære filer. Skrevet i Java blir de i stedet sendt som bytecode , som en virtuell maskin på telefonen kompileres til telefonens arkitektur når appen kjøres. Noen apper inneholder native komponenter, som sendes som binær. Dette gjøres for å gjøre noen typer apper raskere (spesielt spill), eller for å la appen få tilgang til C-biblioteker som ikke er tilgjengelige i Java. Disse appene kan inneholde mer enn en binær for de innfødte kodedelene, slik at de kan kjøre på forskjellige arkitekturer. Allikevel er de fleste apper bare Java, så de fungerer bare på hvilken som helst arkitektur.

Ovennevnte var sant på det tidspunktet dette spørsmålet (og de fleste av de andre svarene) var skrevet, men ikke lenger. Lollipop introduserte støtte for de nye 64-biters ARM-prosessorene ( ARMv8 ) samt for Intel og AMDs x86_64-prosessorer, noe som betyr at Android nå støtter både 32-bit og 64-biters prosessorer. Nexus 9 var det første 64-biters Android-enheten. I tillegg til å gi tilgang til nye instruksjonsutvidelser, betyr 64-biters støtte at apper kan bruke mer enn 4 GB RAM. De fleste apper trenger ikke så mye, men avanserte spill og programvare for å lage foto / video kan absolutt benytte seg av det: å presse Android mot å være en plattform for spill i konsollkvalitet (inkludert VR-spill) og for å lage innhold. Java-apper trenger ikke å oppdateres for å dra nytte av dette, fordi den virtuelle maskinen alltid kompilerer dem til telefonens arkitektur, men apper med innfødt kode vil.

Fordi ARMv8 er bakoverkompatibel med 32- bitkode (på samme måte som x86_64 fremdeles kan kjøre x86-kode), til og med apper som inkluderer innebygd kode for 32-biters prosessorer, kan fortsatt kjøre på 64-biters Android. En app trenger bare å kompileres for 64-bit hvis den inneholder kode og vil den dra nytte av den høyere RAM-grensen eller de nye funksjonene i arkitekturen.

Alle ARM-sjetonger er for tiden 32-bit. På grunn av dette kjører Android for øyeblikket all kode i et 32-biters miljø.

64-biters prosessorer satt til å starte i 2014 .

Kommentarer

• At ‘ ikke akkurat er en pålitelig kilde da dette snakket om servere, for å sitere “ Smarttelefonen er litt lenger borte, ”sa Forsyth. , vi ‘ snakker om ARM i sammenheng med Android / smarttelefoner / nettbrett.

Er Android et 32- eller 64-biters operativsystem? Jeg antar at det er en eller annen og ikke begge deler, da det ville tvinge både 32- og 64-bits binærfiler til å være vert på Google Play.

Verken faktisk. Android er et Dalvik VM-basert operativsystem, og Google Play er vert for Dalvik-applikasjoner. Dalvik VM selv, som Java VM, er alltid 32-bit uavhengig av den fysiske maskinens bithet.

Som du mistenker, må applikasjoner som leveres med innfødte binære filer og NDK-applikasjoner leveres med binærfiler som er samlet for alle arkitekturer det er ment å løpe på. Den vanligste arkitekturen som Android kjører på er ARM 32-bit; men det er også enheter som kjører på x86 og MIPS.

Jeg gjetter bare, men jeg tror dette forklarer det bare enkel. Det avhenger av hvilken enhet du bruker, det er fire typer operativsystemer som er ARM, ARM 64, X84 og X84_64. ARM er den populære 32-biters plattformen, ARM 64 er også den populære men 64-biters plattformen, X84 er den uvanlige plattformen og brukes på Zenfones, samme som X84_64, den er uvanlig og brukes på Android-emulatorer. Jeg har denne informasjonen om Open Gapps