I området för ARM-chipsets som är den gemensamma faktorn, hela Android-stacken, från den nästan identiska kärnan baserat på Linux är i själva verket 32-bitars, tvärsammanställt från vanligtvis antingen en 32-bitars / 64-bitars värdmiljö, värdmiljön är vanligtvis en av distributionerna av Linux. Rekommenderad distribution av Google för att bygga och korskompilera Android är Ubuntu .

Android-körtidsbiblioteket (media, grafik, filsystem, för att bara nämna några) är också 32 bitar, men när vi når dalvikvm-lagret blir antalet bitar irrelevant eftersom det är vid den här tiden, apkarna som kommer från Google Play Store är inbyggd bytkod (En ”biprodukt” av genererad Java-kod kompilerad till en bärbar bytecode) som riktar sig mot DalvikVM (Virtual Machine) som i sin tur tolkar och översätter bytecode som riktar sig till den råa ARM-instruktionsuppsättningen.

Froyo var den senaste Android som möjliggjorde kompilering under en 32-bitars värdmiljö där det var en tvärsammanställd inriktning på ARM-chipsetet.

Pepparkakor var den första av ”framtida” Android, då omkring tre år sedan, som införde ett krav att använda en 64-bitars värdmiljö där den byggdes . Det fanns många hack för att få pepparkakor att byggas under 32-bitars värdmiljö.

ICS och JB, och uppåt, kräver nu definitivt en 64-bitars miljö för att påskynda sammanställningen och för att minska vändningstiden i byggnaden.

Så för att sammanfatta, vad du ser i Play Store har ingen betydelse för om 32bit eller 64bit används och därmed irrelevant.

Sidanot: Typiskt 16 GB RAM / Fyrkärnig / 64-bitars Linux-distribution, den tid det tar att bygga ICS från grunden, tar maximalt 30 minuter, hade detta varit en 32-bitars Linux-distribution, skulle det ha tagit längre tid, i själva verket, kan orsaka en CPU-meltdown eftersom det helt enkelt är, inte tillräckligt bearbetningskraft för att churn och vrida ut korskompilerad kod, vilken är en mycket krävande och beskattande process!

Bevis på detta.

Dra in valfri ARM-binär som finns i /system/bin eller /system/xbin till exempel /system/bin/dalvikvm, detta är Dalvik VM-binär som ansvarar för de övre lagren av Java och APK.

Undersök nu binärfilmen genom att utfärda detta kommando: file dalvikvm som ger en sammanfattning av vilken filtyp det är, den förväntade utdata skulle vara den här:

dalvikvm: ELF 32-bitars LSB-körbar, ARM, version 1 (SYSV), dynamiskt länkad (använder delade libs), strippad

Lägg märke till referensen till 32-bitars ELF och är tvärsammanställd till ARM och är en binär körbar.

Höger, fortsätter, låt oss inspektera ett inbyggt delat bibliotek som finns i /system/lib, till exempel /system/lib/libandroid_runtime.so, utfärdar nu file libandroid_runtime.so, den förväntade utgången skulle vara denna:

libandroid_runtime.so: ELF 32-bitars LSB-delat objekt, ARM, version 1 (SYSV), dynamiskt länkad, avskalad

Återigen, märk, dess 32-bitars ELF, korskompilerad till ARM och är ett delat bibliotek.

Nyckeln till värdens tvärkompilering kan hittas i AOSP-källan, dvs att pepparkakor hade ursprungligen ett krav på att byggas på ett 64-bitars värdsystem, här är nyhetsgruppen linky hänvisar till hur man lappar skripten för att få den att bygga på 32-bitars värd som har två korrigeringsfiler, som finns här, för build/core.mk och build/main.mk ( kombinerat ) på AOSP: s Gerrit-recension.

Som en efterföljande resultatet, den här korrigeringen hade tagit sig till ICS: s byggskript där jag hade privilegiet att kompilera ICS på en 32-bitars plattform som det tog 3 dagar att bygga ( det var en port av ICS för Zte Blade ). Nu förstärks kraven, du gör definitivt 64bit-värd för att möjliggöra korskompilering av att bygga AOSP från ICS uppåt: )

Kommentarer

