Google werkt aan 64bit-ondersteuning Android

Google werkt aan ondersteuning voor 64bits processors in zijn mobiele besturingssysteem Android. Aanwijzingen daarvoor werden gevonden in de broncode van het OS. Over enige tijd moeten de eerste smartphones uitkomen met een 64bit-soc.

Een commit op het Android Open Source Project maakt melding van de 64bit-ondersteuning. Daarin wordt gesproken over het ondersteunen van 32bit-binaries op een apparaat dat van een processor met ARMv8-instructieset is voorzien. Deze instructieset voor ARM-soc's is voorzien van 64bit-ondersteuning en wordt onder andere gebruikt door Qualcomm in zijn high-end Snapdragon 810-soc. Ook MediaTek heeft een 64-bits-soc gepresenteerd.

Daarnaast wordt gesproken over api-niveau 20. Dat is één level boven het huidige niveau, dat in Android 4.4 op 19 is aanbeland. Wat de wijzigingen zijn die Google heeft doorgevoerd voor ontwikkelaars die van Android-api's gebruikmaken is niet duidelijk, maar de nieuwe api's zullen waarschijnlijk in een volgende versie van het mobiele besturingssysteem verschijnen.

Dat Google werkt aan ondersteuning voor 64bits instructies op Android is geen verrassing. Naast de aankondiging van verscheidene soc's met 64bit-ondersteuning kwamen er ook geruchten naar buiten over een nieuwe lijn met Google-smartphones met de Silver-naam. De eerste van deze smartphones zou, als de geruchten kloppen, zijn voorzien van een 64bit-soc, vermoedelijk de Snapdragon 808 of 810.

Omdat Google zelf nog geen informatie heeft vrijgegeven over de plannen voor 64bits ondersteuning, is nog onduidelijk wanneer de functionaliteit wordt uitgebracht. Het is aannemelijk dat 64bits ondersteuning, net als het nieuwe api-level, wordt doorgevoerd in in de eerstvolgende nieuwe versie van Android. ARM liet eerder weten te verwachten dat er snel meer smartphones komen met 64bit-soc's. Apple was onlangs de eerste met de iPhone 5s.

Reacties (139)

[Dreamvoid]

Wellicht moet het artikel duidelijker worden vermeld dat het her gaat om de 64-bit ARM versie van Android, de 64-bit Android versie voor x86 SoCs is in Januari al vrijgegeven en wordt gebruikt voor de komende Bay Trail tablets.

http://www.pcworld.com/ar...-for-x86-smartphones.html

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 18:07]

[mikesmit]

Sorry, 64 bits versie voor x86 socs? Ik denk dat er een aanpassing in die zin moet komen...

[Verwijderd]

x86_64
Nu goed?

[Verwijderd]

De eerste twee 64-bit cores van ARM, de Cortex A57 en A53 kunnen volgens ARM allebij 32-bit ARM applicaties efficient uitvoeren en hebben zelfs binary compatibility. (AAarch32). ARM geeft de indruk zat ze, vergeleken met corresponderende 32-bit cores op het zelfde fab-process, sneller zijn. De zuinigheid moet nog duidelijk worden, want de cores zijn waarschijnlijk een stuk groter binnen een chip.

De Cortex A57 is een grote core met hoge performance (waarschijnlijk lijkt de core in de Apple A7 daar veel op), maar is minder zuinig. Door ARM wordt hij gezien als opvolger van de Cortex A15, die ook niet zuinig was.

De Cortex A53 is een kleine, efficiente "in-order" core die de opvolger is van de Cortex A7. De laatste is in de praktijk heel zuinig en efficient gebleken met adequate performance en goede scaling naar meer cores, en dat zal waarschijnlijk ook voor de A53 gelden. Het lijkt mij dat deze heel populair wordt in mobiele apparaten.

http://www.arm.com/produc.../cortex-a57-processor.php

Het is waarscijnlijk dat een 32-bit versie van Android, of een aangepaste versie van 32-bit Android, het mogelijk maakt op deze cores in ieder geval 32-bit applicaties snel te laten uitvoeren. Bijvoorbeeld door de cores gewoon helemaal in Aarch32 compatibility mode te laten lopen. De optimalisaties in de pipeline implementatie van de core zullen waarschijnlijk ook voor 32-bit code voordelen opleveren. Waarschijnlijk zal een gedeelte van de eerste Android apparaten die de nieuwe cores gebruiken gewoon een soort 32-bit Android runnen

