A Google bemutatta a dinamikus rendszerfrissítést, egy új módszert a GSI telepítésére Android Q rendszerben, amely nem igényli a rendszerbetöltő feloldását.
Az Android 8.0 Oreo megjelenése mellett a Google bemutatta a leplet Projekt Treble: az Android OS keretrendszer és a gyártó HAL-ok és Linux kernel kommunikációjának jelentős átépítése. A Treble egy jelentős kezdeményezés, amelynek célja az Android platform verziószámának csökkentése és biztonsági javítás töredezettsége, és minden Android Pie-vel induló Android márkájú eszköznek támogatnia kell a Project Treble-t. Az OEM-ek és a gyártók úgy tesztelik a Treble kompatibilitást, hogy elindítanak egy generikus rendszerképet (GSI) – az AOSP tiszta Android készletét – és átadják a Vendor Test Suite (VTS) és Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). A GSI hasznosnak bizonyult nemcsak abban, hogy lehetővé tette az OEM-eknél dolgozó szoftvermérnökök számára a Treble-kompatibilitás tesztelését, hanem megnyitotta az ajtót egy
nagy egyéni ROM közösség az XDA-n. Az Android Q kiadás esetében a Google egy másik csoport számára szeretné hasznossá tenni a GSI-ket: az alkalmazásfejlesztők számára.Azóta, hogy az adott Android platform első stabil kiadása és forráskódja általában megjelenik augusztusban, azoknak a fejlesztőknek, akik valódi eszközön szeretnék tesztelni a következő Android-kiadást, általában szükségük van egy Google okostelefonhoz való hozzáférésre, ha nem akarnak megvárni, amíg a frissítés eléri a saját hardverüket. A Google azonban együttműködött az OEM-ekkel, hogy egy Android P béta több eszközre tavaly, és idén ezt követték egy Android Q béta. A hivatalos Android Q béta mellett a Google idén kiadott egy hivatalos Q béta GSI így minden Project Treble-kompatibilis eszközzel rendelkező fejlesztő telepítheti a legújabb Q-kiadást anélkül, hogy hónapokat kellene várnia arra, hogy a build elérje eszközeit. A következő Android-kiadás tesztelésének ez az új módja több lehetőséget és így több időt biztosít a fejlesztőknek, hogy teszteljék alkalmazásaikat. jelentős változások az Androidban.
Sajnos a jelenlegi módszer a GSI telepítése nehéz lehet. Ehhez fel kell oldani a rendszerbetöltőt – ami azt jelenti, hogy törölni kell az összes felhasználói adatot és/vagy meg kell semmisíteni a garanciát – és egy kép felvillantását a fastboot protokollon keresztül. Ez nem egy gyors és egyszerű folyamat egy alkalmazásfejlesztő számára, ha az eszköze még a rendszerbetöltő feloldását is lehetővé teszi. Éppen ezért a elmúlt néhány hónap, a Google a GSI-k indításának új módján dolgozott. Adjon meg egy új funkciót, a dinamikus rendszerfrissítést vagy DSU-t.
(Ezt a funkciót korábban „Live Image”, „Dynamic Android” és „Android on Tap” néven fejlesztették ki, ezért ne lepődjön meg, ha a Google néhány héten vagy hónapon belül másként hívja.)
Dinamikus rendszerfrissítések Android Q-ban
A DSU funkció célja, hogy lehetővé tegye a fejlesztő számára a GSI rendszerbe való indítását anélkül, hogy megzavarná az aktuális telepítést. Ez azt jelenti, hogy a rendszerbetöltőt nem kell feloldani, és a felhasználói adatokat sem kell törölni. A telepítési folyamat is jelentősen leegyszerűsödik, mivel a Google parancssori felületet biztosított az ADB-n keresztül, és egy alkalmazást, amely intenten keresztül vezérelhető. Így néz ki egy GSI rendszerindítása DSU használatával:
Ebben a videóban* az Android Q béta 3 rendszert futtató Google Pixel 3 XL újraindul GSI-be. Ebben a környezetben az alkalmazásfejlesztő telepítheti és tesztelheti alkalmazását Q API-kompatibilitás szempontjából. Amikor végeztek a teszteléssel, egyszerűen újraindíthatják az eszközön lévő szokásos Q béta 3 szoftvert. Alapvetően kettős GSI-t indít, így biztonságosan tesztelheti az alkalmazást!
*Ezt a videót a 2019-es Google I/O rendezvényen vettük fel, amikor a DSU még nem volt nyilvánosan elérhető, ezért a lefilmezett Pixel 3 XL-re épülő Q beta 3-at a Google némileg módosította, hogy DSU-támogatást is tartalmazzon. A Q béta 4 vagy újabb verziót futtató eszközök jogosultak a DSU támogatására, ha megfelelnek az alábbi követelményeknek.
A dinamikus rendszerfrissítések követelményei
A lényegében kettős rendszerindítást jelentő rendszer elindítása és futtatása nem volt könnyű feladat a Google számára. Jelentős változtatásokat kellett végrehajtani a partíciók kezelésében a Pixel 3-on, a Google DSU-tesztelőjén. Így a DSU támogatás első fő követelménye, hogy az eszköz támogassa dinamikus partíciók. A dinamikus partíciók a tároló egy valós partícióját foglalják magukban, amely átméretezhető logikai partíciókra van felosztva, például rendszer, szállító, odm, oem, termék stb. A GSI telepítése során helyet foglalnak le az új rendszer- és felhasználói adatok partíciók számára úgy, hogy a meglévő userdata partícióból kivonják a nem használt blokkokat. Mivel ezek az új partíciók több gigabájt méretűek is lehetnek, a DSU-támogatásnak csak logikai megoldással van értelme partíciókat különben az eszköznek tartósan több gigabájt tárhelyet kellene lefoglalnia a GSI számára installációk.
További követelmények közé tartozik a ramdisk, amely eldönti, hogy a rendszer helyreállítási, rendszer- vagy logikai partícióról induljon-e, valamint egy metaadat-partíció a GSI metaadatainak tárolására. A DSU-támogatás építőkövei általában az Android Q indítási követelményei, a Project Treble vezetője, Iliyan Malchev szerint. Nem vagyunk biztosak benne minden amely a DSU támogatásához szükséges, az Android Q indítási követelménye, de feltételezhetjük, hogy a legtöbb, ha nem az összes Android Q-val induló eszköz tud támogatja a DSU-t, még akkor is, ha a Google jelenleg nem követeli meg őket. Eddig csak a Pixel 3, Pixel 3 XL, Pixel 3a és Pixel 3a XL rendelkezik dinamikus partíciókkal, ezek közül az eszközök közül csak a Pixel 3 és a Pixel 3 XL támogatja a DSU-t az Android Q béta 4-ben. Bár a DSU támogatása nem szükséges, a Google reméli, hogy az OEM-ek mégis engedélyezik a funkciót, mert leegyszerűsíti a Treble kompatibilitás biztonságos tesztelését. Például egy OEM szoftvermérnök beállíthat egy GSI-t SD kártyán így gyorsan elindulhatnak több eszközön, hogy teszteljék a Treble kompatibilitást.
Biztonság a dinamikus rendszerfrissítésekhez
Mivel a DSU lényegében egy második operációs rendszert vezet be a keverékbe, a Google-nak gondoskodnia kell arról, hogy az új telepítést ne lehessen megváltoztatni az eszköz integritásának megsértése érdekében. Így a ugyanazok az alapvető biztonsági védelmek, mint az eredeti telepítés, a GSI-telepítésre is érvényesek: Android Verified Boot és SELinux házirendek. Ezenkívül csak az INSTALL_DYNAMIC_SYSTEM aláírással rendelkező|privilegizált engedéllyel rendelkező alkalmazások kezdeményezhetnek GSI-t telepítés, míg a MANAGE_DYNAMIC_SYSTEM aláírási engedéllyel rendelkező alkalmazások engedélyezhetik/letilthatják vagy törölhetik a GSI-t telepítés. Ez azt jelenti, hogy csak megbízható, rendszerszintű alkalmazások működhetnek a DSU-val.
Az eredeti felhasználói adatok védelmének biztosítása érdekében a Google hozzáadott egy extra védelmi mechanizmus Android Q-ban. ""Ellenőrző pont", a szolgáltatás az ellenőrzőpontos partíciók eredeti állapotának visszaállításával véd a felhasználói adatok megsemmisülése ellen. Az ellenőrző pontok azonban nem csak a DSU számára hasznosak. Az elromlás elleni védelemre is használják Projekt fővonal APEX modul és A/B OTA frissítések. (Eszközök A/B partíciókkal már rendelkezik visszaállítási védelemmel, de ezekhez a visszaállításokhoz vissza kell állítani a gyári adatokat, míg a felhasználói adatok ellenőrző pontjainál nem.)
GSI telepítése
Ha eszköze támogatja a DSU-t, például a Pixel 3 sorozatot, akkor egyszerűen telepítheti a GSI-t. Először is meg kell győződnie arról, hogy a Dynamic System funkciójelző engedélyezve van-e az alábbi két mód egyikén:
- Ha userdebug buildet használ, engedélyezze a settings_dynamic_android jelzőt a Beállítások > Rendszer > Fejlesztői beállítások > Szolgáltatásjelzők menüpontban.
- Ha felhasználói buildet használ, futtassa a következő adb shell parancsot:
setproppersist.sys.fflag.override.settings_dynamic_system 1
Ezután töltse le a legújabb Android Q béta GSI-t innen Google vagy az eszköz OEM-je. (A DSU csak a Google vagy egy OEM által aláírt GSI-k telepítését teszi lehetővé.) A letöltés után használja simg2img hogy a ritka képet nyers képpé alakítsuk. A gzip használatával csomagolja be a nyers képet, majd másolja az így létrejött archívumot egy helyre az eszközén külső tároló (pl. /data/media/0/Download) vagy tényleges külső adathordozó (például fizikai SD kártya). Végül indítsa el a DynamicSystemInstallationService alkalmazást a megfelelő szándékkal a telepítés megkezdéséhez:
adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592Miután rákattint az újraindításra, elindul a GSI. Az eszköz használhatósága a GSI-ben attól függ, hogy az eszköz OEM-je mennyire implementálta a Treble-t (vagy inkább, mennyire sérti meg a Treble-t kompatibilitás.) Egyes eszközök jobban működnek a GSI-kkel, mint mások, de általában ne számítsunk arra, hogy ezt a telepítést mindennapi használatra használják sofőr. Tesztelnie kell az alkalmazást, majd újraindítással ki kell lépnie. Ha a GSI-telepítésben szeretne maradni további tesztelés céljából, akkor használhatja a gsi_tool shell parancs.
A DSU teljes GSI telepítési útmutatója megtalálható itt. A hibákat a Google Issue Tracker,Reddit, vagy Stack Overflow.
A dinamikus rendszerfrissítések oka
Amikor Iliyan Malchevvel beszéltem a Google I/O-n, megismételte, amit Hung-ying Tyan a Treble csapatától a korai GSI-hozzáférésről mondott. Novemberi Android Dev Summit. A Google létrehozta a DSU-t kérjen visszajelzést a lehető legszélesebb közönségtől. A cél a GSI minőségének javítása, ami viszont javítja a jövőbeli Android-kiadás minőségét mivel a GSI az Android legtisztább formája. Jelenleg a Google az egyetlen olyan cég, amely teszteli a következő verziójú GSI-kompatibilitást (például, hogy az Android Q rendszerképe mennyire működik az Android P-n szállítói megvalósítás), de ahogy egyre többen villogtatják a GSI-ket és adnak visszajelzést, az OEM-ek kijavíthatják a Treble kompatibilitási megsértéseket, így a GSI-k még jobban fognak működni jövő. Iliyan szerint az OEM-ek és a gyártók, például a Qualcomm nagy érdeklődést mutat az előző Android-kiadás gyártói képeinek újrafelhasználása iránt a következő verziójú rendszerképpel. Az olyan kezdeményezések, mint a DSU, segítik a Google-t és az OEM-eket, hogy pótolják az olyan automatizált tesztek, mint a VTS és a CTS-on-GSI, lefedettség terén meglévő hiányosságokat. Így a Google több bétatesztelőt kér, hogy visszajelzést adjanak a következő Android-kiadásról, miközben a Treble-kompatibilitási megsértésekről is hallanak, így az OEM-ek javíthatják munkájukat.
Üdvözöljük a dinamikus rendszerfrissítések hozzáadását az Android Q-hoz, de ez nem lesz az a kettős rendszerindítási megoldás, amelyre néhányan számítanak. Mint korábban említettük, csak a Google vagy az OEM-ek által aláírt rendszerképek telepíthetők. Amikor megkérdeztem Iliyant a DSU kiterjesztésének lehetőségéről, hogy támogassa az alternatív Android ökoszisztémáját Azt mondta, hogy ez technikailag lehetséges, mivel a DSU egyszerűen egy csatorna a rendszer szállításához képeket. Bármely OEM használhatja, ahogy akarja mindaddig, amíg a végeredmény Android-kompatibilis. A Google itt nem teremtett alternatívát az OTA rendszerhez, és a DSU-t nem valódi kettős rendszerindításra szánták. Ettől függetlenül a Google által a Treble-n végzett munka modulárisabbá teszi az Androidot, így nem lennék meglepve, ha a natív kettős rendszerindítás valósággá válna.