Google wil dat Android-fabrikanten patches sneller doorvoeren naar eindgebruiker

Google meent dat er een hiaat bestaat tussen verschillende bedrijven die samen een Android-toestel bouwen. Hierdoor zouden patches niet snel genoeg geïmplementeerd worden. Het Amerikaanse bedrijf roept op om patches sneller tot bij de eindgebruikers te krijgen.

Volgens Google waren er vorig jaar een aantal gevallen waarbij een leverancier (van bijvoorbeeld een chip) een patch voor een kwetsbaarheid had uitgebracht en Android-fabrikanten vervolgens verzaakten om deze patch snel te verspreiden naar de eindgebruikers van hun toestellen. Hierdoor kunnen n-days, kwetsbaarheden waarvoor al een patch bestaat, fungeren als een zeroday, een kwetsbaarheid waar nog geen patch voor bestaat.

Het bedrijf haalt een kwetsbaarheid in Arms Mali-gpu, die vorig jaar is ontdekt, als voorbeeld aan. Deze kwetsbaarheid werd in juli 2022 gemeld en in oktober kwam Arm met een patch naar buiten. Het duurde echter nog tot april 2023 voordat de patch daadwerkelijk was verspreid naar de eindgebruikers. Volgens Google zijn hiaten zoals deze niet uitzonderlijk, maar ze zouden meer voorkomen en langer duren bij leveranciers en fabrikanten van Android-toestellen. Het bedrijf roept leveranciers en fabrikanten daarom op om patches en bugfixes sneller door te voeren naar de toestellen van de eindgebruikers.

Google schrijft in het rapport ook dat er vorig jaar 41 zerodays zijn ontdekt. Dat zijn 28 minder dan in 2021. Het Amerikaanse bedrijf meldt ook dat zeventien van de 41 ontdekte zerodays als varianten van al ontdekte kwetsbaarheden bestempeld kunnen worden. Volgens Google was er ook een toename van het aantal bug collisions. Die term wordt gebruikt wanneer meerdere personen melding doen van eenzelfde kwetsbaarheid of bug. Volgens Google is dit goed nieuws. Dit zou volgens het bedrijf immers betekenen dat het aantal zerodays die actief gebruikt worden, afneemt.

Reacties (75)

[MastaG]

Google moet gewoon naar een punt gaan, dat ze eisen dat alle drivers in de upstream linux kernel zitten.
Zo niet, dan geen certificering meer.
Voor de populaire GPU's hebben we opensource drivers in het mesa project zitten: freedreno (OpenGL Adreno), panfrost (OpenGL Mali), turnip (Vulkan Adreno) en panvk (Vulkan Mali).
En deze drivers zijn behoorlijk gevorderd, aangezien de Yuzu Nintendo Switch emulator voor Android deze drivers al meelevert.
Je hoeft op deze manier geen externe patchsets en binary blobs te onderhouden, wat regressie testen en future updates een stuk makkelijker maakt.

[Reactie gewijzigd door MastaG op 23 juli 2024 17:52]

[ari3]

Google moet gewoon naar een punt gaan, dat ze eisen dat alle drivers in de upstream linux kernel zitten.
Zo niet, dan geen certificering meer.
Voor de populaire GPU's hebben we opensource drivers in het mesa project zitten: freedreno (OpenGL Adreno), panfrost (OpenGL Mali), turnip (Vulkan Adreno) en panvk (Vulkan Mali).

Ik zou zelfs nog een stap verder gaan: de industrie moet een generieke (hardware-register) interface maken voor componenten als een modem of GPU. Het is gewoon achterlijk dat we in 2023 nog steeds specifieke drivers hebben voor specifieke GPUs en modems. Voor USB, Firewire en SATA is meer dan 10 jaar geleden al een generieke hardware interface opgesteld zodat er maar één driver nodig is om USB (xhci), Firewire (ohci) en SATA (ahci) controllers te ondersteunen. Dat kun je ook voor een GPU of modem doen zodat er maar één kernel module nodig is voor GPUs en modems.

[ronaldmathies]

Werkt dat niet alleen wanneer de hardware an-sich ook gestandadiseerd is? En is dat dan niet de reden dat het niet haalbaar is, want hou zou nvidia zich van amd kunnen onderscheiden op hardware niveau? Vertraagt dit ook niet enorm de door ontwikkeling, een comminicatie standaard is iets totaal anders dan een GPU.