Het is wellicht ook mogelijk om Aarch64 mode te gebruiken maar gewoon met 32-bit Android. Dan kunnen Java applicaties via JIT gebruik kunnen maken van verdere voordelen het nieuwe ARMv8 instructieset, zoals meer registers, en andere verbeteringen. Dit zou de meest praktische oplossing kunnen zijn.

De Cortex A5x cores hebben met het ARMv8 instructie set hebben een aantal voordelen t.o.v. 32-bit ARMv7 cores. 32 registers i.p.v. 16 zorgt voor betere optimalisatie door compilers (native of JIT), hoewel het voordeel minder groot zal zijn dan het was bij x86-32 naar x86-64 (8 naaar 16 registers).

Instructies die werken op 64-bit registers heeft voordelen voor sommige applicaties, maar daarbij moet wel opgemerkt worden dan ARMv7 ook al een aantal instructies heeft die met 64-bit waarden werken (twee 32-bit registers), en veel algoritmen (bv. voor video) die 64-bit instructies zouden kunnen gebruiken hebben waarschijnlijk meer baat met het gebruik NEON (SIMD) (wat al in de meeste ARMv7 cores zat) dan 64-bit ARMv8 instructies. De 64-bit cores hebben trouwens ook speciale cryptografie acceleratie. En NEON werkt nu ook met 64-bit (double) floating point.

Verder lijkt me een betere samenwerking met de GPU in ieder geval voor GPU Compute met een ingebouwde Mali GPU (coherente cache) een voordeel. Ik heb wel de indruk dat Qualcomm in hun laatste generatie (Snapdragon 800 etc) al redelijk ver was met het delen van een grote 2MB L2 cache tussen de CPU cores en de GPU wat natuurlijk veel efficienter is dan twee grote L2 caches (een voor CPU cores en een voor GPU) op de chip de plaatsen. Ik twijfel of dit ook met Cortex A5x haalbaar is (de meeste 32-bit ARM processors met Mali GPU hebben gewoon een volledig gescheiden L2 cache voor de GPU van b.v. 256KB, terwijl de grotere L2 cache van de CPU cores nauwelijks benut kan worden door de GPU).

[aval0ne]

De Cortex A57 is een grote core met hoge performance (waarschijnlijk lijkt de core in de Apple A7 daar veel op), maar is minder zuinig. Door ARM wordt hij gezien als opvolger van de Cortex A15, die ook niet zuinig was.

De A7 lijkt waarschijnlijk helemaal niet op een cortex A57 of A53 maar is een volledig custom ontwerp (cyclone).

[beantherio]

is dit niet oud nieuws? Intel heeft al een 64-bits port van Android klaar staan (zie nieuws: Intel komt met Android 4.4 met 64bit-kernel en 14nm-socs voor instap-pc's ) en ik meen vorig jaar al een artikel gelezen te hebben waarin gemeld werd dat er in de source van nieuwere releases van Android aanwijzingen te vinden waren van werk door Google aan een toekomstige 64-bit release (het artikel kan ik helaas niet terugvinden).

[aval0ne]

Tablet =/= Telefoon

[P1nGu1n]

Zat er dik aan te komen, de 64-bit socs zijn ook al aangekondigd. Vraag is of je er nu al veel profijt van hebt, 4 GB RAM, is dat niet overkill op dit moment? Maar ach, op 19 januari 2038 om 03:14:07 moeten we toch over zijn op 64-bit haha..

[Markcortbass]

64-Bit socs en 4GB RAM is voor alleen smartphone gebruik natuurlijk overkill. Maar dat veranderd als je je smartphone dockt en gebruikt als desktop.
http://www.ubuntu.com/phone/ubuntu-for-android

[Maurits van Baerle]

64 bit gaat wel over iets meer dan alleen 4GB. Het is een hele architectuur die verandert. Er zijn bijvoorbeeld bij bestaande smartphones met 64 bit ARM architectuur (die minder dan 4GB RAM hebben) ook duidelijk snelheidswinsten meetbaar. Bredere bussen, verbeteringen in de instructieset en extra registers kunnen veel uitmaken.

Het is niet meer dan logisch dat Google dat nu ook op Android wil.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 18:07]

[Verwijderd]

Het is niet alleen RAM voordeel, kijk eens naar je registers?

[schaduwridder]

waarom? een 32bit systeem kan daar al op voorbereid zijn.

[OddesE]

