Szeretett volna valaha is kipróbálni egy frissítést anélkül, hogy ténylegesen frissítene? Az Android 10 DSU-ját erre tervezték, de jelenleg korlátozott. Ez hamarosan megváltozhat.
Az Android operációs rendszer és a biztonsági szint töredezettsége óriási probléma, amelynek leküzdésére a Google sok mérnöki erőfeszítést fektet be. Az elmúlt két évben a Google két fontos kezdeményezést jelentett be, amelyek célja a frissítések kibocsátásának felgyorsítása: Projekt Treble és Projekt fővonal. Ez utóbbit csak idén májusban jelentették be Google I/O 2019, és csak az Android 10 rendszerrel induló eszközökön támogatott. Az előbbi azonban azóta is létezik Google I/O 2017, tehát láttuk, hogy mekkora hatással volt az Android frissítéseire Android 9 Pie rendszerrel és Android 10.
A töredezettség csökkentése mellett a Google azt is szeretné, ha a Project Treble hasznos lenne az alkalmazásfejlesztők számára. Ezért leplezték le Dinamikus rendszerfrissítések (DSU) az Android 10 rendszerben, hogy a fejlesztők kipróbálhassák egy új operációs rendszer-frissítés barebone verzióját a rendszertöltő feloldása vagy az adatok törlése nélkül. Látva a DSU-ban rejlő lehetőségeket, a Google nem áll meg itt – kibővíti a segédprogramot, lehetővé téve az OTA-frissítések telepítését az OEM-ektől ugyanúgy, mint a GSI-ket.
Ez sok zsargon, de képzeld el, hogy ez a jövőben megtörténik: egy OEM kiad egy telefont Android 10-zel, és elindít egy béta programot az Android 11-hez. Érdekli, hogy kipróbálja ezt a bétaverziót, hogy megismerje az új funkciókat, de nem szeretné kockáztatni jelenlegi napi vezetőjének stabilitását. Ahelyett, hogy villogtatná a béta frissítést, és azt remélné, hogy tökéletesen stabil lesz, miért nem telepíti ideiglenesen a DSU folyamaton keresztül? Ha nem tetszik, csak indítsa újra, és a beállítások visszatérnek a normál kerékvágásba. Ha tetszik, "elkötelezheti magát" a frissítés mellett.
Nem tudom, ti hogy vagytok vele, de ez örvendetes változás lenne az Androidon, ami élvezetesebbé tenné a bétatesztelést. Többé nem kell elköteleződnie egy béta frissítés mellett, csak hogy lássa, milyen az. Biztos vagyok benne, hogy sokan vágynak arra, hogy Android 10 bétaverziót lássanak az eszközükön, de előfordulhat, hogy nem lesz kényelmes, hogy azonnal telepítse. A DSU-n végrehajtott változtatásokkal ez már nem aggodalomra ad okot.
Dinamikus rendszerfrissítések Android 10+ - Mi változik
Luca Stefani, az XDA Portál barátja és a Elismert Fejlesztő, tájékoztatott bennünket a új commit összevonva az AOSP-ben "csatlakoztassa több DSU partíciót, ha van." A véglegesítés módosítja a fájlrendszer táblát (fstab) és a init folyamat, hogy a rendszertől eltérő DSU-partíciókat lehessen csatlakoztatni a rendszerindítás során, beleértve a terméket és a szállítót. folyamat.
Jelenleg a DSU-t úgy tervezték, hogy csak egy általános rendszerképet (GSI), egy AOSP-ből összeállított barebone rendszerképet indítson el, így tesztelheti az új API-kat és a legújabb Android-frissítés egyéb változásait. Ezzel a változtatással azonban a DSU termék- és szállítóképeket is elfogad. Az előbbi eszközspecifikus alkalmazásokat, könyvtárakat és egyéb fájlokat tartalmaz, míg az utóbbi eszközspecifikus bináris fájlokat tartalmaz. A Project Treble úgy hozta létre, hogy az eszközt egy rendszerkép használatával indítsa el, eszközspecifikus fájlok nélkül, így a termék és a szállító betöltésének engedélyezése nem tűnik túl sok értelmesnek.
A Google egyik mérnöke azonban kifejezetten azt állítja, hogy ez a változás az, hogy "engedélyezze az OEM-ek számára, hogy OTA-csomagokat telepítsenek a /data fájlba, majd a [DSU" folyamat segítségével csatolják a product.img fájlt, system.img, [és] vendor.img a /data fájlból." Ez azt jelenti, hogy ahelyett, hogy felülírná az aktuális telepítést az új OTA csomaggal, az OTA ideiglenesen betölthető DSU-n keresztül. Az OTA-frissítés kipróbálása után "a felhasználó eldöntheti, hogy szeretné-e ezeket a képeket a /super mappába helyezni vagy sem." Ez az utolsó rész kb A változtatások „bevezetése” még mindig folyamatban van, mivel a Google egyik mérnöke megjegyzi, hogy „jelenleg nincs tervünk DSU-partíciók létrehozására állandó a DSU-kontextusban." Ezután elmondja, hogyan lehetne ezt megvalósítani, de ez a megvalósítás "túlmutat" aktuális patch.
Néhány kifejezést és fogalmat meg kell magyaráznunk itt, mert a Google szereti megváltoztatni a partíciós sémát minden Android-verzióban. Kezdetnek ajánlom, hogy olvassa el korábbi cikkemet Dinamikus rendszerfrissítések a működésének átfogó áttekintése érdekében, de összefoglalva, kihasználja a "dinamikus partíció" koncepcióját, a tároló egy valós partícióját (ún. a "szuper" partíció), amely átméretezhető logikai partíciókra van osztva (beleértve a rendszert, a szállítót, a terméket és a system_ext-et), hogy ideiglenesen telepítsen egy GSI. A GSI telepítésekor a DSU a meglévő userdata partíció átméretezésével helyet teremt az új rendszernek és a felhasználói adatoknak. A DSU-támogatás építőkövei (dinamikus partíciók, ramdisk és ellenőrzőpontok az adatmentésekhez) indítási követelmények Android 10, tehát minden, az Android operációs rendszer új verziójával induló eszköznek támogatnia kell a DSU-t. A DSU nem az a kettős rendszerindítási megoldás az egyéni ROM-okhoz, amelyeket néhányan keresnek, mert csak az Android Verified Boot (AVB) kulcsainak megfelelő képek telepíthetők. Ezzel az új változtatással azonban sokkal hasznosabbnak bizonyulhat a jövőben.
A dinamikus partíciók mellett a Google bevezette a „virtuális A/B” fogalmát az Android 10-ben. Ez alapvetően a megvalósítása a kettős A/B partíció korábban, de logikai partíciókkal. Az A/B partíciók fontos partíciók másolatait foglalják magukban a zökkenőmentes és biztonságos frissítések érdekében. A "virtuális A/B" használatával a Google egyik mérnöke úgy képzeli el, hogy a DSU-partíciókat a jelenlegi telepítés partícióira "lekötheti"; A jelenlegi A/B OTA frissítési folyamathoz hasonlóan talán az új képek módosításai az inaktív partíción történnek.
Ezek a változtatások még fejlesztés alatt állnak, és eltarthat egy ideig, amíg a Google vagy az OEM-ek megszokják őket. Mi Valószínűleg ennek semmilyen megvalósítása nem fog megjelenni, amíg legkorábban az Android 11 R megjelenése után meg nem jelenik év. Ennek ellenére nincs garancia arra, hogy az OEM-ek ezt a funkciót az OTA-frissítésekhez is alkalmazzák. Tekintettel arra, hogy ez mennyire hasznosnak tűnik a béta teszteléshez, úgy gondolom, hogy a Google már együttműködik az érdeklődő OEM-ekkel, hogy engedélyezze ezt a funkciót a jövőbeli frissítésekhez. Engem személy szerint izgat az új Android-frissítések vásárlása előtti kipróbálása, de mi van veled?