[ari3]

Werkt dat niet alleen wanneer de hardware an-sich ook gestandaardiseerd is?

Het idee is dat de register interface tussen GPU en CPU gestandaardiseerd wordt. Dat betekent niet dat iedere GPU dezelfde functionaliteit moet bieden. Met OpenGL heb je een API waarbij je het host systeem (kernel) vraagt welke functionaliteit een GPU ondersteunt. Je kunt prima een hardware interface maken die de eigenschappen van een GPU beschrijft.

Voor printers is de hardware ook nog steeds niet gestandaardiseerd en zijn er uiteenlopende feature-sets, maar ook daar zien we dat (netwerk) printers zelf hun hardware kunnen beschrijven (DPI, duplex, papierformaat, kleurprofielen, scaling, enz.) zodat er maar één driver nodig is.

[CAPSLOCK2000]

Werkt dat niet alleen wanneer de hardware an-sich ook gestandadiseerd is?

Op zich wel, maar de meeste hardware is al min of meer standaard. Vaak zijn er maar een paar basischips die bepaalde functionaliteit leveren en die worden door alle fabrikanten gebruikt om hun eigen hardware om heen te bouwen. Zo'n beetje alle grafische kaarten zijn gebaseerd op precies dezelfde chips van nvidia en amd. De fabrikant van de kaart hoeft zelf alleen maar voor de ventilator en de RGB-ledjes te zorgen en gebruikt daarvoor waarschijnlijk ook kant-en-klare chips.

En is dat dan niet de reden dat het niet haalbaar is, want hou zou nvidia zich van amd kunnen onderscheiden op hardware niveau?

Deze bedrijven zijn gespecialiseerd in hardware bouwen. Software doen ze er uiteindelijk bij omdat het moet. Ik denk dat ze liever alleen op hun specialisme willen richten. Ik moet er wel bij zeggen dat grafische kaarten een beetje speciaal zijn, dat de software enorme invloed heeft op de performance en dat de competitie moordend is. Wat dat betreft is het misschien niet het beste voorbeeld. De meeste hardware is een stuk minder spannend.

Vertraagt dit ook niet enorm de door ontwikkeling, een comminicatie standaard is iets totaal anders dan een GPU.

Zowel nvidia als amd hebben zelf al gekozen om één driver te ontwikkelen voor al hun hardware. De voordelen wegen blijkbaar op tegen de nadelen.

[sympa]

Bij wifi-chips zitten veel functies in de driver. Van algoritmes om het te gebruiken signaal te kiezen tot het al dan niet activeren van functies op de chips.

[CAPSLOCK2000]

Ik zou zelfs nog een stap verder gaan: de industrie moet een generieke (hardware-register) interface maken voor componenten als een modem of GPU. Het is gewoon achterlijk dat we in 2023 nog steeds specifieke drivers hebben voor specifieke GPUs en modems.

We hebben een standaard maar die staat stil in 1987: VGA.
https://en.wikipedia.org/wiki/Video_Graphics_Array

[HollowGamer]

Ik weet niet of fabrikanten hierom staan te springen. Het probleem is namelijk dat elk toestel dan nog updates/upgrades zou krijgen, en ze ook hun drivers open-source moeten maken. Dat zou hun verdienmodel onderuit halen.

Ben het helemaal met je eens hoor, alleen heb je nu eenmaal merken die hun eigen implementatie belangrijker vinden dan een globale. Ik noem bijvoorbeeld iets als Samsung's Knox, en dan heb je nog custom modules/settings voor de camera, sensoren, etc. - die fabrikanten echt niet willen prijsgeven. Ik geloof dat Google elk jaar (terecht) zeurt over updates van vendors, maar dit krijg je dus.

Het zou veel beter zijn als er een Android alternatief zou komen, zoiets dat werkt op basis van Gnome/KDE, en met PWA's zou dat moeten lukken. Helaas zijn die nog veel te klein, en ook hier worden ze weer tegengehouden door telefoonmakers. Tevens heb je nog een hele grote groep, die echt niet willen afstappen van Android, want iets anders kennen ze niet of ze willen iets 'premium' als Apple.

[kodak]