Nou om een timestamp als 64-bit op te slaan heb je geen 64-bit proc. nodig hoor.

[Loller1]

Ik ben benieuwd, maar begrijp nog steeds niet waarom we nu plots allemaal 64-bit nodig zouden hebben, alsof 32-bit voor een smartphone niet genoeg is... Kom aan, normale desktops zijn pas sinds 2009 aan het overschakelen op 64-bit, en zelfs nu vind je nog 32-bit machines in de winkels.

[Verwijderd]

Omdat er nu al smartphones zijn met 3GB, met 4GB en een 32 bit's OS verlies je geloof ik al werkgeheugen.

En natuurlijk voor marketing; Android fabrikanten hadden een 64-bits A8 niet verwacht in september '13, en denken nu dus dat zij achterlopen met een 32-bits processor. Puur marketing natuurlijk, maar dat speelt wel mee.

[Silmarunya]

Met 4GB nog net niet, maar dat doet weinig terzake. Er zijn gewoonweg geen apps die baat hebben bij zoveel werkgeheugen, en de trend lijkt de afgelopen jaren net terug naar efficiënter geheugengebruik te gaan (zie Android 4.4).

Zelfs bij PC-gaming blijkt het voordeel van meer dan 4GB volgens Tweakers erg beperkt. Laat staan in een smartphone.

[Soldaatje]

En disk cache dan?
En dat er geen apps zijn die er gebruik van maken komt omdat er nog geen hardware voor is, kip en ei dus.
Meer dan 4 GB is altijd goed, maar dat kan ook met PAE heb je geen 64 bits voor nodig.

[bantoo]

Alleen in Windows land deden ze er zo lang over, Linux bijvoorbeeld was direct over. 64 heb je niet per se nodig, daar gaat het ook niet om. Het is gewoon een stuk comfortabeler om nu al te wisselen dan wanneer het wel echt nodig is. De prestatieboost alhoewel klein in ook fijn.

[MSalters]

Kunst, Linux werkte niet alleen op x86 maar ook op bijvoorbeeld SPARC. En de SPARC64 dateert al van 1995, dus het is niet zo bijzonder dat Linux-amd64 er zo snel was. De basis 64 bits code bestond al een decennium.

[Verwijderd]

alsof 32-bit voor een smartphone niet genoeg is...

Men dacht ook ooit dat 640 kilobyte ruim voldoende was voor een pc, en dat er in het jaar 2000 hooguit een markt voor een stuk of 6 computers zou bestaan.

De Android kernel is, als ze er niet een al te grote zooi van hebben gemaakt,al zo goed als klaar voor 64 bit. Misschien willen ze Android naar zwaardere machines brengen met veel meer geheugen. Het zal mij in elk geval benieuwen waarom ze deze stap zetten.

Edit: Ik weet niet precies wat ik gedaan heb om de minnetjes te scoren, maar eh... Sorry?

De Kernel is als het goed is al klaar om naar 64 bit gecompileerd te worden. Als Google slim is, hebben ze bij het bouwen van de lagen daar bovenop ook rekening gehouden met 64bit. Het lijkt me tenminste een kleinere stap dan rekening houden met Arm en x86 architectuur.

Dat bedoelde ik met mijn reactie. Je kan wel zeggen dat het niet nodig is, maar als het OS er al klaar voor is, waarom zou je het niet doen? Plus, de ontwikkelingen gaan zo snel, dat je je over een paar jaar misschien al niet meer kan voorstellen dat je aan 32bit ooit genoeg had.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:07]

[OddesE]

Android's kernel is Linux dus ja die is allang 64-bit. En ook heus wel een zooitje.

[koelpasta]

Deze discussie gaat niet over of het zin heeft om een 64 bit kernel te hebben maar over het algemene nut van 64 bit cpu's in een smartphone...

[Verwijderd]

Ik zou het nut niet onmiddellijk weten, maar kennelijk is het er wel. Ik neem tenminste aan dat ARM de processors niet voor de grap produceert. Als het geen nut zou hebben, dan is de kans groot dat er ook geen vraag naar komt, waardoor ARM er verlies op zou draaien.

Plus, je OS pas aanpassen als het nut heeft, kan betekenen dat je jezelf op een flinke achterstand stelt ten opzichte van de concurrentie. Aangezien de investering nu redelijk te overzien is (denk ik) is het helemaal geen slecht idee om het nu te doen.

En misschien zitten fabrikanten als Samsung, HTC en LG er al met smart op te wachten. Weten wij veel.

