Google halveert aantal releases Android-broncode naar twee keer per jaar

Google gaat de broncode van Android nog maar twee keer per jaar uitbrengen, in plaats van de vier keer in de afgelopen jaren. De reden is dat dit beter aansluit op de 'trunk'-ontwikkelmethode van Android.

Door die 'trunk'-ontwikkelmethode komt het beter uit om de Android-broncode twee keer per jaar uit te brengen: in de lente en in het najaar. Tot nu toe kwam er een nieuwe versie van de broncode uit met elke kwartaalrelease.

Het nieuwe ritme moet het voorspelbaarder en makkelijker maken voor ontwikkelaars, die zich voortaan kunnen richten op android-latest-release in plaats van android-main. Wel wordt het lastiger om te zien waar Google aan werkt in Android. De beveiligingsupdates blijven wel maandelijks komen.

Veranderingen in Android AOSP
Veranderingen in Android AOSP

Door Arnoud Wokke

Redacteur Tweakers

07-01-2026 • 09:21

79

Submitter: KipKroket

Reacties (79)

Sorteer op:

Weergave:

"De beveiligingsupdates blijven wel maandelijks komen."
Dit is al niet meer het geval zoals het eerder was. Eerder kreeg elke fabrikant telkens de maandelijkse patches een maand van te voren onder embargo. Veel fabrikanten liepen erg achter met beveiligingsupdates. Daarom krijgen fabrikanten nu al 3 maanden van te voren de patches. Het embargo is nu wel alleen op de sourcecode, fabrikanten mogen al wel binnen de 3 maanden de updates zonder source releasen. Maar er zijn er maar enkelen die dit doen en dan vaak ook niet de complete patches.
Bijkomend gevolg van dit alles is dat er nog wel elke maand een security bulletin komt, maar de meeste fixes komen maar eens in de 3 maanden. Daartussen zijn de maandelijkse bulletins vaak leeg of bevatten ze een enkele fix voor een kritiek lek dat actief misbruikt wordt. En dit alles zorgt er alleen voor dat fabrikanten beter voor de dag komen omdat ze makkelijker een actueel patch level kunnen bijhouden. Terwijl updates minder vaak komen en opensource ROMs het helemaal lastig krijgen.

[Reactie gewijzigd door Matthijs8 op 8 januari 2026 09:59]

Dit is zo onverantwoordt ten opzichte van de eindgebruikers. Je bent zo als je pech hebt zo'n 3 maanden, of misschien wel langer, kwetsbaar voor 'bekende' kwetsbaarheden. Binnen GrapheneOS heb je in ieder geval de optie "Receive security preview release" waarbij je de kans hebt om eerder toegang te krijgen tot security patches via alternatieve release channels. Wat meer info via https://discuss.grapheneos.org/d/27068-grapheneos-security-preview-releases
Ik vind het inderdaad ook erg slecht. Een enorm groot aantal bedrijven en personen heeft toegang tot deze early releases dus de sourcecode kan ook snel uitlekken om exploits te ontwikkelen. En die binary releases zonder source schijnen ook vrij makkelijk te reverse engineeren naar source code, waardoor nog een veel groter aantal partijen hiervoor exploits kan ontwikkelen. Dat hele embargo is een wassen neus.
Zelf gebruik ik gelukkig ook GrapheneOS met de security preview release, maar 99,99% van Android gebruikers gaat natuurlijk achteruit met dit beleid..
Schattig hoe ze proberen over te brengen alsof ze dit voor het bestwil van ontwikkelaars doen en denken dat er een levende ziel op aarde is die dat geloofd O+

Dit is trouwens niet vanaf nu, hier waren ze vorig jaar al mee begonnen. Enige verschil is dat ze het nu toegeven ipv smoesjes gebruiken als "komt binnenkort, z.s.m., vertraagd" enz. Je kan in de blog van LineageOS het effect ervan lezen: https://lineageos.org/Changelog-30/

