Google: niet alle Android-apps werken goed op Googlebooks met Intel-processors

Google zegt dat niet alle Android-apps goed werken op Googlebooks met Intel-processors. Ontwikkelaars moeten daarvoor aanpassingen doen. Tot nu toe is alleen aangekondigd dat de Intel-modellen in Nederland en België uitkomen.

Veruit de meeste apps draaien wel goed op Intel-processors, zegt Google tegen Android Authority. "Omdat veel Android-apps oorspronkelijk voor Arm-chips zijn ontworpen, hebben enkele complexe apps of games aanpassingen van ontwikkelaars nodig om optimaal te presteren op platforms met Intel-processors. We werken nauw samen met appontwikkelaars, Intel en Qualcomm om de prestaties voortdurend te optimaliseren en de compatibiliteit binnen het volledige portfolio te vergroten."

Onbekend welke apps

Drie van de vijf aangekondigde Googlebooks hebben een Intel Core Ultra-processor. Dat zijn ook de drie modellen van Acer, ASUS en Lenovo die begin december uitkomen.

Android-telefoons hebben allemaal Arm-processors en de apps zijn dus voor die processorarchitectuur gemaakt. Google zegt niet welke apps slecht of niet werken op de Intel-versies van de Googlebooks.

Googlebooks?

Acer, ASUS, Dell, HP en Lenovo brengen deze week in diverse landen de eerste Googlebooks uit. Google heeft Android geschikt gemaakt voor laptops door onder meer de interface aan te passen en taakbeheer en een terminal toe te voegen. Het gaat in alle gevallen om dure laptops. De Acer Googlebook 14 komt in december uit in Nederland en België voor 1299 euro. ASUS brengt zijn Googlebook 14 ook in december uit voor 1349 euro. Die van Lenovo gaat 1499 euro kosten.

Googlebooks

Reacties (25)

[The Zep Man]

Onbekend welke apps
(...)
Android-telefoons hebben allemaal Arm-processors en de apps zijn dus voor die processorarchitectuur gemaakt.

Dat klopt niet helemaal. Verreweg de meeste applicaties zijn geschreven om op een interpreter ("virtual machine") te draaien. Zonder native component draaien die prima op een x86-CPU end op iedere andere architectuur waarvoor de interpreter beschikbaar is.

Het probleem betreft dus applicaties die wel een native component hebben en die dat native component niet meeleveren voor x86. ARM is de eerste en vaak enige keuze. Dat is logisch, gezien Android op x86 tot nu toe een uitzondering betreft.

[Reactie gewijzigd door The Zep Man op 6 oktober 2026 12:22]

[kiang]

Ze zijn misschien platform-agnostisch geschreven, maar veruit de meeste apps compileren wel op zijn minst een gedeelte van de split-apk naar arm-native code en dat is wat je uit de play store krijgt. Kan je zelf nakijken btw met het commando "adb shell pm path {package naam van app}"

Laten we even enkele populaire apps nemen, en kijken of ze een split apk met arm-spcifieke code hebben:

• WhatsApp: base.apk, split_config.arm64_v8a.apk, split_config.xxhdpi.apk, split_i18n_nl.apk
• Firefox: base.apk, split_config.arm64_v8a.apk, split_config.xxhdpi.apk
• Tikkie: base.apk, split_config.arm64_v8a.apk, split_config.xxhdpi.apk
• ING app: base.apk, split_config.arm64_v8a.apk, split_config.xxhdpi.apk
• DigiD: base.apk, split_config.arm64_v8a.apk, split_config.en.apk, split_config.nl.apk, split_config.xxhdpi.apk

Na even rond te neuzen kon ik op mijn toestel geen enkele app vinden met een universele apk, behalve dan de Telegram APK die ik vanaf hun website downloadde als test.

De meeste developers leveren dus alsnog platform-specifieke code aan de playstore. De vraag is of de bovenstaande app developers de apps paltform-agostisch hebben ontwikkeld en simpelweg native builds hebben aangeleverd en daarbij ook x86 versies hebben getest en gebouwd. Persoonlijk denk ik wel dat de meeste agnostisch ontwikkelen, en ook x86 builds uitleveren, maar of die getest zijn durf ik oprecht te betwijfelen omdat x86 bij android zo een niche is.

[Reactie gewijzigd door kiang op 6 oktober 2026 13:23]

[karelb1984]

Sinds enige tijd worden apps overwegend als Android App Bundle (aab) en niet meer als universal apk gepubliceerd op Google Play. Wanneer je een app uit Google Play installeert, dan wordt er vanuit de aab een of meerdere APKs gegenereerd met daarin alleen voor jouw device relevante resources. Als je de APKs op je eigen arm64 device hebt geanalyseerd dan is het te verwachten dat je er alleen arm64 relevante code in vindt.