Tot slot: Loller kennende zou zijn mening heel snel kunnen omslaan als Microsoft deze ontwikkeling zou volgen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:07]

[aval0ne]

Ik ben benieuwd, maar begrijp nog steeds niet waarom we nu plots allemaal 64-bit nodig zouden hebben, alsof 32-bit voor een smartphone niet genoeg is...

Het gaat niet om de 64bits, het gaat om de extra voordelen van de ARMv8 instructieset.
Lees een willekeurige review van de iPhone 5s (bij voorkeur die van Anandtech) en je zal zien waarom de 64bits processor met ARMv8 nuttig is.

[bantoo]

Zou vrij triviaal moeten zijn, Android draait bijvoorbeeld ook op x86 en MIPS. Portabiliteit van de codebase zou goed zat moeten zijn.

[Jhinta]

Zou vrij triviaal moeten zijn, Android draait bijvoorbeeld ook op x86 en MIPS. Portabiliteit van de codebase zou goed zat moeten zijn.

Android draaid op dalvik --> dalvik draaid op een OS ->. OS draaid op welke CPU dan ook

Linux heeft al enige tijd 64 bit arm support het is dat dalvik en android zelf aangepast moeten worden

[Reactie gewijzigd door Jhinta op 23 juli 2024 18:07]

[Amanoo]

"draaid" is een verleden tegenwoordigheid, voor als het een pas geleden is gebeurd, maar wel zo actueel is dat het geen verleden tijd mag krijgen? Of een kwantummechanische superpositie tussen verleden tijd en tegenwoordige tijd? Het heeft in ieder geval een bijzondere uitgang die het Nederlands nog niet kende toen ik op het voortgezet onderwijs zat. Toen hadden we tegenwoordige tijd, verleden tijd en voltooid deelwoord. Mijn persoonsvormen in de tegenwoordige tijd hebben ofwel niets, ofwel een '-t', of wel '-en' als uitgang.

Maar het mag niet extreem veel moeite zijn. Android en Dalvik draaien inderdaad al op diverse platforms, dus enige portability zal wel aanwezig zijn. Wel gok ik dat Dalvik opnieuw gecompileerd moet worden, mogelijk met enige aanpassingen. Dalvik is namelijk in C++ geschreven, redelijk dicht bij de machine.(klik hier voor een serie cpp bestanden). Het zou redelijk zot zijn als Android weer de code waar Dalvik uit bestaat zou moeten interpreteren. Had je een interpreterception.

[Jhinta]

"draaid" is een verleden tegenwoordigheid, voor als het een pas geleden is gebeurd, maar wel zo actueel is dat het geen verleden tijd mag krijgen? Of een kwantummechanische superpositie tussen verleden tijd en tegenwoordige tijd? Het heeft in ieder geval een bijzondere uitgang die het Nederlands nog niet kende toen ik op het voortgezet onderwijs zat. Toen hadden we tegenwoordige tijd, verleden tijd en voltooid deelwoord. Mijn persoonsvormen in de tegenwoordige tijd hebben ofwel niets, ofwel een '-t', of wel '-en' als uitgang.

portability -> portabiliteit interpreterception > interpretexception -> interpret(eren) uitzondering, voor het ABN , of talen door elkaar halen is normaal.

[Reactie gewijzigd door Jhinta op 23 juli 2024 18:07]

[MSalters]

Nee. Twee problemen: Dalvik draait binnen Android, niet andersom.

Het grotere probleem is dat Dalvik een JIT compiler is. Het is niet handig als je JIT compiler wél op een 64 bits machien draait, maar alleen 32 bits instructies produceert. De markt voor JIT cross-compilers is vrij klein

Met andere woorden, er is nieuwe Dalvik code nodig die 64 bits code produceert.

[Jhinta]

Nee. Twee problemen: Dalvik draait binnen Android, niet andersom.

Het grotere probleem is dat Dalvik een JIT compiler is. Het is niet handig als je JIT compiler wél op een 64 bits machien draait, maar alleen 32 bits instructies produceert. De markt voor JIT cross-compilers is vrij klein

Met andere woorden, er is nieuwe Dalvik code nodig die 64 bits code produceert.

Dat heb je dus groten deels fout , zou maar is de boot proses na lezen .( mag jij me vertellen wanneer android dan in komt)
Android draait just in vm -> laat dat nou net dalvik zijn
en dalvik is een vm en jit , is just in time , in andere worden java naar bytecode .
dalvik heeft op dat opzicht weinig met bytecode(jit) te maken omdat je het niet nodig hebt om android te draaien( enkel een stuk trager ), jit maakt het enkel sneller , en voornamelijk apps met de risico dat het wel is fout kan gaan .