[Reactie gewijzigd door HakanX op 7 januari 2026 10:11]

Stel je werkt als bank aan een NFC-app. Dan loop je dus een half jaar achtesrand op tov Google?
Het lijkt me niet dat een bank de broncode zelf nodig heeft om de app te ontwikkelen.
Enkel de beschrijving van de api's en een ontwikkelomgeving waarin die api's aangeroepen kunnen worden.

Het zijn eerder de ontwikkelaars van telefoons die hierdoor op achterstand gezet worden, t.o.v. de Google Pixel. Zij moeten Android met de hardware integreren en vaak ook nog combineren met een eigen launcher, die vaak fungeert als aangepaste UI van Android, met extra mogelijkheden, en niet zo zeer als een app die bovenop Android draait.

En natuurlijk de ontwikkelaars van de niet-Google versies van Android. Die worden hierdoor op nog meer achterstand gezet.
Ik denk dat de beschrijving 'Het zijn de ontwikkelaars van telefoons die geen overeenkomst hebben met Google op achterstand gezet worden.' accurater is. Het geldt alleen voor AOSP Android.

Een bedrijf als Samsung werkt samen met Google. Hun Samsung OneUI Android maken ze in samenwerking met Google. Ze krijgen de sources van Google, niet via AOSP Android code releases.
Dat is volgens mij een van de redenen dat geen van de banken zelf meer iets ontwikkelen op dat gebied maar allemaal naar Google Wallet gegaan zijn. Tot mijn grote verdriet overigens.
Waarom, Google Wallet werkt toch prima? De apps van de meeste banken zijn om te janken zo slecht.
Aangezien Google geen bank is kunnen ze alles met de data doen wat ze willen. En de opsporingsdiensten in de USA kunnen ook in deze data grabbelen. Moet je zelf weten. Maar ik pas.
De US zal u geld niet afnemen... De EU daarentegen...
Omdat niet iedereen de voorwaarden van Google wil accepteren om een smartphone te gebruiken.
En mogelijke transactiekosten. Mogelijk niet in Nederland maar toch, wat niet is gaat toch komen.
Heel specifiek scenario, India + vaste lasten huis maargoed wel een voorbeeld inderdaad waarom de keuzes beter moeten zijn dan met nfc je bank betalen via Google Pay of geen nfc kunnen gebruiken waar het nu effectief op neer komt.
Ooit geprobeerd om Google Wallet op GrapheneOS te installeren? Ik kan je zeggen.. Google Wallet werkt niet altijd prima.. of gewoon.. at all.
Waarom, Google Wallet werkt toch prima? De apps van de meeste banken zijn om te janken zo slecht.
Nooit issues gehad met ING, dat andere banken hun zaakjes niet op orde krijgen is niet hun probleem.

Overigens heb ik niet echt het idee dat die updates ook maar iets met NFC te maken hebben zoals @TheMak zegt, een NFC-app gebruikt gewoon de API en die is er gewoon, daar hoef je geen half jaar op te wachten. Die wordt als het nodig is ook gewoon vaker geupdate en heb je de achterliggende code helemaal niet van nodig, dat is het hele idee van een API :P

[Reactie gewijzigd door watercoolertje op 7 januari 2026 11:33]

Je bent waarschijnlijk niet bekend met het proces van enshitification.
Zeker wel, maar ik heb een even grote hekel aan banken als aan big tech. Dus of je nu door de hond of de kat wordt gebeten. Who cares.
Ik gebruik Curve, wat zich nu Curve Pay noemt precies om zich te positioneren als alternatief voor Google Pay en Apple Pay.

Met het voordeel dat je niet alleen via je telefoon, maar ook met een fysieke kaart alle achterliggende kaarten kan gebruiken. Dus ook de virtuele kaarten van gratis banken ;)