Ik verwacht ook dat grote apps als Whatsapp gewoon voor x86 of x86_64 beschikbaar zijn, maar die zul je dus alleen vinden wanneer je het daadwerkelijk draait op een x86 device.

[GertMenkel]

In het begin wel, maar eigenlijk heeft iedere APK die ik uit elkaar trek wel ergens een native library die een hoop werk afhandelt. Juist vroeger, toen Intel nog een poging deed een mobiele chip te maken en er zelfs nog MIPS-chips ondersteund werden, was dit logischer.

Tegenwoordig is Android bijna alleen maar aarch64 (niet eens ARMv7 meer) en zijn apps daar ook op gebouwd.

In principe zou dit allemaal nog moeten kunnen werken als Google ervoor zorgt dat iets als FEX naar hun ChromeOS-distro komt. Net als de Steam Frame is Google's OS niet anders dan een specieke laag bovenop Linux, de techniek zou moeten kunnen werken (met wat frameverlies bij de spelletjes, wellicht).

[2Keys]

Man man man, je hebt als Google de mogelijkheid om al je fouten van de Chromebook recht te zetten en voordat je product gereleased is zit het al vol met fundamentele problemen.

Ik zou graag hebben willen zien wat er door het hoofd van de productowners ging toen ze bezig waren met de gemaakte keuzes.

[GurbieV]

Een paar apps doen het niet, dat lijken me nou niet gelijk fundamentele problemen. Daarbij is t ook oplosbaar, en zijn diverse partijen er al mee bezig.

Oftewel over een maandje is t gefixt.

[Luchtbakker]

Een paar apps doen het niet, dat lijken me nou niet gelijk fundamentele problemen. Daarbij is t ook oplosbaar, en zijn diverse partijen er al mee bezig.

Oftewel over een maandje is t gefixt.

Vind ik erg makkelijk over gedacht. Want ik moet nu als dev weer mijn apps gaan aanpassen terwijl Google het met een fatsoenlijke emulator ook prima had kunnen oplossen. Dit is gewoon laksheid van Google die het zoals altijd weer lekker in de schoenen van de ontwikkelaars duwt.

[watercoolertje]

Of je biedt het gewoon niet aan aan die gebruikers?

Je bent helemaal niet verplicht tot het ondersteunen daarvan. Zolang de gebruiker de app dan niet ziet is er niet zo veel aan de hand, tenzij je toevallig de heilige graal hebt waar niemand zonder kan, maar dan ontstaan er wel alternatieven om dat gat te vullen.

Daarnaast weten we niet hoeveel apps het zijn, moet Google een emulator gaan schrijven voor 1 app? 5 apps? 10? 100? 1000?

[necessaryevil]

Ik vraag me af hoe makkelijk f je die native apps kunt vertalen. Ik heb welleens gelezen dat je voor het echt goed emuleren van dacht een SNES een 1 GHz cpu nodig hebt. Aan de andere kant, toen waren trucjes in assembly nog normaal. En Apple is het destijds met de overstap naar x86 ook gelukt met rosetta. En met de overstap van x86 naar ARM volgensmij ook. Maarja, Apple is vaker geswitched tussen instructiesets, dus misschien is de software voor hun platform wel beter geschikt om op een emulator te draaien.

//edit
Toen Apple overstapte naar x86 ontwikkelde de hardware zich nog wat sneller, en snelle hardware compenseert de overhead van een compiler ook nog.

[Reactie gewijzigd door necessaryevil op 6 oktober 2026 12:41]

[watercoolertje]

Lekker overdreven!

Appmakers moeten het oplossen indien ze hun app beschikbaar willen hebben op die GoogleBook(s). Google (play store) heeft ook gewoon een curated list waarbij je (meer) zekerheid hebt dat alles werkt, maar als je daarbuiten gaat zoeken naar een app, ja dan kan er een issue zijn, lijkt me vrij logisch dat ze niet meer dan 1 miljard apps gaan testen

Beetje zoals je games ook specifiek SteamDeck-compatbile kan laten taggen in Steam, je kan als gebruikers ook apps die mogelijk niet werken installeren, dat is dat volledig je eigen keus.

[YGDRASSIL]

Waarom is het een google probleem als bedrijf x zijn android app niet zo maakt dat ie op andere platformen ook werkt?

[2Keys]

Bedrijf X kondigt niet aan dat al haar apps op googlebooks werken.

[Reactie gewijzigd door 2Keys op 7 oktober 2026 08:46]

[YGDRASSIL]

Je zin is onduidelijk? Google geeft aan dat niet elke app in de appstore goed werkt op Intel. Dat is gewoon een mededeling. En per app van derden dus eventueel een issue. Waarbij de app eigenaar dat moet fixen.