Het verdienmodel van die fabrikanten is gebaseerd op het verdienmodel van Google. Dus het komt er eerder op neer dat als Google geen strengere eisen stelt ze er vooral zelf niet om staan te springen andere risico's te lopen die ze financieel kan raken. En dat maakt dit klagen over de fabrikanten door Google te makkelijk.

[willieverhoef]

Als google dan google play ook opensource maakt. Google eisen laten stellen terwijl ze zelf hetzelfde spelletje spelen, zelfs naar mijn mening nog een beetje erger.
In dit geval brengen chip leveranciers het netjes uit, maar wordt het niet door telefoon leveranciers opgepakt. In het gedeelte van google play api is het bewust software afhankelijk maken om zelf controle te houden.

[kodak]

Als google eisen gaat stellen die in belang van gebruikers is dan zijn die eisen absoluut niet onredelijk of erger te noemen dan de huidige situatie. Verplichten om updates beschikbaar te stellen en binnen bepaalde tijd te leveren is juist een voorbeeld hoe google dan juist zelf iets doet om het ecosysteem beter te maken.

[GertMenkel]

Telefoonfabrikanten komen er wellicht beter van af, maar fabrikanten als Qualcom en Mediatek verkopen langdurige updates voor veel geld. Zo was er bij de Oneplus One bijvoorbeeld controverse dat er een bepaalde Androidversie niet vrij kon komen omdat, aldus Oneplus, de driver niet kon worden geüpdatet om de nieuwe versie van de graphics-API te ondersteunen. Later bleek men van een ander toestel met een identieke SoC gewoon wel een nieuwere driver te kunnen vinden en konden custom ROMs gewoon door met updaten, maar dat bewijst wel weer hoe de onderhoudsprijs die Qualcom rekent de consument soms zwaar in de weg kan zitten.

Ik snap het model wel, updates krijg je voor een tijdje een na een dag moet je betalen, dat maakt capaciteit vrij zodra iedere klant updates laat vallen. Met de aankomende EU-wet zal dit model onder druk komen te staan.

[sympa]

Dus Qualcomm blokkeert wigenlijk updates van toestellen zodat wij nieuwe moeten kopen?
Helaas zijn andere fabrikanten niet beter.

[R4gnax]

Ik weet niet of fabrikanten hierom staan te springen. Het probleem is namelijk dat elk toestel dan nog updates/upgrades zou krijgen, en ze ook hun drivers open-source moeten maken. Dat zou hun verdienmodel onderuit halen.

Ik denk dat fabrikanten er eerder niet om zullen staan de springen wanneer de EU hier wind van krijgt en dadelijk lastige vragen inzake productduurzaamheid gaat stellen, wanneer blijkt dat apparatuur die door de fabrikanten als afgeschreven beschouwd wordt, feitelijk nog tot in lengte van jaren breedgedragen ondersteuning kan genieten...

[CAPSLOCK2000]

Ik weet niet of fabrikanten hierom staan te springen. Het probleem is namelijk dat elk toestel dan nog updates/upgrades zou krijgen, en ze ook hun drivers open-source moeten maken. Dat zou hun verdienmodel onderuit halen.

Daar staat tegenover dat drivers schrijven en onderhouden erg duur is. Zo duur dat de meeste fabrikanten van telefoons dat meestal niet zelf doen maar het overlaten aan de fabrikant van de chips. Waarschijnlijk wordt dezelfde basisdriver aan iedere telefoonbouwer verkocht. Dat is vast niet goedkoop en daarna moet die driver ook nog onderhouden worden. Het zou voor de telefoonbouwers goedkoper zijn om samen te werken aan één goede driver.

De toenemende eisen aan garantie, veiligheid en duurbaarheid vereisen dat hard- en software steeds langer mee gaat. Goed onderhoudbare software wordt dus steeds belangrijker want je moet er steeds langer voor zorgen. Het huidige model waarin iedere telefoonbouwer voor updates moet zorgen voor alle chips die ze gebruiken is veel te duur om in stand te houden.

Ben het helemaal met je eens hoor, alleen heb je nu eenmaal merken die hun eigen implementatie belangrijker vinden dan een globale. Ik noem bijvoorbeeld iets als Samsung's Knox, en dan heb je nog custom modules/settings voor de camera, sensoren, etc. - die fabrikanten echt niet willen prijsgeven. Ik geloof dat Google elk jaar (terecht) zeurt over updates van vendors, maar dit krijg je dus.