Ook Openbank biedt nog zijn eigen "Contactless pay"-optie aan onder Android, maar dan heb je een Spaans rekeningnummer en Spaanse, eh... manier van bankieren (nogal archaïsch in communicatie).
Volgens mij had ik ooit van curve gehoord maar toen niet geprobeerd. Ik ben nu wel benieuwd, privacy policy ziet er in ieder geval zeer transparant uit dat lijkt positief. Alleen sign up gaat vaak niet goed volgens de reviews.
Ik denk dat deze kwestie andere oorzaken heeft. Je hebt AOSP source echt niet nodig om je bank app met nfc te laten werken.

Voor banken is het vrij zeker veel makkelijker om een add to Google Pay/wallet toe te voegen dan een eigen nfc methode die inhaakt op de android api. De implementaties die ik bij banken los heb gezien waren dramatisch, of dat lag aan de bank, android (api) of iets daar tussenin durf ik niet te zeggen. Verder voor zover ik weet zit je aan 1 nfc/bank app vast voor payments als een bank het implementeert, dus het is of bank 1 of bank 2 etc. Weet niet hoeveel banken/kaarten anderen hebben, maar zeker in combinatie met het buitenland heb ik tenminste 2 verschillende banken nodig waarmee ik kan betalen. Ja dat kan ook met de echte kaarten maar sommige zijn bijvoorbeeld ook Virtual only kaarten.

Verder wel eens dat afhankelijk zijn van Google Pay om met je telefoon te betalen niet optimaal is. Ik zou het liefst een framework zien wat gewoon werkt zoals dat de banken het zelf aanbieden maar dat je wel net voor of tijdens payment makkelijk kan kiezen/switchen tussen betaalmethoden/banken
Het gaat bij Android altijd met API's die je aanroept, en daar zit gewoon een termijn aan waarop wijzigingen aangekondigd worden, en blijft een backwards comptabiliteit actief, want anders stoppen alle apps ineens te werken bij een nieuwe release van Android.

Enige achterstand die je hebt is eventuele nieuwe functionaliteit waar je pas na 6 maanden achter komt dat die toegevoegd wordt, en Google dat al klaar heeft voor zijn telefoons en apps, maar jij nog aan moet gaan werken om dat te integreren. Maar eigenlijk gebeurt daar al enkele jaren niets spannends meer op.
Is nu het moment om een publieke fork te maken zodat de broncode beschikbaar blijft als ze volgend jaar besluiten om deze helemaal onbeschikbaar te maken?
Nee, in dat theoretische geval zou dat nu ook wel kunnen. Daarnaast verwijderd Github ook forks van verwijderde repo's, als Google Android niet meer Open source (of source available, ik ken de license niet) maakt ben je dus alsnog je forks kwijt. Je zou het dan sowieso moeten "kopieren" ipv echt forken of naar een andere git provider forken oid.
Forks van verwijderde repositories worden niet verwijderd op GitHub. De oudste fork wordt gewoon de nieuwe upstream repository voor alle andere bestaande forks. Idem dito voor het veranderen van public naar private.

[Reactie gewijzigd door Loller1 op 7 januari 2026 09:43]

En anders hebben we altijd de Software Heritage nog. Die hebben al best veel gearchiveerd staan, ook projecten die inmiddels verwijderd zijn van GitHub (gek genoeg ook projecten die via een cease and desist van GitHub zijn verwijderd)
waarom gebruiken we github dan?

is er niks anders wat gebruikt kan worden svn of wat dan ook :O
Als je blieft geen SVN meer, wat een hel was dat!

Anyway met git(lab/hub/etc het is allemaal gewoon git-protocol) kan je gewoon de code lokaal trekken (een checkout doen op de repository, dan heb je een copy van de repository/branch lokaal op je eigen PC). Ze kunnen enkel de fork die bij hun op de server staat verwijderen (al zie ik geen enkel bewijs dat die opmerking klopt) maar niet wat je lokaal op je PC hebt natuurlijk.

Mensen die Google niet vertrouwen dat het opensource blijft gaan toch niet vervolgens hun fork/backup (enkel) in de cloud bewaren, dan ben je nog steeds afhankelijk van de grillen van een ander :Y)

