I området af ARM-chipsæt, som er den fælles faktor, hele Android-stakken, fra den næsten identiske kerne baseret på Linux er faktisk 32bit, krydskompileret fra normalt enten et 32bit / 64bit værtsmiljø, værtsmiljøet er normalt en af distributionerne af Linux. Anbefalet distribution fra Google til opbygning og krydskompilering af Android er Ubuntu .

Android-runtime-biblioteket (medier, grafik, filsystem, for blot at nævne nogle få) er også 32bit, men når vi når frem til laget af dalvikvm, så bliver antallet af bits irrelevant, som det er på dette tidspunkt, apkerne, der kommer fra Google Play Butik, er native bytecode (Et “biprodukt” af genereret Java-kode, der er kompileret til en bærbar bytecode), der er målrettet mod DalvikVM (Virtual Machine), som igen fortolker og oversætter bytecode, der målretter det rå ARM-instruktions sæt.

Froyo var den sidste Android, der muliggjorde kompilering under et 32bit hostet miljø, hvor det var krydskompileret målretning af ARM-chipsættet.

Gingerbread var den første af “fremtidige” Android, dengang for cirka tre år siden, der indførte et krav om at bruge et 64bit hostet miljø, hvor det blev bygget . Der var mange hacks for at få Gingerbread til at blive bygget under 32bit hostet miljø.

ICS og JB, og opefter, kræver nu helt sikkert et 64-bit miljø for at fremskynde kompilering og reducere omdrejningstid i bygningen.

Så for at opsummere har det, du ser i Play Butik, ingen indflydelse på, om der bruges 32bit eller 64bit og dermed irrelevant.

Side note: Typisk 16 GB RAM / Quad core / 64bit Linux-distribution, den tid det tager at opbygge ICS fra bunden, tager maksimalt 30 minutter, hvis dette var en 32bit Linux-distribution, ville det have taget længere tid, faktisk, kan forårsage en CPU-nedbrydning, da der simpelthen ikke er nok bearbejdningskraft til at churn og crank ud krydskompileret kode, som er en meget krævende og beskatningsproces!

Bevis for dette.

Træk ethvert indfødt ARM-binær, der findes i /system/bin eller /system/xbin for eksempel /system/bin/dalvikvm, dette er Dalvik VM-binærsystemet, der er ansvarlig for de øverste lag af Java og APKer.

Undersøg nu binærprogrammet ved at udstede dette kommando: file dalvikvm som giver et resumé af den filtype det er, den forventede output ville være denne:

dalvikvm: ELF 32-bit LSB eksekverbar, ARM, version 1 (SYSV), dynamisk linket (bruger delte libs), fjernet

Læg mærke til henvisningen til 32-bit ELF og er krydskompileret til ARM og er en binær eksekverbar.

Højre, fortsætter, lad os inspicere et indbygget delt bibliotek fundet i /system/lib, f.eks. /system/lib/libandroid_runtime.so, udsteder nu file libandroid_runtime.so, det forventede output ville være dette:

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

Igen skal du bemærke, dens 32-bit ELF, krydskompileret til ARM og er et delt bibliotek.

Nøglen til værtens krydskompilering kan findes i AOSP-kilden, dvs. at Gingerbread build oprindeligt havde et krav om at blive bygget på et 64bit værtssystem, her er nyhedsgruppen linky henviser til hvordan man lapper scripts for at få det til at bygge på 32bit vært som har to patches, der findes her, til build/core.mk og build/main.mk ( kombineret ) på AOSPs Gerrit-gennemgang.

Som en efterfølgende resultatet, denne patch havde fundet vej til ICSs build-scripts, hvor jeg havde privilegiet at kompilere ICS på en 32bit platform, som det tog 3 dage at bygge ( det var en havn i ICS til Zte Blade ). Nu er kravene forøget, du gør bestemt brug for 64bit vært for at muliggøre krydskompilering af bygning AOSP fra ICS opad: )

Kommentarer

• Så mener du, at kompilering og kørsel af et på 32-bit Android OS tager langsommere end i 64-bit? Er det et generelt krav at være alle 64-bit til moderne Android OS såsom Kitkat eller L ?
• Der er nu 64-bit ARM-enheder kører 64-bit Android.
• Jeg ‘ nedstemmer, fordi det meste af svaret handler om, hvilke miljøer der bruges til at kompilere Android, hvilket er helt irrelevant for spørgsmål.
• @DanHulme Dette svar blev sendt nær 4 år siden … ja, landskabet har ændret sig meget siden da. 🙂
• Ja, at ‘ er sandt, og jeg ‘ skal sende et nyt svar om situationen i dag, men kompileringsmiljøet har altid været en rød sild.