Voor iedere Samsung zijn er tien andere fabrikanten die "normale" telefoons maken waar geen bijzondere drivers voor nodig zijn. Het probleem zou al een stuk kleiner zijn als Google zorgt dat er meer goede drivers komen in de Linux-kernel komen voor basishardware

Het zou veel beter zijn als er een Android alternatief zou komen, zoiets dat werkt op basis van Gnome/KDE, en met PWA's zou dat moeten lukken.

Eerlijk gezegd denk ik dat we meer hebben aan Debian-achtig alternatief. Een groot deel van het probleem zit in de veel te ingewikkelde relaties tussen Google, Android, Linux, chipfabrikanten, telefoonbouwers en telefonieproviders. Bij iedere driverupdate moeten verschillende partijen in actie komen. Het is heel anders dan de Linux of Windows wereld. Veel Linux-gebruikers installeren nooit een extra driver maar gebruiken alleen wat het OS levert (al is er soms wat firmware nodig en dat is eigenlijk precies hetzelfde als een driver).
Deel van het probleem zit overigens ook in de hardware-architectuur. PC's zijn heel flexibel en je kan on-the-fly zo'n beetje al je hardware autodetecten en configureren maar een typische ARM-gebaseerde Android telefoon kan dat niet. Ik durf nie te zeggen hoe (on)oplosbaar dat probleem is maar aangezien het als sinds de begindagen van Android zo werkt ben ik bang dat het eigenlijk niet aanpasbaar is.

[MrMonkE]

OT: Wordt wel een beetje moe van Yuzu updates. Lijkt wel om de dag ofzo.

[Aaargh!]

Ik snap nog steeds niet waarom Google Android zo heeft opgezet dat patches via de fabrikant van de hardware moeten verlopen.

Stel je voor dat elke Windows update via de fabrikant van je moederbord zou moeten gaan.

[Z80]

Andersom. Dat elke firmware en driver update via "Windows update " moet gaan.
En dus eerst door de Microsoft molen moet voordat deze een keer online verschijnt.

Grootste probleem binnen de android wereld is dat de drivers niet openbaar verkrijgbaar zijn.
Alleen de fabrikanten die de hardware afnemen kunnen ook de drivers en firmware kopen.
Zodra de eindgebruiker zelf de driver kan upgraden zal het een stuk sneller gaan.

[Osiummaster]

Het hoeft niet open-source te zijn oid. Als ik bv een intel wifi chip driver nodig heb op windows kan ik gewoon naar de Intel website gaan en die downloaden. Tegenwoordig heeft Windows ook bij Optional Updates veel propriatary drivers die hij automatisch detecteert

Als android de device drivers en het OS eens goed weet los te koppelen dan zou het updaten naar mijn gelimiteerde kennis een stuk makkelijker lijken.

[TrekVogel]

Dat is natuurlijk niet hoe het werkt met Linux/Android. Dat werkt gewoon niet zo. Drivers zitten in principe nou eenmaal in de kernel.

[sfc1971]

Niet in de kernel, modules bestaan, maar strak gekoppeld aan de kernel. Aangezien iedere telefoon maker een net iets andere versie kan leveren zou het veel eisen van een onderdeel maker om iedere gebruikte kernel te ondersteunen.

[GertMenkel]

Dit is waarom elke laptop met een firmware/driverupdater wordt geleverd. Veel tweakers (en ikzelf, voor een tijdje) hebben de neiging die te verwijderen, maar voor bijvoorbeeld graphicsdrivers heb je die tool nodig of zul je zelf periodiek de site af moeten lopen.

Ik denk dat een veel groter probleem niet per se de manier is waarop de drivers beschikbaar komen, maar de manier waarop de ontwikkelketen werkt.

Je krijgt als fabrikant je kernel van de SoC-ontwikkelaar met veranderingen in plaats die niet per se kwalitatief of stijlcorrect zijn om in de upstreamkernel mee te nemen. Daarop bouw je vervolgens je eigen aanpassingen, voor je eigen drivers en andere modificaties die alleen voor jouw toestel gelden. Daarop bouw je dan je eigen Android-fork. Ergens komt ook nog een tweede Linuxkernel voor het modem binnen die bijna niemand ooit updatet.