[Reactie gewijzigd door Jhinta op 23 juli 2024 18:07]

[Kingpinda]

Over enige tijd moeten de eerste smartphones uitkomen met een 64bit-soc.

incorrect. Er bestaan al smartphones met een 64bit-soc

edit:
En natuurlijk lees ik de laatste 2 posts niet want ik ben niet de enige die wakker is

[Reactie gewijzigd door Kingpinda op 23 juli 2024 18:07]

[Pataar]

Voor mij wordt het echt spannend als Microsoft aankondigd 64 bit te ondersteunen op WP 8.1. Natuurlijk duurt dat wéér een jaar. Microsoft is redelijk langzaam met de nieuwste technologieën te implementeren in hun Windows Phone.

[SomerenV]

Ja, want ze liepen gigantisch achter wat betreft optische beeldstabilisatie, draadloos opladen, nieuwe cameratechnieken, audio-opname, en vast nog wat meer dingetjes. Oh... wacht!

[Verwijderd]

Maar was het Nokia of Microsoft die dat heeft ontwikkeld? Microsoft heeft het OS geleverd, maar hoeveel ze gedaan hebben aan de rest? Maar goed, dat is verder volstrekt off-topic natuurlijk.

[slaapkop]

Audio opname ?
Call-recording is gewoon niet mogelijk. Een van de redenen waarom ik nog altijd een Android toestel heb naast mijn 920.

[aval0ne]

Ben ik nu de enige die het vreemd vindt dat je je eigen telefoongesprekken opneemt?

[OddesE]

Ja, want ze liepen gigantisch achter

Ehm ja. Optische beeldstabilisatie?? Come on dat is een software trucje, zo oud als de weg naar Rome. Overigens liepen ze wel voorop in de marketing ervan... Ehm.. reden ernaast met een bestelbusje.

Sorry maar ik vind Windows Phone er best mooi uit zien en ooit liepen zowel MS als Nokia ook echt voorop (zo rond de tijd van Windows Mobile) maar om nu nog te doen alsof dat zo is? De hele reden dat ze die camera pushten was omdat dat één van de weinige punten was waar ze nog wat tegenwicht konden bieden tegen het iPhone / Android geweld.

[Reactie gewijzigd door OddesE op 23 juli 2024 18:07]

[SomerenV]

Wat Nokia heeft gedaan met de Lumia 920 was geen softwaretrucje maar hardwarematige optische beeldstabilisatie. De lens 'hangt' in een harnas zeg maar, en geloof me, dat zie je terug in de filmpjes die je opneemt en de foto's bij weinig licht. Of het wel of niet in samenwerking gedaan is met Microsoft doet er niet toe, feit is dat Nokia het paradepaardje is/was van Windows Phone.

[Grrrrrene]

Maar optische beeldstabilisatie wordt nu gebruikt om te verdedigen tegen de bewering dat MS met WP8.1 achter de feiten aan loopt. Dat slaat nergens op, omdat het 0,0 met WP8.1 te maken heeft. Zou je Android of iOS op zo'n Lumia 920 (kunnen) zetten, dan hadden zij dezelfde voordelen van optische beeldstabilisatie.

[SomerenV]

Het ging over de nieuwste technologieën implementeren in telefoons, maakt niet uit of het nou software of hardware is toch? En besides, de nieuwste technologie is geen garantie voor succes

[Silmarunya]

Je kunt optische beeldstabilisatie bezwaarlijk nieuwe technologie noemen, elk degelijk fototoestel heeft het al tijden.

[SomerenV]

Niet in het formaat waarop je het momenteel vindt in smartphones In dat opzicht was het wel degelijk nieuwe technologie, althans, voor smartphones. Zoiets is nou eenmaal niet makkelijk voor elkaar te krijgen.

[Martinspire]

Voor smartphones was optische beeldstabilisatie wel redelijk uniek. Zeker op de schaal waarop Nokia het heeft toegepast. Dus in die zin zeker een technisch hoogstandje.

Toch blijven zaken als draadloos laden wel eerder bij een smartphone OS dan anderen. Samsung is dat ook pas later gaan doen. Of het kunnen gebruiken van je smartphone met eender welke handschoenen. Al komt dat ook natuurlijk omdat Nokia in Finland zit.