[jb044]

Yup, datzelfde probleem heb ik met waydroid op mijn Linux. Ooit mee begonnen omdat ik toen een bepaalde game veel speelde, toen ik het eindelijk aan de praat had bleek die game dus arm only 😃

[Soldaatje]

Dat probleem heb ik ook helaas, bepaalde apps kunnen niet draaien. Misschien met qemu arm emulatie wel maar dat zal te traag zijn.

[Vizzie]

Is dit echt een probleem voor Google?

Het lijkt me sterk dat er zoveel mensen per sé die apps die het niet doen op een intel googlebook zouden willen draaien. Sowieso heb ik zelf nooit dat ik denk: wat zou het fijn zijn als deze app op m'n telefoon op m'n laptop werkte.

Het zal vast voorkomen, maar ik denk dat het gros liever een app gebruikt die voor de laptop ontworpen is.

[dabachata]

Nog niet genoemd volgens mij, maar op een Googlebook kan je Apps ook streamen vanaf een Android 17 Smartphone, en zo via een omweg ook apps gebruiken die niet (fijn) op een Intel Googlebook werken. Hoe soepel dat streamen werkt in realiteit weet ik niet. Ik weet ook niet of je daarbij een andere layout kan kiezen (landscape/tablet/laptop layout).

De eerste enigzins gedetailleerde just-out-of-the-box video's zijn pas gisteren geplaatst op YouTube, vanwege embargo tot 4 oktober.

[beerse]

Iets zegt mij dat de apps die op de intel-googlebooks niet werken de zelfde zijn die in mijn intel-gebaseerde chromebook niet als android-app kunnen worden geladen/gestart. De 'nettere' melden netjes dat het platform niet wordt ondersteunt, de mindere goden installeren gewoon niet of installeren wel maar draaien daarna gewoon niet.

[rolf-smit]

Hoi Android developer hier!

Ik zie best veel reacties met informatie die soms net niet helemaal klopt, dus ik dacht ik deel even mijn kennis, dan wel mijn mening.

@The Zep Man Dat klopt niet helemaal. Verreweg de meeste applicaties zijn geschreven om op een interpreter ("virtual machine") te draaien. Zonder native component draaien die prima op een x86-CPU end op iedere andere architectuur waarvoor de interpreter beschikbaar is.

Dit is heel discutabel, en ik durf het tegenovergestelde te claimen. Het klopt dat de meeste applicaties op Android geschreven worden met eigenlijk alleen interpreteerbare code, echter trekken de meeste apps tegenwoordig extreem veel dependencies binnen, waaronder officiële Google SDKs, die intern vaak naast interpreteerbare code ook native code shippen. Denk bijvoorbeeld aan de androidX `media3` packages, `datastore`, `sqlite-bundled`, bepaalde Compose graphics dependencies, deze worden allemaal veelvuldig gebruikt. Daarnaast zijn er veel third-party dependencies die intern gebruik maken van native code, denk bijvoorbeeld aan cryptografie, of OpenCV en dat soort zaken.

TLDR: Veel Android apps leunen en shippen gewoon op native binaries, dan wel bewust, dan wel onbewust.

@kiang De meeste developers leveren dus alsnog platform-specifieke code aan de playstore. De vraag is of de bovenstaande app developers de apps paltform-agostisch hebben ontwikkeld en simpelweg native builds hebben aangeleverd en daarbij ook x86 versies hebben getest en gebouwd. Persoonlijk denk ik wel dat de meeste agnostisch ontwikkelen, en ook x86 builds uitleveren, maar of die getest zijn durf ik oprecht te betwijfelen omdat x86 bij android zo een niche is.

Dit klopt dus, de meeste apps hebben ook platformspecifieke native code (zoals eerder al uitgelegd). Of developers er ook echt actief mee bezig zijn om agnostisch te ontwikkelen? Dat is denk ik wat meer een 50/50 split, veel Android ontwikkelaars, en met name de minder ervaren ontwikkelaars snappen soms zelf niet eens de in- en outs van native code in Android apps. Maar de tooling van Google (meestal via de Android Gradle Plugin), lost eigenlijk de meeste problemen voor je op, standaard worden native binaries die mee komen via dependencies gewoon voor alle beschikbare architecturen in een App Bundle gestopt die naar de Play Store gaat. Je moet dat gedrag moedwillig uitschakelen als je bijvoorbeeld x86 code wil uitsluiten. De nuances beginnen wellicht wanneer je zelf native code gaat schrijven (en gebruik gaat maken van de NDK), maar er zijn maar weinig apps waar dat heel normaal is.

@GertMenkel Tegenwoordig is Android bijna alleen maar aarch64 (niet eens ARMv7 meer) en zijn apps daar ook op gebouwd.