Er zijn flink wat stappen genomen om drivers en Android zelf los te koppelen zodat upgraden en updaten makkelijker gaat, en je ziet ook steeds meer bedrijven jaren aan support toevoegen. Echter heb je daar niks aan zolang een significant deel van de consumenten nog iedere twee of drie jaar een nieuw toestel neemt en niet bereid is meer te betalen voor langere ondersteuning.

Als Qualcom en vrienden niet met een eigen kernel kwamen maar gewoon modulus leverde met een tussenlaag zoals Nvidia met DKMS doet, zou de compatibiliteit nog steeds op niveau Nvidia liggen maar zouden updates een stuk makkelijker gaan.

Gelukkig zijn er projecten als PostmarketOS die drivers de upstream tree in helpen, en zelfs open source GPU drivers die het aardig goed doen. Zelfs als de leverancier er met de pet naar gooit, zouden sommige fabrikanten daarmee samen kunnen werken om langer kernelupdates te leveren. Dan moet de consument er alleen wel om geven.

Nu is het wel zo dat de EU een nieuwe wet heeft aangenomen die onder andere verbiedt om producten met bepaalde kwetsbaarheden te verkopen. Bedrijven worden ook verplicht om patches te verhelpen in veel gevallen. Als instanties hier ook daadwerkelijk wat mee doen, denk ik dat winkels wel twee keer nadenken voor ze Oneplus of Xiaomi met hun onbetrouwbare patchschema in de schappen leggen; je kunt zomaar te maken krijgen met maanden aan verkoopstops als ze hun updates niet op orde hebben. Ik denk dat dit de goede kant op gaat.

[FONfanatic]

Het valt de consumenten niet kwalijk te nemen dat zij om de paar jaar hun Androidtoestellen vervangen, aangezien fabrikanten om diezelfde paar jaar de ondersteuning stil zetten. Keer die redenatie dus niet om.

[GertMenkel]

Ik ken eigenlijk helemaal niemand die vanwege een gebrek aan updates hun Androidtoestel wegdoet. Op Android is de norm dat apps het nog jaren (als in, vijf jaar of meer) na het stoppen van OS support het allemaal nog doen met bijna altijd de nieuwste features. De traagheid van de hardware heeft veel meer impact voor zover ik bij anderen zien.

Als ik kijk naar de features van Android 14 dan zie ik weinig dat ik erg zal missen. Bij Android 12 idem. De belangrijkste upgrades zitten in apps als de dialer enzo, maar daar heb je geen OS-updates voor nodig.

[FONfanatic]

Het is met Android versies net als met andere OS: des te ouder de versie des te meer kwetsbaarheden hackers erin ontdekken. Ook zijn er steeds meer apps die de ondersteuning stopzetten.

[Sinester]

Het valt de consumenten niet kwalijk te nemen dat zij om de paar jaar hun Androidtoestellen vervangen, aangezien fabrikanten om diezelfde paar jaar de ondersteuning stil zetten. Keer die redenatie dus niet om.

Die redenatie geld alleen voor (een klein) gedeelte van Tweakers.. wat misschien iets van 0,1% van alle Android gebruikers zijn

Mensen roepen dit hier (wellicht terecht) erg graag, maar buiten een handje vol gebruikers van technische websites geeft letterlijk niemand hier wat om, en is al helemaal geen reden om de telefoon te vervangen als die nog prima werkt

[Reactie gewijzigd door Sinester op 23 juli 2024 17:52]

[FONfanatic]

QED. Ooit komt er een moment dat een zeroday in een verouderde Android versie niet tijdig gepatcht raakt ...

[Sinester]

Dat geloof ik best, en ik ben ook voorstander van updates en dergelijke, echter in al die tijd dat Android bestaat heb ik nog nooit gehoord dat dit een probleem heeft opgeleverd

Wat ik dus probeer te zeggen is dat het 9 van de 10 mensen niet interesseert en volgens mij amper invloed heeft op jouw punt dat mensen steeds hun telefoon vervangen

[familyman]

Zou het echt niet heel gek vinden als dit verplicht ging worden. Zelfs als blobs zou het de wereld een stuk veiliger maken.

[watercoolertje]

Stel je voor dat elke Windows update via de fabrikant van je moederbord zou moeten gaan.

Ah jah dat kennen we zeker van die aantal keren dat het driver-systeem in windows op de schop ging en er voor je nieuwe windows dan heel veel drivers misten, echt top was dat (not).