[Pataar]

Dat is nokia. Ik ben geen hater maar juist een Windows/Nokia fanboy.

[Verwijderd]

Ik zou dat dus weer totaal niet spannend vinden maar goed Is een mening.

[Pasteis]

Pataar ze zijn daarin aardig aan het inlopen, het feit dat WP8.1 niet de allernieuwste processor nodig heeft, lijkt me genoeg te zeggen! De allernieuwste die ze gebruiken is de Snapdragon 800, een 801 is natuurlijk bullshit!

Kijk echt uit naar de 64 bit processors, daarom wacht ik denk ook nog een tijdje voordat ik een nieuw toestel neem.

[Pataar]

Tussen de prestaties van de S800 en S801 zit nauwelijks verschil. De S801 is alleen een stuk veiliger. Ik geef je wel gelijk dat windows phone weinig speciaals nodig heeft voor goed te kunnen presteren. Op de 720 met 512MB ram draait het ook als een zonnetje.

[RebelwaClue]

En hun tablets waren al 64bits. Dus hoezo lopen ze achter.

[blottle]

Ik denk dat google verrast was door de introductie van een 64 bits iphone, waardoor ze nu snel ook 64 bits processoren moeten gaan ondersteunen.

[Verwijderd]

Je wordt gedownmod maar je hebt in wezen wel gelijk. Ik denk dat dit tenminste een van de redenen is waarom ze dit doen. Voor de gemiddelde consument is 64 bit namelijk gewoonweg beter dan 32 bit, en volgens dat idee loopt het Android ecosysteem wel een achterstand op als ze niet nu al met 64 bit gaan beginnen.

[blottle]

Ik denk dat veel niet weten dat Google dit totaal niet had verwacht, net als de samsungs en andere telefoonmakers. Google kan zijn android pas 64bit maken wanneer de instructie set van de 64bit processoren bekend zijn. Nadat Apple de 64 bit iPhone heeft gepresenteerd zijn de chipmakers heel hard gaan werken aan de 64 bit chips en dus kan Google nu pas beginnen met het aanpassen van de android code.

[stewie]

de 64bit variant van ARM bestond al een paar jaar, dus dat van die instructie set is pure onzin.
er was gewoon geen enkele financiële reden om 64bit te implementeren, en ja de iPhone is 64bit en nee je hebt er geen drol aan tot ze dingen met 8GB aan systeem geheugen gaan verschepen (de iPhone heeft nog steeds maar iets van 2GB, dus het nut er van is echt extreem minimaal)

[koelpasta]

"er was gewoon geen enkele financiële reden om 64bit te implementeren, "

Klopt, bij de vorige generaties waren de 64 bit modellen duurder dan de 32 modellen. Deze generatie echter wordt verwacht dat de 64 bit cpu's meer gaan verkopen dan de 32 bit cpu's waardoor ze ook goedkoper gaan worden dan de 32 bit varianten.

"en ja de iPhone is 64bit en nee je hebt er geen drol aan tot ze dingen met 8GB aan systeem geheugen gaan verschepen (de iPhone heeft nog steeds maar iets van 2GB, dus het nut er van is echt extreem minimaal) "

Dit is niet waar. de nieuwe architectuur heeft juist een hoop voordelen die helemaal niks met de hoeveelheid bits te maken hebben.
De nieuwe 64 bit cpu's zijn dus een stuk beter ook al draaien ze geen 64 bit code.

[Amanoo]

Ik denk dat er ineens 64-bit Snapdragons werden aangekondigd, en dat Google besloot dat het ondersteunen van veelgebruikte SoC-series wel handig kan zijn. Dat doet Google niet omdat Apple het doet, maar omdat de nieuwste telefoons binnenkort anders geen Android kunnen draaien. Heel misschien dat Qualcomm het nodig vindt Apple na te volgen in hardware, maar voor Google is het enige belangrijke dat alle smartphone-platforms ondersteund worden. Als hardwarebakkers ineens besluiten dat 64-bit een platform moet zijn, dan moet Google daar in mee gaan.

[Amanoo]

Was op zich wel al tamelijk bekend nieuws. Het was misschien niet officieel aangekondigd, maar aangezien het wel al bekend was dat we binnen redelijke tijd Snapdragon 810 SoC's in smartphones zouden gaan tegenkomen kan je op je klompen aanvoelen dat Google graag Android op deze smartphones wil hebben.