[Reactie gewijzigd door watercoolertje op 7 januari 2026 11:26]

ook al zou github dat doen (forks verwijderen)

dat heeft heel heel weinig zin, er hoeft maar 1 developer te zijn die de git checkout lokaal heeft staan en die pushed het gewoon naar een new git repo op github...
Ik zie er meer brood in om support achter wat anders te zetten, zoals Sailfish.
Precies mijn gedachten. Als we gewoon lekker stoppen met Android zijn we in 1 klap van Google af, in plaats van dat we moeten doormodderen met "ontgooglede" versies en workarounds om apps te draaien die van Google API's afhankelijk zijn. Ik hoop dat Sailfish eindelijk eens geport gaat worden naar meer apparaten. Niet iedereen heeft een Sony Experia...
Leuke idealistische gedachte, maar hoeveel % van de wereld denkt dit? Dat gaat geen zoden aan de dijk zetten, zelfs niet als een paar miljoen mensen over gaan.
Rusland was al eerder over op Aurora OS, wat gebaseerd is op SailfishOS, omdat ze niet van Amerika afhankelijk wilden zijn.
Dat is een communistisch land wat makkelijk z'n bevolking kan opdwingen wat wel en niet te gebruiken. Dán werkt het. Hier zie ik dat niet zo snel gebeuren, helaas. En ik zeg helaas, omdat Amerika een wereldwijde ramp is voor de wereldvrede. Word tijd dat de rest op staat en ook massaal Amerika gaat boycotten. Maar goed, misschien is dat ook wel een leuke idealistische gedachte...
In welk jaar leef jij? Rusland is ongeveer zo'n 30 jaar niet meer communistisch. Het is een oligargische autocratische dictatuur met een vorm van kapitalisme.
En in aanvulling op wat Kerfuffle 10 minuten geleden al zei, in China is Huawei's HarmonyOS inmiddels populairder dan iOS. Het kan dus wel degelijk. Zolang Trump maar ruzie blijft zoeken worden Amerikaanse partijen steeds minder betrouwbaar en zullen meer mensen weg willen van de Amerikaanse ecosystemen. Hoe meer er overstappen, hoe krachtiger een platform wordt.
Ik zei het al in een andere reactie: zolang wij slappe politici hebben zonder daadkracht en weigeren te zeggen "zo gaan we het doen", gebeurt er niks. Zie ook Anonymoussaurus in 'Google halveert aantal releases Android-broncode naar twee keer per jaar'.
Dat was inderdaad een beetje de kern.
Google's grip op android is dusdanig dat je eigenlijk beperkt wat aan android hebt als je niet gewoon meedoet aan al die Google poeha.

Graphene is leuk, maar ze hebben nogsteeds geen Pixel 10 release, en het aantal apps die leunen op die integrity API en ook meer willen dan alleen basic integrity (en dus niet meer werken op een "ontgoogle" telefoon met of zonder sandboxed playstore) groeit.
De praktische bruikbaarheid van zo'n alternatieve rom vertooont inmiddels best wel wat serieuze haarscheurtjes.

Daar kan je natuurlijk van alles van vinden, maar als straks de helft van je apps niet meer werken en je qua supportbasis opnieuw moet beginnen kan je allicht beter energie steken in iets waar Google helemaal niks mee te maken heeft, dan android overeind proberen te houden.

[Reactie gewijzigd door Polderviking op 7 januari 2026 10:30]

Of je koopt gewoon een toestel van Jolla waar Sailfish al op staat.
Heb ik zelf inderdaad gedaan. Heb de C2 besteld (maar is op backorder dus moet er nog op wachten). Maar niet iedereen wil een nieuwe telefoon kopen. Het zou mooi zijn als je op telefoons makkelijker van OS kon wisselen, zoals op de desktop. Ik heb nog geen desktop gezien waar ik geen Linux op kon installeren. Misschien iets voor de overheid, om wat aan die geslotenheid te doen? Verplichte unlocken van de boot loader ofzo?
Een ARM desktop/laptop zal iets minder makkelijk overgezet kunnen worden op een ander OS.
Linux draait prima op ARM.
Ik bedoelde met name de driver ondersteuning. Die op ARM een stuk minder is.
Nagenoeg alle door Sailfish gesupporte telefoons gebruiken libhybris en zijn dus ook afhankelijk van AOSP/Google. Dit komt met name door de soc vendors en ODMs.

