Mellékleteink: HUP | Gamekapocs
Keres

Újra nekifut az androidos frissítések problémájának a Google

Gálffy Csaba, 2017. május 15. 17:18

Nincs miért kertelni: gyalázatos az Android operációs rendszert futtató eszközök frissítési gyakorlata. A Google, a gyártók és a mobilszolgáltatók között gazdátlanul heverő frissítések ügyét most a platformot fejlesztő Google karolná fel. Az Android O hozza el a Project Treble-t.

Új megközelítéssel, az operációs rendszer modularizálásával lépne a Google az Android platform egységesítése irányába, már az Android O-tól fogva. Drákói lépés jön: a cég leválasztaná az operációs rendszert és a hardveres illesztőprogramokat egymásról, közéjük pedig szabványos interfészt tenne. A paradigma jóval olcsóbbá tenné a kiadott telefonok frissen tartását, így a gyártók is összeszedhetnék magukat.

Project Treble

Az új kezdeményezés megértéséhez előbb azt érdemes szemügyre venni, hogy hogyan működnek jelenleg az androidos implementációk. A Google a kezdetek óta feltételként szabta az androidos gyártók számára, hogy az eszközöknek kötelezően kompatibilisnek kell lenniük az Android API-val. Pontosabban: ha egy fejlesztő alkalmazást ír az általános és egységes Android API-t figyelembe véve, annak hibátlanul futnia kell minden androidos eszközön. A Google ezt a kompatibilitást úgy kényszeríti ki, hogy saját komponenseit, köztük a Play Store-hozzáférést kizárólag azon eszközök számára biztosítja, amelyek e kompatibilitási teszteken átmennek. Ez persze nem gátolja meg a fragmentációt a különböző Android-verziók között, de biztosítja, hogy azonos API-szintet (Android verziót) használó eszközök azonos módon is viselkednek.

Ezt a kompatibilitást, vagyis a tulajdonképpeni Developer API-t egy részletes Compatibility Definition Document (CDD) kodifikálja, amely a gyakorlatban az Android-implementációk közös specifikációját jelenti. A gyártók mehetnek ennél tovább, adhatnak saját egyedi API-kat ehhez a csokorhoz, de a CDD-ben lefektetett alapkövetelményeket minden körülmények között teljesíteni kell. A teljesítést pedig a Google nem bemondásra hiszi el, készült ugyanis egy Compatibility Test Suite, amely az API-k implementációját egészen részletekbe menően teszteli és vizsgál minden, a szabványostól eltérő viselkedést. Hogy mennyire részletes a CTS, azt jól mutatja, hogy ma már millió fölötti a lefutó vizsgálatok száma.

"A Project Treble célja ugyanazt tenni az Android Keretrendszerrel, amit a CTS tett az alkalmazások számára" - mondja a Google. A koncepció szerint a gyártói implementáció (vendor implementation) és a keretrendszer közé is szabványos, szigorúan szabályozott, tesztelhető, dokumentált interfész kerül, amelyet a Vendor Test Suite segítségével validál majd a vállalat.

Elválik a rendszer és a hardverillesztők

A VTS szintje az "eszközspecifikus, nagyrészt a lapkagyártók által írt alacsony szintű szoftverek" szintjét jelenti - a gyakorlatban ez a különböző illesztőprogramok szintjét jelenti. Az interfész tehát e meghajtók és az operációs rendszer ("Android Framework") sztenderdizált kapcsolódási pontja lesz, amely lehetővé teszi mindkét oldal zökkenőmentes cseréjét: lesz lehetőség a rendszer alatt eszközt, vagy az eszközön rendszert cserélni. Míg mindkét oldal tiszteli a szabványos interfészt, addig az ilyen váltásnak problémamentesnek kell lennie.

Értelemszerűen ez azt is jelenti, hogy amíg az új Android verzió kompatibilis a meglévő interfészekkel, addig gond nélkül cserélhető majd a meglévő hardvereken. A visszafelé kompatibilitásnak az lehet gátja, ha az interfész szabványát a Google módosítja és például új hardveres funkciókat követel meg, ezt értelemszerűen az előző generációs VTS-szintet támogató hardver nem fogja majd tudni lekövetni. Az ilyen váltásoknak azonban elvben ritkának kell lenniük, így eljöhet a hosszanfriss androidos telefonok korszaka.

Hozzáadott érték, hogy a szabványos hardveres interfésszel a biztonsági frissítések kiadása is jelentősen felgyorsulhat. A Google tervei szerint ugyanis az olyan kritikus szoftverelemek, mint a rádiós baseband a VTS vonala alatt maradnak, így valószínűleg szolgáltatói tesztelés nélkül is bevethető lesz majd. Ez nagyon fontos áttörés lenne, a szolgáltatók ugyanis erre a tesztelésre nem szánnak elegendő erőforrást, így nagyon sokszor rajtuk csúszik el a frissítés.

A VTS bevezetése nagyon érdekes új fejezet lesz a ROM-főzők világában is. A szabványos interfész ugyanis azt jelenti majd, hogy (nyitott bootloader esetén) nem csak a gyártók, hanem a felhasználók is tetszőlegesen cserélhetik a rendszert a telefonjukon, egészen addig, amíg az a VTS interfésszel kompatibilis, működnie is kell.

Vannak kemény korlátok

A moduláris operációs rendszer koncepciója egyébként ismerős lehet egy másik platformról: a Windows operációs rendszer ugyanis a kezdetek óta pontosan ezt a megközelítést használja. Maga a rendszer a hardverrel illesztőprogramokon keresztül tart kapcsolatot, amíg a meghajtók kompatibilisek, a rendszer probléma nélkül frissíthető. Komoly gond ezért csak akkor lépett fel, amikor a rendszer változtatott a meghajtó-architektúrán (lásd Windows XP és Windows Vista), ettől eltekintve általában zökkenőmentes a váltás.

A fenti problémát egyébként a Google új megközelítése is örökli majd, tehát ha változik az interfész és az SoC fejlesztője nem tesz elérhetővé modernizált meghajtót, akkor bizony az androidos frissítés sem lesz telepíthető. Erre már korábbról is van példa, a Qualcomm például iparági információk szerint saját üzleti döntésével fektette meg a 2013-as és 2014-es csúcsmodellek Android 7.0-s frissítését azzal, hogy nem tette elérhetővé a frissített meghajtócsomagot a gyártók számára, beleértve a Google-féle Nexusokat is.

Facebook

Mit gondolsz? Mondd el!

Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.