Dat is dus net zo goed niet zaligmakend, andere voordelen maar net zo goed andere nadelen. Maar dus nog steeds ook nadelen.

[GertMenkel]

DOS-98, XP, Vista, dat waren de grote drivermodelrevisies. Eventueel met 32/64 bit als extra verschil. Je hebt nog andere releases van NT natuurlijk maar voor consumenten waren de NT-releases niet zo relevant tot XP uit kwam. Sinds Vista zijn er steeds meer driver-API's naar user mode getrokken, maar in kernelland blijven ze werken.

Maar goed, het algemene model is natuurlijk ook anders. Bij Linux en Android zitten de meeste drivers in de kernel zelf, dus als je de kernel updatet neem je mooi alle drivers mee waarvan je de code kunt vinden. Heel erg veel Windowscomputers hebben kwetsbare drivers waar ze niet vanaf weten omdat de fabrikant de moeite niet neemt om patches uit te brengen.

Verder is er een lijstje van zo'n 200 drivers beschikbaar op internet met bekende, gedocumenteerde, ondertekende drivers die ieder programma met een adminprompt in de kernel kan laden waar dit op Android alleen met exploits mogelijk is. Microsoft trekt de certificatie van die drivers niet in, want dan stopt echte hardware met werken, maar kan ook helemaal niets om die kwetsbaarheden te verhelpen omdat het amper een relatie heeft met de driverontwikkelaars. Google kan dit soort parches dan wel weer zelf schrijven en upstreamen.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 17:52]

[Verwijderd]

Aaargh schreef:

Ik snap nog steeds niet waarom Google Android zo heeft opgezet dat patches via de fabrikant van de hardware moeten verlopen.

Dat is omdat andere hardwareleveranciers heel andere hardware kunnen gebruiken.

Aaargh schreef:

Stel je voor dat elke Windows update via de fabrikant van je moederbord zou moeten gaan.

Geenszins bedoeld om Google te verdedigen:
simpele vergelijkingen met andere platformen gaan zeer snel mank. Er zijn te veel factoren die een rol spelen.

Bijv. in de Windows instellingen staat standaard uit dat updates voor andere Microsoft producten dan Windows ook gedownload moeten worden, laat staan dat er een volwassen systeem is dat third party applicaties van updates voorziet.

Voor Apple producten geldt keiharde vendor-lock-in, en hoewel Apple heel lang updates biedt, moet je bij oudere apparaten een maand extra (of langer) wachten op kritische security-updates.

Ik heb (naast een iPhone) nu een Pixel 6 Pro, die snel updates krijgt, maar de "feel" vind ik minder dan mijn oude OnePlus 6.

Edit 11:08: bij Apple "hardware" weggehaald (stond direct vóór "vendor-lock-in")

[Reactie gewijzigd door Verwijderd op 23 juli 2024 17:52]

[kodak]

Er zijn voor alle mogelijkheden om updates uit te rollen factoren te noemen. Maar in plaats van daarover te speculeren hoe belangrijk die zijn lijkt het me redelijker dat de factoren dan ook door google (of fabrikanten) genoemd worden als ze met 'oplossingen' komen. Dus ook voor de huidige oplossing, waar google nu over klaagt dat fabrikanten maar meer moeten doen. De keuzes voor 'oplossingen' zijn anders meer het opkomen voor onduidelijke belangen en factoren die niet perse vooral te maken hebben met wat ze selectief kiezen als argumenten.

[HollowGamer]

Het probleem is dat die patches vaak in de kernel moeten. Ze hebben het al deels losgetrokken, zoals het kunnen patchen via de Play Service, maar ze kunnen niet zomaar alles patchen, aangezien het ook moeilijk is om te testen en dus breaking kan zijn.

Bij Windows is de opzet anders, de drivers zitten niet in de kernel, die worden er bovenop geladen. Beide hebben hun voor en nadelen, maar het voordeel is dat MS dus wel aan kernel bumps kan doen, en bij Linux je deze als vendor opnieuw dient te compilen en onderhouden.

[SA65]

Laat Google dan ook eens zorgen dat telefoons een fatsoenlijke tijd updates krijgt, windows wordt minstens 7 jaar onderhouden, een telefoon is onderhand net zo duur als een goedkope pc, schande dat je daar maar zo kort updates voor krijg.