Als je echt van Google/AOSP af heb je iets nodig dat op mainline Linux draait zoals PostmarketOS of PureOS (purism's OS).
Interessant, dat wist niet.
Maar evengoed heeft Google met het OS verder natuurlijk niks van doen.

[Reactie gewijzigd door Polderviking op 7 januari 2026 10:27]

Natuurlijk heeft Google heel veel met het Sailfish OS te doen. Zonder Google AOSP zal de compatibiliteit met Android apps vrij spoedig breken.
Sailfish OS uses Alien Dalvik, a proprietary Android compatibility layer. It does not emulate Android, but instead implements its APIs by adapting the Android Open Source Project (AOSP) code to run as an application.
Elk alternatief mobiel OS heeft hetzelfde probleem, hoe haal je de app bouwers over om apps voor jouw mobiel OS te bouwen?

De enige oplossing tot op heden is zorgen voor compatibiliteit met Android AOSP.
Android app ondersteuning gaat wel een beetje voorbij aan de kern van mijn reactie.
Een alternatief mobiel OS is niet levensvatbaar zonder apps. Het heeft geen nut om Sailfish OS te ondersteunen als die volledig afhankelijk zijn van AOSP Android. Er veranderd dan dus niets.
Je moet ergens een keer beginnen anders veranderd er sowieso nooit wat.

En je kan dan android forken en technisch gezien compatibiliteit hebben, maar daarmee heb je nog niet het probleem opgelost dat Google arbitraire barrieres opwerpt door iedereen richting hun play store api te pushen en op die manier zaken af te dwingen buiten alleen "android hebben".

[Reactie gewijzigd door Polderviking op 7 januari 2026 11:11]

Dus in de kern is het allemaal hetzelfde probleem. App bouwers brengen hun apps alleen uit voor iOS en Google Android.

Daarmee heeft elk alternatief mobiel OS een heel groot probleem, de potentiële gebruikers kunnen hun favoriete apps niet gebruiken.

De enige oplossing is dan maar AOSP compatibiliteit inbouwen waarmee men afhankelijk wordt van Google. En ja, dan wordt je ook al snel afhankelijk van de Google Play api. Of je moet accepteren dat sommige apps niet zullen werken.
Graphene, /e/OS en Sailfish beogen juist nuttig te zijn zonder Android apps, maar ze snappen ook wel dat veel mensen makkelijker overstappen als er een Android compatibiliteit is.
Android ondersteuning is een tijdelijke oplossing. HarmonyOS van Huawei had tot aan versie 4 ook Android compatibiliteit, maar door de gestegen populariteit in China en het aantal apps wat er een native versie voor heeft uitgebracht, hebben ze dat in versie 5 laten vallen. En het platform is er niet minder populair om geworden. Een toekomstige versie van Sailfish heeft ook geen AlienDalvik meer nodig als het maar groot genoeg wordt. Sailfish zou onze HarmonyOS kunnen zijn, mits mensen eens verder gaan kijken dan hun Google ecosysteem.
Landen als China en Rusland schrijven hun bedrijven gewoon voor dat ze apps moeten maken voor het mobiele OS waar de overheid de voorkeur aan geeft. Sterker nog, Google mocht geeneens meer Android leveren aan Huawei van de Amerikaanse overheid,

Sailfish kan onze HarmonyOS zijn mits de app bouwers het gaan ondersteunen. Anders hou je de Google afhankelijkheid. En dat is echt het kip-ei probleem wat telkens terugkeert. Een mobiel OS is alleen levensvatbaar zijn als de apps ervoor beschikbaar zijn, maar app bouwers bouwen alleen apps voor grote platformen en niet voor een niche platform.
Ga jij voor die nieuwe Jolla phone?
Ik heb een C2 besteld. Die is de helft van de prijs van de Phone. Vind de Phone te duur voor wat ik met telefoons doe (voornamelijk berichten sturen en informatie op het web opzoeken). Nu nog wachten tot ie eindelijk geleverd wordt...
Oh dat is ook het overwegen misschien wel waard voor mij. Dank!
Volgens mij is er geen reden dat Sailfish niet op mainline zou kunnen draaien. Ze gebruien libhybris omdat er geen publieke drivers zijn voor die telefoons, iets wat je met een mainline kernel op andere OS'en/distro's ook niet op gaat lossen. Wat we nodig hebben is directe kernel ondersteuning vanuit de telefoon fabrikanten, in plaats van dat ze alleen met Google samen blijven werken en binaire blobs verschepen.
en dan mega bedrijven als ING paypall de overheid zo gek krijgen dat een native app bouwen voor jouw sailfish met 5 actieve gebruikers? ik als eerlijke belastingbetaler zou daar behoorlijk veel moeite mee hebben, dat betekent namelijk dat mijn zuurverdiende centjes niet gaan naar openbare veiligheid, onderwijs of zorg maar naar een app een stel doom-denkers (hoe goed bedoeld ook) is het absolute verspilling van geld.

wil je daarin echt iets doen dan zou je eigenlijk zelf moeten zorgen voor die basis functionaliteit denk aan bankieren, navigeren, contact overheid etc. voor iets als digiD zou je bijvoorbeeld kunnen proberen om via een WOO verzoek te kijken of je de ontwikkeldocumentatie in handen kunt krijgen om zelf een digiD app te kunnen bouwen. Pas zodra die apps er zijn kunnen jan en annemieke misschien naar je platform overstappen en kunnen we minder kritieke apps wél op kosten van de maatschappij laten porten (dan zijn er immers wél voldoende gebruikers om openbare middelen te rechtvaardigen).
Je hebt sowieso geen grip op waar je belastinggeld naartoe gaat dus dat zou ik als ik jou was naast me neer proberen te leggen, dat kost alleen maar energie.

Als het goed is gaat het overigens niet naar de ING om apps te maken, dus wat dat met elkaar van doen heeft is me niet helemaal helder.

[Reactie gewijzigd door Polderviking op 7 januari 2026 11:05]

Waarom moet alles via een app? Alle diensten die je noemt werken ook met een website. Je kunt dan allen je telefoon niet meer gebruiken om contactloos te betalen. Maar verder veranderd er weinig.
Werken met een website is wel variërend. Omdat ik soms echt geen zin heb om op mijn pc over te gaan probeer ik het op mijn telefoon, niet eens een kleine. Ik verbaas me gewoon van sommige echt grote platformen die gewoon niks geven om de mobiele site omdat ze al een app hebben of omdat ze gewoon verwachten dat je het op een groot scherm doet. In deze tijden is een site een beetje mobiel toegankelijk maken echt niet lastig, maar ja kost wel een klein beetje werk zeker als je desktop first designed.

Als ik alles via de sites zou moeten doen denk ik dat ik daar persoonlijk snel intens geïrriteerd van zou worden maargoed kan verschillen natuurlijk.

Verder ben ik opzich voor een fallback goede (mobiele) site. Sommige services die alleen via een app toegankelijk zijn probeer oke chr te boycotten. Maar zoals ik zeg de werkelijkheid is net anders

Verder hoe kan je überhaupt bijvoorbeeld whatsapp gebruiken zonder een apparaat met die app? Voor zover ik weet niet. Dat is voor 99% van de mensen al een dealbreaker.

En nog zoiets Spotify? Niet bruikbaar, de web (open) versie opent, je kant pauze play. Maar iets van Bibliotheek, Nee je moet de app downloaden hiervoor. Nou kun je daar bijvoorbeeld desktop mode forceren en dan heb je in theorie ongeveer alles functionaliteit, ware het niet dat alle touch inputs fout gaan omdat het er niet voor gemaakt is met die desktop geforceerd en touchinput.

Dit zijn zomaar 2 services die in mijn kringen eigenlijk iedereen gebruikt en niet mogelijk zijn als pure web variant.

[Reactie gewijzigd door PaulHelper op 8 januari 2026 14:43]

Helaas is SailfishOS meer proprietary dan AOSP, dus niet een geweldig alternatief. Eerder postmarketOS, Mobian, Ubuntu Touch, etc
Voor jezelf zou ik dat zeker doen als je daar bang voor bent. Maar het is niet alsof ze die (huidige) code ooit 100% van internet gaan krijgen :)

