Googles Project Treble modulariserer Android slik at OEM-er kan oppdatere enheter raskere

I dag har Google annonsert Project Treble, et prosjekt som modulariserer Android slik at OEM-er kan levere Android-oppdateringer raskere.

En av de viktigste kritikkene av Android er fragmentering av programvareoppdateringer. Frem til i dag må mange enheter vente flere måneder etter Google-enhetene sine for å motta den neste store versjonen av Android. For eksempel ble Android Nougat offisielt utgitt i august i fjor, men det har tatt OEMs måneder i strekk å rulle ut Android 7.X til brukerne. Per denne måneden kjører bare omtrent 7 % av alle Android-enheter Android Nougat. I et forsøk på å bekjempe den lange tidsperioden mellom utgivelsen av nye versjoner av Android og OEM-er som oppdateres deres enheter, har Google annonsert den største endringen til lavnivå systemarkitekturen til Android til dags dato - Prosjekt diskant.


Project Treble - Modularisering av Android for å forbedre programvareoppdateringer

For det første, for å forstå hva det er Project Treble nøyaktig gjør, er det viktig for deg å forstå den generelle oppdateringsprosessen som er involvert med hver iterasjon av Android. Prosessen kan oppsummeres i omtrent 5 trinn, som sådan:

  1. AOSP-utgivelse – Google publiserer kildekoden til den nye Android-utgivelsen
  2. Oppstart/maskinvarekompatibilitet - Silisiumprodusenter (Qualcomm, Samsung, Hisilicon, MediaTek, etc.) endre kildekoden slik at Android kan starte opp på brikkene deres, og all maskinvare på brikken fungerer som forventet
  3. OEM-modifikasjoner - Denne modifiserte kilden blir deretter gitt til enhetsprodusenter (OEM som f.eks Samsung, LG, Huawei/Honor, OnePlus, HTC, etc.), slik at de kan endre kilden til å inkludere sin egen programvare.
  4. QA/Testing - OEM-er gjennomgår testfaser av programvaren internt, og tester også programvaren deres med sine transportørpartnere.
  5. Generell utgivelse - oppdateringen blir etter hvert gjort tilgjengelig for sluttbrukere over flere uker gjennom OTA-oppdateringer

Google er generelt veldig raske til å gi ut kildekoden til hver nye Android-versjon, og til og med deler koden sin privat med noen av partnerne sine slik at de umiddelbart kan komme i gang med å oppdatere kodebasen. Google har ingen kontroll over hvor lang tid trinn 4 og 5 tar, men de har funnet ut en måte å redusere tidsbruken under trinn 2. Teamet bak Android «re-arkitekterer» Android på et lavt nivå for å gjøre det enklere for silisiumprodusenter å oppdatere og teste koden sin.

For det formål introduserer Google det de kalles Leverandørgrensesnitt. Dette leverandørgrensesnittet ligner i funksjon på Compatibility Definition Document (CDD) og Compatibility Test Suite (CTS), som begge sikrer at OEM-er vet nøyaktig hva de trenger å implementere for at enhetene deres skal oppfylle kravene som kreves for å kjøre Google Play-tjenester på den nyeste versjonen av Android. Google modulariserer Android slik at Android OS-rammeverket holdes atskilt fra den enhetsspesifikke programvaren på lavere nivå skrevet av silisiumprodusentene. Leverandørgrensesnittet er validert av Vendor Test Suite (VTS), slik at silisiumprodusenter vet nøyaktig hvilke krav som må oppfylles for at brikkene deres skal støtte oppstart av Android.

Hovedfordelen med denne endringen er at enhetsprodusenter (OEM) nå kan velge å oppdatere telefonene sine ved å oppdatere Android OS-rammeverket uten å måtte vente på silisiumprodusenter for å oppdatere leverandørens implementeringskode. Selv om dette trekket, hvis det ble gjort tidligere, neppe ville ha påvirket om enheter på MSM8974 eller ikke motta Android 7.0 Nougat-oppdateringen (ettersom problemet der stammer fra CDD-en som krever enten Vulkan Graphics API eller GLES 3.1, som ER noe som OEM-er må vente på silisiumprodusenter å ta med GPU-støtte for i kildekoden deres), bør dette trekket fortsatt redusere tiden det tar for store Android-oppdateringer å nå betraktelig forbrukere.

Hvor mye dette trekket vil redusere oppdateringsforsinkelsen, kan vi ikke forutsi nøyaktig. Microsoft løste dette problemet for lenge siden med maskinvareabstraksjon av Windows-drivere, så vi håper at denne store endringen på lavt nivå bringer Android noe nærmere Windows på den måten. Den nye Project Treble-arkitekturen kjører allerede på Google Pixel og Pixel XL på Android O Developer Forhåndsvisning, og den fullstendige dokumentasjonen for prosjektet vil bli gjort tilgjengelig med lanseringen av Android O senere sommer.

Dessverre betyr det at for det store flertallet av eksisterende enheter vil du ikke se fruktene av Android-teamets arbeid i Project Treble. Det vil ta noen år før vi virkelig kan se om dette trekket har hatt en betydelig effekt på å redusere tiden du må vente for å få den neste smaken av Android. Likevel er dette en spennende utvikling for Android-fans, da den tar for seg et av kjerneproblemene med operativsystemet som mange av oss kommer til XDA-Developers-foraene for å ta opp: programvareoppdateringer. Vi håper den lever opp til hypen.


Kilde: Android Developers Blog