En ja het begint nu eindelijk naar 5 jaar te verschuiven, maar dat is nog steeds geen standaard bij alle leveranciers.

[pjdijkema]

Daar heb je zelf ook invloed op door te kiezen voor een merk die lang ondersteunt. Als ik een Android zou kopen zou dat altijd een Samsung zijn ivm de lange ondersteuning.

[Ortep]

Je kan natuurlijk ook een Pixel kopen.

[NLxDoDge]

Snap de min wel, ik heb bijvoorbeeld om deze rede een Pixel 6a aangeschaft.

Via mijn werk kreeg ik een e-mail dat mijn telefoon geen ondersteuning meer heeft en niet gebruikt kon worden om in te loggen op het bedrijfsnetwerk e.a. koop even een nieuwe telefoon. (PocoPhone F1, die had al geen updates meer rond 2021 als ik me niet vergis). Ik had hem niet direct gekocht. Dus ik heb hem maar twee jaar kunnen gebruiken voordat er al geen security updates meer kwamen.

De 6a heb ik sinds oktober 2022, heeft nog tot oktober 2024 normale support (2 jaar dus ongeveer) en tot oktober 2026 security updates (4 jaar dus ongeveer).

Dus voor mij valt dit een beetje in dezelfde boot. Het hangt er puur vanaf of je de telefoon meteen koopt, omdat vanaf dag één de support tijd al gaat tikken.

[Soldaatje]

Dat kan, maar je kan ook een budget smartphone kopen en kijken of deze een beetje ondersteuning heeft voor custom rom's (geen Mediatek, wel Qualcomm) op XDA of LineageOS, dan kan je er ook langer mee doen.

[SA65]

Klopt, maar daar zit een maar aan, je krijgt 5 jaar ondersteuning, vanaf het punt dat de telefoon op de markt komt. Als je dus die zelfde telefoon koopt na 2 jaar, krijg je dus nog maar 3 jaar updates, waarvan 1 jaar alleen maar veiligheids updates. En dat geld dus ook voor de mobieltjes die 1000+ euro kosten.

[pjdijkema]

Toestellen die al 2 jaar op de markt zijn kosten nooit meer 1000 euro, hooguit 500 of 600. En ook dat is een keuze.

[SA65]

Klopt, dat is een keuze, maar veel mensen kopen zo'n ding bij een winkel, die die "oudere" telefoons nog kwijt willen, en veel mensen zijn niet echt op de hoogte van al het telefoon nieuws. En ik vind dat ook een mobiel van 500 a 600 euro meer dan 2 OS update's verdient, want 600 euro is geen klein geld, dat is voor veel mensen nog serieus veel geld.

Vind zo wie zo, dat vanaf dit soort bedragen, de fabrikanten zo wie zo meer garanties moeten bieden. Als ze dat niet durven, maken ze pruts spul.

[FONfanatic]

Dankzij politieke druk is het over een paar jaar 5 jaar ondersteunen geblazen.

[mschol]

imho: google heeft alle tools om sneller patches bij de eindgebruiker te krijgen, maar wil kennelijk de drivers, het OS en het stukje aanpasbaarheid niet van elkaar loskoppelen
Dus google kan nu wel wijzen naar fabrikanten, maar moet eigenlijk naar zichzelf wijzen omdat zij geen flexibele manier hebben om snel updates aan drivers en het OS toe te voegen zonder dat het andere dingen kan breken

[Chris.nl]

Ik weet er het fijne niet van, maar volgens mij is het Google er al aan gelegen Android zo makkelijk/practisch mogelijk in te richten voor fabrikanten om updates te kunnen pushen. (Project treble?) Dit naast de playstore patches die Google zelf levert.

An sich leg je imo de vinger op een juiste plek. Zelf ben ik in m'n nopjes met een Pixel 7a (EOL mei 2028) en Chromebook (EOL 2030), juist omdat Google daarvoor zelf alle updates verzorgd.

[Tyrian]

Deze eindgebruiker roept Google op om Android patches direct en zonder tussenkomst van de telefoonfabrikant te gaan distribueren naar de eindgebruiker. Net als Microsoft dit doet met Windows Update.

[sfc1971]

HP, Dell en dergelijke kunnen en mogen Windows niet aanpassen. Maakt het een stuk gemakkelijker.