Er zijn genoeg mensen die het forken met of zonder de dreiging van het closed source worden, al is het maar om te archiveren of custom roms te maken.

[Reactie gewijzigd door watercoolertje op 7 januari 2026 09:37]

Niet echt, want zodra je een publieke fork maakt, zal je zelf de code moeten gaan onderhouden. Als de community dat niet oppakt, dan zal de code heel snel achter gaan lopen met alle beveiligingsrisico's van dien.
Prima toch, elk bedrijf zou dat (onderhoud) kunnen doen, zolang ze de code ook maar blijven delen met het internet zoals de licentie voorschrijft.
In theorie wel. Bij Linux is dat uitstekend gelukt. Daar zit een grote community inclusief commerciële bedrijven achter waardoor het een volwaardig OS alternatief is.

Bij AOSP Android zien we echter iets anders, het wordt niet opgepakt. Bedrijfjes met tien FTE ondersteunen hun Android versie die afgeleid is van AOSP Android. Dat kan niet, dus zijn ze volledig afhankelijk van wat Google bijdraagt aan AOSP.

Google trekt zich meer en meer terug van AOSP ondersteuning. Er was al gedoe over security patches en nu gaan ze over op zes maanden AOSP code releases. Ook is er gedoe met de play services en de verplichte ontwikkelaars registratie. Kortom, het wordt allemaal wat lastiger met AOSP Android.
Bij AOSP Android zien we echter iets anders, het wordt niet opgepakt.
Jawel door Google, andere bedrijven zijn pas 'nodig' als Google op dat vlak wegvalt...