Oprindeligt blev Android skrevet kun til 32-bit processorer: og specifikt 32-bit ARM-processorer. Senere investerede Intel og MIPS meget i at få Android til at understøtte deres arkitekturer også: men stadig kun 32-bit processorer. De var i stand til at gøre dette uden (mange) kompatibilitetsproblemer, fordi de fleste apps ikke sendes som binære filer. Skrevet i Java sendes de i stedet som bytecode , som en virtuel maskine på telefonen kompileres til telefonens arkitektur, når appen køres. Nogle apps inkluderer indbyggede komponenter, der sendes som en binær. Dette gøres for at gøre nogle slags apps hurtigere (især spil) eller for at lade appen få adgang til C-biblioteker, der ikke er tilgængelige i Java. Disse apps kan omfatte mere end en binær for de oprindelige kodedele, så de kan køre på forskellige arkitekturer. Alligevel er størstedelen af apps kun Java, så de arbejder bare på enhver arkitektur.

Ovenstående var alle rigtige på det tidspunkt, hvor dette spørgsmål (og de fleste af de andre svar) var skrevet, men ikke længere. Lollipop introducerede support til de nye 64-bit ARM-processorer ( ARMv8 ) såvel som til Intel og AMDs x86_64-processorer, hvilket betyder, at Android nu understøtter både 32-bit og 64-bit processorer. Nexus 9 var det første flagskib 64-bit Android-enhed. Ud over at give adgang til nye instruktionsudvidelser betyder 64-bit support, at apps kan bruge mere end 4 GB RAM. De fleste apps har ikke brug for så meget, men avancerede spil og software til oprettelse af foto / video kan helt sikkert gøre brug af det: skubbe Android mod at være en platform til spil i konsolkvalitet (inklusive VR-spil) og til oprettelse af indhold. Java-apps behøver ikke at blive opdateret for at drage fordel af dette, fordi den virtuelle maskine altid kompilerer dem til telefonens arkitektur, men apps med native-kode vil.

Fordi ARMv8 er bagudkompatibel med 32- bit kode (på samme måde som x86_64 stadig kan køre x86-kode), selv apps, der inkluderer native kode til 32-bit processorer, kan stadig køre på 64-bit Android. En app behøver kun at blive kompileret til 64-bit, hvis den indeholder native kode og ønsker den at udnytte den højere RAM-grænse eller de nye funktioner i arkitekturen.

Alle ARM-chips er i øjeblikket 32-bit. På grund af dette udfører Android i øjeblikket al kode i et 32-bit miljø.

64-bit processorer indstillet til lancering i 2014 .

Kommentarer

• At ‘ ikke ligefrem er en pålidelig kilde, da dette talte om servere, for at citere “ Smartphone er lidt længere væk, ”sagde Forsyth. , vi ‘ taler om ARM i forbindelse med Android / smartphones / tablets.

Er Android et 32- eller 64-bit OS? Jeg antager, at det er det ene eller det andet og ikke begge dele, da det ville tvinge både 32- og 64-bit binære filer til at blive hostet på Google Play.

Hverken faktisk. Android er et Dalvik VM-baseret OS, og Google Play er vært for Dalvik-applikationer. Selve Dalvik VM er ligesom Java VM altid 32-bit uanset biten på den fysiske maskine.

Som du har mistanke om, skal applikationer, der sendes med oprindelige binære filer og NDK-applikationer, leveres med binære filer, der er kompileret til alle arkitekturer det er beregnet til at køre på. Den mest almindelige arkitektur, som Android kører på, er ARM 32-bit; dog er der også enheder, der kører på x86 og MIPS.

Jeg gætter bare, men jeg tror, det forklarer det bare enkel. Det afhænger af, hvilken enhed du bruger, der er fire typer operativsystemer, som er ARM, ARM 64, X84 og X84_64. ARM er den populære 32 bit platform, ARM 64 er også den populære men 64 bit platform, X84 er den ualmindelige platform og bruges på Zenfones, samme som X84_64, den er usædvanlig og bruges på Android Emulatorer. Jeg har disse oplysninger om Open Gapps