Googles Project Treble modulariserer Android, så OEM'er kan opdatere enheder hurtigere

I dag har Google annonceret Project Treble, et projekt, der modulariserer Android, så OEM'er kan betjene Android-opdateringer hurtigere.

En af de største kritikpunkter af Android er fragmentering af softwareopdateringer. Den dag i dag er mange enheder nødt til at vente flere måneder efter deres Google-enheder, bare for at modtage den næste større version af Android. For eksempel blev Android Nougat officielt udgivet i august sidste år, men det har taget OEM'er måneder i træk at udrulle Android 7.X til deres brugere. Fra denne måned kører kun cirka 7 % af alle Android-enheder Android Nougat. I et forsøg på at bekæmpe den lange periode mellem frigivelse af nye versioner af Android og OEM'er, der opdaterer deres enheder, har Google annonceret den største ændring af Android-systemarkitekturen på lavt niveau til dato - Projekt Diskant.


Project Treble - Modularisering af Android for at forbedre softwareopdateringer

For det første, for at forstå, hvad det er, som Project Treble præcis gør, er det vigtigt for dig at forstå den generelle opdateringsproces, der er involveret i hver iteration af Android. Processen kan opsummeres i cirka 5 eller deromkring trin, som sådan:

  1. AOSP-udgivelse – Google udgiver kildekoden til den nye Android-udgivelse
  2. Opstart/hardwarekompatibilitet - Siliciumproducenter (Qualcomm, Samsung, Hisilicon, MediaTek osv.) ændre kildekoden, så Android kan starte på deres chips, og al hardware på chippen fungerer som forventet
  3. OEM-modifikationer - Denne modificerede kilde gives derefter til enhedsproducenter (OEM som f.eks Samsung, LG, Huawei/Honor, OnePlus, HTC osv.), så de kan ændre kilden til at inkludere deres egen software.
  4. QA/Test - OEM'er gennemgår testfaser af softwaren internt og tester også deres software med deres transportpartnere.
  5. Generel udgivelse - opdateringen bliver til sidst gjort tilgængelig for slutbrugere over flere uger gennem OTA-opdateringer

Google er generelt meget hurtig til at frigive kildekoden for hver ny Android-version, og endda deler deres kode privat med nogle af deres partnere så de kan komme i gang med straks at opdatere deres kodebase. Google har ingen kontrol over, hvor lang tid trin 4 og 5 tager, men de har fundet ud af en måde at reducere den tid, der bruges under trin 2. Holdet bag Android "re-arkitekterer" Android på et lavt niveau for at gøre det nemmere for siliciumproducenter at opdatere og teste deres kode.

Til det formål introducerer Google det, de kaldes Leverandørgrænseflade. Denne leverandørgrænseflade ligner i sin funktion Compatibility Definition Document (CDD) og Compatibility Test Suite (CTS), som begge sikrer, at OEM'er ved præcis, hvad de skal implementere, for at deres enheder kan opfylde de nødvendige krav til at køre Google Play Services på den seneste version af Android. Google modulariserer Android, så Android OS-rammerne holdes adskilt fra den enhedsspecifikke software på lavere niveau skrevet af siliciumproducenterne. Leverandørgrænsefladen er valideret af Vendor Test Suite (VTS), så siliciumproducenter ved præcis, hvilke krav der skal opfyldes, for at deres chips understøtter opstart af Android.

Den største fordel ved denne ændring er, at enhedsproducenter (OEM'er) nu kan vælge at opdatere deres telefoner ved at opdatere Android OS-rammerne uden at skulle vente på siliciumproducenter for at opdatere deres leverandørimplementeringskode. Mens dette træk, hvis det blev foretaget tidligere, næppe ville have påvirket uanset om der er enheder på MSM8974 eller ej modtage Android 7.0 Nougat-opdateringen (da problemet der stammer fra CDD'en, der kræver enten Vulkan Graphics API eller GLES 3.1, hvilket ER noget, som OEM'er skal vente på siliciumproducenter at bringe GPU-understøttelse til i deres kildekode), skulle dette træk stadig reducere den tid, det tager for store Android-opdateringer at nå ud til hænderne på forbrugere.

Hvor meget dette træk vil reducere opdateringsforsinkelsen, kan vi ikke præcist forudsige. Microsoft løste dette problem for længe siden med hardwareabstraktion af Windows-drivere, så vi håber, at denne store ændring på lavt niveau bringer Android noget tættere på Windows på den måde. Den nye Project Treble-arkitektur kører allerede på Google Pixel og Pixel XL på Android O Developer Forhåndsvisning, og den fulde dokumentation for projektet vil blive gjort tilgængelig med lanceringen af ​​Android O senere sommer.

Desværre betyder det, at for langt de fleste eksisterende enheder, vil du ikke se frugterne af Android-teamets arbejde i Project Treble. Der vil gå et par år, før vi virkelig kan se, om dette træk har haft en væsentlig effekt på at reducere den tid, du skal vente på at få den næste variant af Android. Ikke desto mindre er dette en spændende udvikling for Android-fans, da den løser et af kerneproblemerne med det operativsystem, som mange af os kommer til XDA-Developers fora for at tage fat på: softwareopdateringer. Vi håber, den lever op til hypen.


Kilde: Android Developers Blog