De huidige situatie hoef je niet naar te kijken, we speculeren juist over een hele andere situatie...

[Reactie gewijzigd door watercoolertje op 7 januari 2026 11:52]

Dat ben ik niet met je eens. Er zijn meerdere bedrijven die al een eigen Android uitgeven op basis van AOSP Android. Die zelfs door telefoonmakers ondersteunt worden.

Die zouden dus helemaal zelf hun versie kunnen ondersteunen waarbij ze de afhankelijkheid van AOSP definitief doorbreken. Ze doen het alleen niet. Kennelijk is die stap veel te groot.

De kans dat wanneer Google zou stoppen met AOSP er ineens wel dik geïnvesteerd gaat worden in die alternatieven, die kans acht ik bijzonder klein.

Al was het maar omdat er dan helemaal geen tijd is om nog security fixes te gaan ontwikkelen. Voordat je dat allemaal op poten hebt gezet, ben je al een flinke tijd verder en zullen de meeste gebruikers allang gestopt zijn met het alternatieve OS wegens de onveiligheid.
Dat kan dat we het niet eens zijn, daarvoor speculeren we over iets :)

Ik zie niet in waarom iemand zelf het werk gaat doen als een ander het al voor ze doet. Lijkt me nogal zonde namelijk, zeker vanuit commercieel oogpunt.

Als dat wel logisch lijkt voor jou dan kan dat natuurlijk.

[Reactie gewijzigd door watercoolertje op 7 januari 2026 12:11]