• Så menar du att det går långsammare att sammanställa och köra ett på 32-bitars Android OS än i 64-bitars? Är det ett allmänt krav att alla är 64-bitars för moderna Android-operativsystem som Kitkat eller L ?
• Det finns nu 64-bitars ARM-enheter kör 64-bitars Android.
• Jag ’ nedröstning eftersom det mesta av svaret handlar om vilka miljöer som används för att kompilera Android, vilket är helt irrelevant för fråga.
• @DanHulme Detta svar postades för nära 4 år sedan … ja, landskapet har förändrats mycket sedan dess. 🙂
• Ja, att ’ är sant, och jag ’ ska lägga upp ett nytt svar om situationen idag, men sammanställningsmiljön har alltid varit en röd sill.

Android skrevs ursprungligen endast för 32-bitars processorer: och särskilt för 32-bitars ARM-processorer. Senare investerade Intel och MIPS mycket för att få Android att stödja sina arkitekturer också: men fortfarande bara 32-bitars processorer. De kunde göra detta utan (många) kompatibilitetsproblem, eftersom de flesta appar inte levereras som binära filer. Skrivna i Java skickas de istället som bytecode , vilket är en virtuell maskin på telefonen kompileras med telefonens arkitektur när appen körs. Vissa appar innehåller inbyggda komponenter, som levereras som en binär. Detta görs för att göra vissa typer av appar snabbare (särskilt spel) eller för att låta appen få åtkomst till C-bibliotek som inte är tillgängliga i Java. Dessa appar kan innehålla mer än en binär för de inbyggda koddelarna, så att de kan köras på olika arkitekturer. Trots det är majoriteten av apparna bara Java, så de fungerar bara på vilken arkitektur som helst.

Ovanstående var helt sant när denna fråga (och de flesta av de andra svaren) var skrivet, men inte längre. Lollipop introducerade stöd för de nya 64-bitars ARM-processorerna ( ARMv8 ) samt för Intel och AMDs x86_64-processorer, vilket innebär att Android nu stöder både 32-bitars och 64-bitars processorer. Nexus 9 var det första flaggskeppet med 64-bitars Android-enhet. Förutom att ge tillgång till nya instruktionsuppsättningstillägg innebär 64-bitarsstöd att appar kan använda mer än 4 GB RAM. De flesta appar behöver inte så mycket, men avancerade spel och program för skapande av foto / video kan verkligen använda det: att driva Android mot att vara en plattform för spel i konsolkvalitet (inklusive VR-spel) och för att skapa innehåll. Java-appar behöver inte uppdateras för att dra nytta av detta, eftersom den virtuella maskinen alltid kompilerar dem till telefonens arkitektur, men appar med inbyggd kod kommer.

Eftersom ARMv8 är bakåtkompatibel med 32- bitkod (på samma sätt som x86_64 fortfarande kan köra x86-kod), även appar som innehåller inbyggd kod för 32-bitarsprocessorer kan fortfarande köras på 64-bitars Android. Så en app behöver bara kompileras för 64-bitars om den innehåller inbyggd kod och vill utnyttja den högre RAM-gränsen eller de nya funktionerna i arkitekturen.

Alla ARM-chips är för närvarande 32-bitars. På grund av detta kör Android för närvarande all kod i en 32-bitars miljö.

64-bitars processorer inställda på att starta 2014 .

Kommentarer

• Att ’ inte exakt är en pålitlig källa eftersom det här talade om servrar, för att citera ” Smartphone är lite längre bort ”, sa Forsyth. vi ’ talar om ARM i samband med Android / smartphones / surfplattor.

Är Android ett 32- eller 64-bitars operativsystem? Jag antar att det är en eller annan och inte båda, eftersom det skulle tvinga både 32- och 64-bitars binärer att vara värd på Google Play.

Inte heller faktiskt. Android är ett Dalvik VM-baserat OS och Google Play är värd för Dalvik-applikationer. Dalvik VM i sig, precis som Java VM, är alltid 32-bitars oavsett hur mycket den fysiska maskinen är.

Som du misstänker måste applikationer som levereras med inbyggda binära filer och NDK-applikationer levereras med binärer som sammanställts för alla arkitekturer det är avsett att springa på. Den vanligaste arkitekturen som Android körs på är ARM 32-bit; men det finns också enheter som körs på x86 och MIPS.

Jag gissar bara men jag tror att detta också förklarar det bara enkel. Det beror på vilken enhet du använder, det finns fyra typer av operativsystem som är ARM, ARM 64, X84 och X84_64. ARM är den populära 32-bitars plattformen, ARM 64 är också den populära men 64-bitars plattformen, X84 är den ovanliga plattformen och används på Zenfones, samma som X84_64 dess ovanliga och används på Android-emulatorer. Jag har den här informationen om Open Gapps