Klopt de meeste telefoons zijn aarch64, maar de meest populaire dependencies (zeker die van Google zelf), bevatten gewoon native binaries voor verschillende architecturen waaronder x86, dus je zou eigenlijk geen problemen verwachten. Apps zijn dus niet per se gebouwd om alleen aarch64 te ondersteunen.

Daarnaast, als je als Android ontwikkelaar op Windows ontwikkelt, ben je constant x86 aan het testen, want idealiter draait je emulator op x86 (iets met performance), op een M serie MacBook is dat natuurlijk een ander verhaal, dan draait je emulator weer op ARM en test je x86 dus niet automatisch al een beetje mee.

@Luchtbakker Vind ik erg makkelijk over gedacht. Want ik moet nu als dev weer mijn apps gaan aanpassen terwijl Google het met een fatsoenlijke emulator ook prima had kunnen oplossen. Dit is gewoon laksheid van Google die het zoals altijd weer lekker in de schoenen van de ontwikkelaars duwt.

Dit is een statement waar ik het niet mee eens ben als Android ontwikkelaar. Google/Android vertelt ontwikkelaars al vanaf dag 1 dat het belangrijk is om na te denken over de native binaries en architecturen die je app ondersteunt, ook de tooling is al sinds jaar en dag hier helemaal omheen gebouwd. Gebruik je standaard Android SDK's en ontwikkel tooling, dan kost dit niet eens extra moeite. Dit is gewoonweg hoe Android al meer dan 18 jaar werkt: je app kan meerdere CPU architecturen ondersteunen, en dat is ook de verwachting. Er is helemaal geen emulatie nodig.

Maar, hier is een fun fact: zo'n emulatielaag bestaat dus al wel, in de vorm van `libnativebridge` en `libndk_translation`, en zit standaard in de meeste Chromebooks ingebouwd. Maar zo'n translatielaag is gewoon niet perfect, en heeft zo zijn nadelen en nuances.

(Waar ik in deze reactie over x86 spreek, maakt het voor het principe niet uit of dat nou 32 of 64-bit is, maar 64-bit is in de praktijk wel de norm)

[Reactie gewijzigd door rolf-smit op 6 oktober 2026 19:16]

[killerdemon]

Wat is hier nieuw aan?

Er waren al eerder (goedkope) Android tablets met x86 CPU's die niet alles draaiden..

[LootersV]

Ik vergelijk dit even met Rosetta2 dat zo goed werkt dat veel developers in de afgelopen 6 jaar nooit hun apps native ingediend hebben. Echter zaten op Rosetta2 wellicht meer of betere programmeurs, en het budget zal ook ongetwijfeld hoger geweest zijn. Dan is het normaal dat je een ander resultaat krijg.

Ik zie echter nog steeds niet het nut van een Googlebook in, net zoals ik niet het nut van een android tablet zie voor productiviteit; behalve enkele apps is het meeste gewoon een opgeblazen telefoon app. Als mensen dit niet echt trekken op een android tablet van 500 euro, waarom dan wel ineens op een laptop van 1500 euro?

[watercoolertje]

Dit is niet te vergelijken met Rosetta2, die laag is er juist niet in dit geval. Overigens werkte dat (zeker in het begin) ook helemaal niet altijd , niet elke instructie van X86(-64) is om te zetten naar een ARM instructie.

Uiteindelijk moet je dat ook helemaal niet willen zo'n lapmiddel. Je wilt gewoon apps die niet voor je architectuur zijn blokkeren, dan is het aan de ontwikkelaar om het om te zetten!

Ik zie echter nog steeds niet het nut van een Googlebook in, net zoals ik niet het nut van een android tablet zie voor productiviteit; behalve enkele apps is het meeste gewoon een opgeblazen telefoon app.

Er zijn best veel (android) apps die wel degelijk goed voor een tablet gemaakt zijn, jouw vertekende beeld en de conclusie die je er dan aan hangt is niet perse de realiteit.

En zelfs de apps die als smartphone-apps openen werken gewoon goed en bruikbaar, enige nadeel is dat het menu vaak onder een knop zit ipv ernaast staat, nou whoop die whoop, de horror

Als mensen dit niet echt trekken op een android tablet van 500 euro

Hoe kom je er bij dat mensen het niet trekken?

[Reactie gewijzigd door watercoolertje op 6 oktober 2026 11:01]

[oef!]

Er zijn veel bedrijven die gebruik maken van Google Workspaces, voor hen is een premium laptop die aansluit op het Google ecosysteem interessanter dan voor de gemiddelde consument.

[arnoldus1955]

Overigens is Rosetta2 niet meer standaard aan in de laatste macOS (v27), en vanaf volgend jaar wordt het zelfs niet meer geleverd (macOS 28)