Ik zie niet in waarom iemand zelf het werk gaat doen als een ander het al voor ze doet. Lijkt me nogal zonde namelijk, zeker vanuit commercieel oogpunt.
Om te voorkomen dat je zodanig van Google afhankelijk wordt dat je product ineens om kan vallen als Google met AOSP ondersteuning stopt.
Zitten de meeste devs juist niet op main omdat die releases zo ver achter lopen? Daar maak je het nu niet beter mee, toch?
Met de stappen die Google aan het zetten is, is er bijna geen voordeel meer aan Android tov IOS.

Same shit, different company binnenkort. Denk dat het tijd is om op zoek te gaan naar een moderne domme telefoon. Zonder AI en al die trackers en BS wat tegenwoordig in elke telefoon zit.
edit:
Hoofdletters en IOS ipv Apple

[Reactie gewijzigd door K.Y op 7 januari 2026 11:44]

Klopt als een bus. Android is bij lange na niet meer zo open en toegankelijk als 10-15 jaar geleden door alle toevoegingen en aanpassingen die Google eraan doet. Eigenlijk praktiseert Google gewoon een nieuwe variant van het goede oude Embrace, Extend & Extinguish.
Niet helemaal mee eens. Ja Google lijkt inderdaad minder open te worden maar je kunt eigenlijk nog steeds ongeveer alle dingen die je 10 jaar terug ook kon. Side loaden, met adb (wireless zonder pc/shizuku etc) ongeveer alles wat je kan bedenken. Ja voor dat soort dingen moet je door iets meer 'hoops' springen maar je krijgt het wel mogelijk. Waar iOS nu wel een alternatieve app Store heeft en side loading voor zover ik weet nog steeds wekelijkse 'refresh' nodig heeft met bijv altstore en ipa files.

Verder blijft android met accessoires en integraties echt wel opener, waar iOS met bijvoorbeeld externe servers als ftp, WebDAV etc syncs enorm lastig doet, kun je bij android met meerdere apps dit gewoon precies zo instellen als je wil. En de appstore van iOS is nog steeds zo ondoorzichtig als wat, je moet geluk hebben met je app en concurrenten maar ook met wie je app goedkeurt of updates doorlaat. Bij android hebben ze nu volgens mij wel een tester plicht toegevoegd waar mogelijk terecht wat gaat op is maar verder heb je veel meer vrijheid
Allemaal negatieve reacties op dit artikel uiteraard, maar hoeveel keer per jaar zet Apple de broncode voor iOS online?
Het verschil is dat iOS nooit open is geweest en dat Apple nooit beweert heeft dat het open source is. Je hoeft dat niet leuk te vinden, maar je krijgt bij Apple wel precies wat je kon verwachten toen je voor het eco-systeem getekend hebt.

Google daarentegen heeft mooie verhalen over openheid verteld, maar is in de praktijk bezig het hele eco-systeem dicht te timmeren, niet alleen door de source-code minder vaak te releasen, maar ook op vele andere manieren. Dat is ons nooit verteld toen we ons op het eco-systeem vastlegden. Dat is bait-and-switch. Achterbaks gedrag. Helaas niet illegaal vermoed ik.

Er zijn genoeg redenen om Apple te bekritiseren. Dit is er niet een van.
Ik denk dat misschien deels meeweegt dat android het openste grote platofrm is mobiel gezien. Als android en AOSP verslechteren betekend dat dat de alternatieven minder levensvatbaar worden. Aangezien je dan een totaal ander ecosysteem moet maken wat compleet losstaan van android/AOSP en iOS. Dan is er al helemaal niks meer tussen te krijgen behalve in landen waar ze het OS zowat kunnen afdwingen.

Als android vroeger zo was als iOS dan zou de verandering naar de nu situatie positiever worden ontvangen want 0 naar meerdere open source releases is natuurlijk beter dan van altijd naar paar keer per jaar als je geluk hebt .

Om te kunnen reageren moet je ingelogd zijn