[Roel1966]

Net als Microsoft dit doet met Windows Update.

Ik dacht eerst van ja inderdaad maar dit klopt niet helemaal dat Microsoft via Windows Update alle patches uitbrengt. Kijk ik naar b.v. bios updates dan is dit vaak beperkt tot laptops maar weer niet voor desktop pc's. Evenzozeer zie je vaak wel voor Intel dan patches via Windows update maar niet voor AMD. Dus het is deels merk en deels afhankelijk van het soort apparaat zoals desktop pc of laptop/tablet.

[kodak]

Het Amerikaanse bedrijf roept op om patches sneller tot bij de eindgebruikers te krijgen.

De meeste en grote merken leveren de officiële Android software die ze bij Google onder Googles voorwaarden kopen. Als google van mening is te kunnen aantonen dat dit traag en niet doorvoeren van patches naar eindgebruikers onaanvaardbare risico's voor Google en de eindgebruikers heeft, dan kunnen ze hun voorwaarden naar de merken strenger maken. En als ze het echt serieus hadden genomen dan hadden ze dat afgelopen 14 jaar al gedaan. Dit verkondigen dat de merken fout zitten is anders vooral marketing om de merken fout te laten lijken. Google heeft dit Android eecosysteem met slappe regels over updaten, waaraan ze in totaal miljarden verdienen, zelf gemaakt.

[CivLord]

Laat Google nu net nieuwe Pixel telefoons en een tablet te hebben aangekondigd, waardoor het net op dit moment even goed uitkomt om andere fabrikanten slecht te doen lijken.

[lilmonkey]

Daar heeft Google helemaal geen belang bij. Google brengt zelf Android-hardware uit juist om andere fabrikanten te stimuleren — exact hetzelfde principe als Microsoft met de Surface-lijn.

[CivLord]

Google wil de anderen niet uit de markt duwen met de eigen hardware. Maar het kan nooit kwaad om tijdens het uitbrengen van nieuwe modellen even te laten zien waarom ze beter zijn dan de rest. Dat kan ook de rest weer stimuleren

[quazar]

Het is jammer dat er niet een aparte driver-laag is met daarnaast een OS-laag. Zodat je een OS ook kunt updaten zonder afhankelijk te zijn van device-specifieke drivers, of dat generieke updates mogelijk worden onafhankelijk van de drivers. Regel dat eens Google.

[PCG2020]

In Linux (waar Android op gebaseerd is) kunnen nieuwe drivers heel lastig "apart" van de kernel geleverd worden. Ze zitten er meer in verweven dan in bijvoorbeeld Windows. Je moet dus al gauw een nieuwe variant van de kernel leveren wanneer er grote updates plaats moeten vinden. Daarnaast maken vrijwel alle fabrikanten een "eigen" versie van de Android-kernel. Dat is nog een extra hobbel.

Maar je hebt gelijk, het zou een stuk makkelijker zijn wanneer drivers en OS apart(er) van elkaar bijgewerkt kunnen worden.

[Roel1966]

Op zich wel goed dat Google er vaart achter wil gaan zetten en eigenlijk daar gewoon één lijn in getrokken moet worden. Als dus een bepaalde chipfabrikant met een patch komt dat deze dan door de andere fabrikanten dan ook direct door gaat naar de consument. Zeker bij smartphones is het vaak pure willekeur van de fabrikant of je wel of niet dan patches en updates ontvangt.

Zeker zou het helpen wanneer patches dan via Google zelf zou gaan net zoals dat deels ook bij Windows gebeurd en al zeker bij Apple. In die zin heeft Apple het beter voor mekaar doordat zij alles in eigen handen genomen hebben. Echter ja voor de consument heeft dat ook weer nadelen als je dan kijkt naar dingen als right to repair en je niet vrij bent in de keuze van hardware.

[Marc-Jan]

Oh wat fijn, ben net in onderhandeling met Asus over het feit dat mijn telefoon net buiten garantie vernacheld is door een update van Asus, maar zij claimen dat t 'hardwareschade' is. Nog sneller pushen, nog vaker functies verliezen/schade...

[Bart_Smith]

Ehh sorry hoor, maar in Juli weten dat er een veiligheids issue is en pas in Oktober met een patch komen ?
En dan klagen dat de fabriekanten traag zijn met updaten ?