Google samarbeider med Qualcomm for å gjøre det enklere å levere programvareoppdateringer, og muliggjør 4 Android OS-versjoner og 4 år med sikkerhetsoppdateringer.
For over 3 år siden, Google annonserte Project Treble, en stor ombygging av Android designet for å øke hastigheten på programvareoppdateringer. Mens arkitekturen introdusert av Project Treble har hjulpet OEM-er til å fremskynde leveringen av store Android OS-oppdateringer og månedlige sikkerhetsoppdateringer, det har hatt en negativ effekt på SoC-leverandører som Qualcomm. Faktisk har Treble faktisk økt kompleksiteten, og dermed ingeniørkostnadene, forbundet med å gi Android OS-oppdateringsstøtte for et gitt brikkesett. Det har begrenset lengden på støtten som Qualcomm kan gi for sine SoC-er, men det vil snart endre seg. Alle Snapdragon SoCs lanseres med Android 11 eller nyere – starter med Snapdragon 888, Qualcomm vil støtte 3 Android OS-versjonsoppdateringer (lanseringsutgivelse + 3 bokstavsoppgraderinger) samt 4 år med sikkerhetsoppdateringer. Det er et ekstra år enn de tidligere ga for flaggskipet deres i 800-serien.
Dagens kunngjøring er betydelig, men den kan ikke forstås uten bakgrunnskunnskapen om hva Google forsøkte å oppnå med Project Treble for 3 år siden.
Diskant opprettet en splittelse mellom Android OS-rammeverket (inkludert all UI-koden, API-er og systemprosesser som apper samhandle med) og enhetsspesifikk programvare på lavt nivå (inkludert de underliggende Linux-kjernen og maskinvareabstraksjonslagene, eller HAL). Den enhetsspesifikke programvaren på lavt nivå kommuniserer med Android OS-rammeverket gjennom en veldefinert, stabil leverandørgrensesnitt. Hver Android OS-versjon garanterer bakoverkompatibilitet med leverandørimplementeringen, noe Google sikrer gjennom bruk av leverandørtestsuiten (VTS), en standardisert samsvarstestpakke. Dette betyr at for eksempel Android 11 OS-rammeverket er bakoverkompatibelt med leverandørimplementeringen designet for Android 10. Faktisk publiserer Google Generic System Images (GSI) for hver nye Android-utgivelse, kildebygde systembilder som er bakoverkompatible med de siste 3 versjonene av leverandørimplementeringer. Når en OEM bygger en ny Android-enhet, står de fritt til å endre Android OS-rammeverket for å introdusere nye proprietære funksjoner og APIer, men de må sikre at enhetens leverandørimplementering er kompatibel med GSI.
Dette er først og fremst hvordan Treble reduserer fragmentering og øker hastigheten på leveringen av nye OS-oppdateringer - det er mye mindre brudd ved sammenkobling av Android OS-rammeverket (som er åpent) kilde og levert av Google) og enhetsspesifikk programvare på lavt nivå (som ofte er lukket kildekode og levert under kontrakter med SoC-leverandører) takket være den stabile leverandøren grensesnitt. Ideelt sett betyr det at OEM-er kan bruke mindre tid på å fikse feil med maskinvare og mer tid på å overføre endringer på systemnivå på toppen av den nyeste Android OS-utgivelsen. Faktisk, siden Treble ble introdusert, sier Google at OEM-er har tatt i bruk den nyeste Android OS-utgivelsen mye raskere enn før. "På det tidspunktet Android 11 ble lansert var det 667 millioner aktive brukere på Android 10, hvorav 82% fikk sin Android 10-konstruksjon via en OTA-oppdatering," sa Google.
Fordi hver ny Android-utgivelse legger til støtte for flere maskinvarefunksjoner (operativsystemet må støtte nye funksjoner for å holde tritt med de raske fremskritt i mobilindustrien), må Google oppdatere leverandørgrensesnittet for det utgivelse. Selskapet definerer dermed nye HAL-krav og pålegger nye Linux-kjerneversjoner, men de krever kun enheter lansering med den nye Android OS-utgivelsen for å faktisk støtte disse leverandørpåvirkende endringene. For eksempel, hvis Google endrer Androids kamera-HAL for å støtte flere bakre kamerasensorer, må bare nye enheter som lanseres med den nye Android-versjonen støtte den oppdaterte HAL, mens eldre enheter som oppgraderer til den nye utgivelsen kan gjenbruke sin eldre leverandørimplementering uten denne nye kamera-HAL krav. Dette reduserer kostnadene og kompleksiteten – fra en OEMs perspektiv – ved å bringe en ny Android OS-utgivelse til en eldre enhet. Problemet er imidlertid at denne tilnærmingen introduserer ekstra kompleksitet for SoC-leverandører som Qualcomm, MediaTek og andre.
Som et resultat av dette designprinsippet må Qualcomm og andre SoC-leverandører støtte flere kombinasjoner av Android OS-rammeprogramvare og leverandørimplementeringer. En SoC-leverandør som støtter 3 generasjoner av Android OS-versjoner for et bestemt brikkesett, må støtte 6 kombinasjoner av OS-rammeprogramvare og leverandørimplementeringer. Det er fordi mens OEM-er kan slippe unna med å gjenbruke en eldre leverandørimplementering for å omgå ny HAL- og Linux-kjerne versjonskrav, må SoC-leverandører sikre at deres leverandørimplementeringer støtter både det gamle og det nye krav. De får ikke velge og vrake. Multipliser det med dusinvis av brikkesett som en SoC-leverandør må støtte, og du kan se hvordan Treble faktisk har økt kompleksiteten for dem.
Det er av denne grunn at Qualcomm og andre SoC-leverandører vanligvis bare gir maksimalt 2 OS-bokstavoppgraderinger og 3 års sikkerhetsoppdateringer for et bestemt brikkesett. Selv om jeg ikke er klar over de nøyaktige kostnadene, antar jeg at det ikke er økonomisk mulig for SoC-leverandører som Qualcomm å støtte brikkesett mye lenger enn det. Vi har sett Qualcomm og andre SoC-leverandører noen ganger gi støtte lenger, men det avhenger av etterspørselen fra OEM-er for å gjøre det økonomisk. Hvis det ikke eksisterer en slik etterspørsel, faller det på OEM-er å bære hovedtyngden av utviklingskostnadene for å få frem en ny Android-utgivelse – og det er ikke en lett prestasjon. Men takket være den samlede innsatsen fra Google og Qualcomm, vil sistnevnte nå støtte 4 Android OS versjoner og 4 år med sikkerhetsoppdateringer for utvalgte Snapdragon-brikkesett, som starter med Qualcomm Snapdragon 888.
For å gjøre dette mulig har Google utvidet Project Trebles «no-retroactivity-prinsipp» til SoC-er i tillegg til enheter. Dette betyr at nye krav til HAL- og Linux-kjerneversjon ikke vil ha tilbakevirkende kraft for SoC-er. Så for eksempel en SoC som lanseringer med Android 11 (som Snapdragon 888) kan gjenbruke den samme leverandørimplementeringen for å støtte Android 12 til og med Android 14. Dermed kan SoC-leverandører utvikle en enkelt Board Support Package (BSP) for et bestemt brikkesett å distribuere til OEM-er, i stedet for å opprettholde flere versjoner av BSP-en som må oppdateres med hver nye Android utgivelse. Dette reduserer ingeniørkostnadene forbundet med å støtte Android på et bestemt brikkesett dramatisk, og gir SoC-leverandører som Qualcomm muligheten til å støtte brikkesettene deres lenger.
Google jobber også med Qualcomm for å sikre at sistnevnte gjenbruker samme OS-rammeprogramvare på tvers av flere Qualcomm brikkesett, noe som ytterligere reduserer antallet OS-rammeverk og leverandørimplementeringskombinasjoner som Qualcomm må Brukerstøtte. SoC-leverandører endrer for tiden AOSP-rammekoden og bygger sine egne versjoner av generiske systembilder. Qualcomms kalles for eksempel QSSI, mens MediaTeks kalles MSSI. Disse SoC-spesifikke systembildene vil nå garantert være kompatible med flere brikkesett så vel som med eldre leverandørprogramvare, omtrent som Googles AOSP GSI.
Enheter med Qualcomm Snapdragon 888 forventes å lanseres veldig snart, og starter med Xiaomi Mi 11- og Samsung Galaxy S21-serien. Selv om vi håper Google og Qualcomms kunngjøring betyr at alle Snapdragon 888-enheter vil få 3 år med Android OS og sikkerhetsoppdateringer, er det ingen garanti for at dette vil være tilfelle. OEM-er må fortsatt investere betydelige summer for å utvikle og distribuere nye OS-versjoner - men det er mye mer sannsynlig at det skjer nå som Qualcomm selv vil støtte 4 Android OS-versjoner. Her håper vi at en eller flere OEM-er drar nytte av dagens kunngjøring for å kunngjøre utvidet programvarestøtte for deres fremtidige flaggskiptelefoner drevet av Snapdragon 888. De fleste OEM-er tilbyr bare 2 år med Android-oppdateringer for øyeblikket, mens både Samsung og Google lover 3 år. Det er fortsatt alt for kort sammenlignet med Apple og har med rette blitt kalt ut mange, mange ganger og vil fortsette å bli kalt ut til gapet er redusert.
Når det gjelder de andre SoC-leverandørene, er Google i samtaler med dem om å anvende dette nye prinsippet om tilbakevirkende kraft slik at de også kan tilby utvidet programvarestøtte for brikkesettene sine. Vi har ingen bekreftelse fra MediaTek eller andre SoC-leverandører, men vi ser ingen grunn til at de ikke ville være med på denne ideen – i hvert fall for nye brikkesett. Ifølge Google forventer de at stort sett kun nylanserte SoC-er vil dra nytte av disse endringer, så ikke forvent at noen av dine nåværende enheter får utvidet programvarestøtte på grunn av dagens kunngjøring.
Denne artikkelen ble oppdatert kl. 13:50 ET 16.12.2020 for å endre "enheter" i tittelen til "brikkesett" for bedre å reflektere hvor endringene vil tre i kraft. Ytterligere informasjon er lagt til artikkelen med tillatelse fra Google.
Denne artikkelen ble oppdatert klokken 14:10 ET for å gjenspeile at Google og Qualcomm lover støtte for 4 Android OS-versjoner – som betyr lanseringsutgivelsen pluss 3 år med Android OS-oppdateringer – i stedet for 4 år med OS oppdateringer. Qualcomm lover imidlertid å gi 4 år med sikkerhetsoppdateringer.