Az Android 11 DSU Loaderrel érkezik a Fejlesztői beállításokon belül, amely lehetővé teszi a kompatibilis GSI-k automatikus letöltését és telepítését! Olvasson tovább!
A jó alkalmazás-ökoszisztéma az operációs rendszer sikerének egyik legfontosabb pillére. Mind a Google, mind az Apple felismeri annak értékét, hogy jó alkalmazások vannak a platformjukon, ezért mindkét vállalat megpróbálja egyensúlyba hozni felhasználóik és alkalmazásfejlesztőik igényeit. A felhasználók folyamatosan szorgalmazzák az operációs rendszerek megváltoztatását, és bár a legtöbben általában értékelik az új funkciókat, ezeket A változtatások nem mindig szórakoztatóak az alkalmazásfejlesztők számára, mivel sok alapvető funkciót és funkciót megváltoztathatnak viselkedés. Azok a fejlesztők, akik folyamatosan azon dolgoznak, hogy alkalmazásaik relevánsak legyenek, ezeknek a változtatásoknak a kezelése növeli a munkalistájukat. Még ha ezek a változtatások nem is érintik közvetlenül az alkalmazásaikat, a fejlesztőknek továbbra is meg kell győződniük arról, hogy alkalmazásaik működni fognak az új operációs rendszer frissítésén. A Google az évek során számos változtatást hajtott végre, hogy megkönnyítse ezt a folyamatot az Android-alkalmazások fejlesztői számára, és most egy új Az Android 11 DSU Loader nevű funkciója még egyszerűbbé teszi az alkalmazásfejlesztők számára, hogy teszteljék alkalmazásaikat az új Androidon verziók.
A Project Treble-vel kezdődik
Az Android 8.0-ban bevezetett Treble projekt jelentős az Android operációs rendszer újratervezése. A Project Treble célja az volt, hogy az Android operációs rendszert két nagy részre ossza fel: a keretrendszerre és a szállítói megvalósításra. (a „szállító” itt az eszközben található bármely védett hardverkomponens gyártóját jelenti, általában a szilícium). Az Android operációs rendszer keretrendszere maga az operációs rendszer, beleértve az összes rendszeralkalmazást, a felhasználói felületet és annak összetevőit, valamint az Android-eszközökön megosztott API-kat. A szállítói megvalósítás tartalmazza a szállítói HAL-okat (Hardware Abstraction Layers), valamint a Linux kernelt és a Linux kernel modulokat.
Mivel az OEM-ek sokféle hardverelemet tartalmazó okostelefonokat szállítanak sok különböző gyártótól, sok munkát kell végezniük ahhoz, hogy a hardvert egyetlen Android OS-kiadáson felállítsák és futtassák. Ezután minden új Android OS frissítéssel még többet kell dolgozniuk, hogy megbizonyosodjanak arról, hogy hardverük működik az új verzióval. De mivel a Project Treble szabványosítja az ABI-t (Application Binary Interface) az Android operációs rendszer keretrendszere és a HAL-ok között egy adott Android-verzióhoz, Az Android OEM-ek megkezdhetik eszközeik frissítéseinek tesztelését anélkül, hogy meg kellene várniuk, míg a szilíciumgyártók és más alkatrészgyártók frissítik az oldalukat. a kód. Ez a változás érezhetően felgyorsult az Android frissítések kezelésének módja.
Ez a lényege annak, amit a Project Treble tett az Android-frissítések terén, de ami még fontosabb az alkalmazások esetében A fejlesztők szerint a Treble lehetővé tette az általános rendszerképek (GSI) használatát a kompatibilitás érdekében tesztelés.
A GSI-k megjelenése
Annak érdekében, hogy az OEM-ek teszteljék, megfelelően implementálták-e a Project Treble-t, a Google előírja, hogy az OEM-nek képesnek kell lennie az Android tiszta buildjének elindítására az AOSP-ről az eszközön. Az Androidnak ezt a letisztult felépítését Generic System Image-nek vagy GSI-nek hívják. Ha a GSI indul és a legtöbb alapvető hardver megfelelően működik, akkor az OEM tudja, hogy eszköze megfelel a Project Treble követelményeinek. A GSI-k eredeti célja tehát a Treble kompatibilitás tesztelése volt, de amint azt az XDA-Developers fejlesztői közösségével láttuk, más célokra is felhasználhatók. Láttuk, hogyan működik a GSI lényegében lehetővé tenné, hogy a nehéz Android felhasználói felülettel rendelkező eszközök az Android legújabb verzióját élvezhessék működő funkciókkal az új kiadás után néhány napon belül. A Google azonban egy másik célt is elképzel a GSI mögött: lehetőséget ad az alkalmazásfejlesztőknek, hogy teszteljék alkalmazásaikat egy új Android-verzión a már birtokukban lévő fizikai eszközön.
Az Android 10 rendszerrel a Google kiadta saját GSI buildjét a fejlesztők számára. A Google megerősítette azt az elképzelést, hogy az alkalmazásfejlesztőknek GSI-t kell használniuk az Android tiszta buildjének elindításához saját hardverükön, így könnyebben tesztelhetik alkalmazásaik viselkedését a gyári Androiddal. Ez a módszer így kiegészítette az alkalmazáskompatibilitás tesztelésének meglévő lehetőségeit az Androidon az OEM viselkedésének megváltoztatása nélkül, a többi pedig Pixel okostelefon használatával, az Android Studio hivatalos Android emulátorának használatával, vagy alkalmazás-összeállítások telepítésével egy eszközpéldányra a felhőben.
A GSI-k által nyújtott minden kényelem ellenére telepítésük még mindig nehézkes folyamat volt. Előfordulhat, hogy az alkalmazásfejlesztők nem érzik jól magukat, ha manuálisan villogtatják a rendszerképet Android-eszközön, mivel ezt általában csak a hobbibarátok vagy az Android operációs rendszer fejlesztői ismerik. A GSI telepítéséhez egy rendszerkép villogtatására volt szükség a gyorsindítás során, amihez az Android Verified Boot letiltása és a rendszerbetöltő feloldása szükséges. A rendszerbetöltő feloldásához viszont teljes felhasználói adatok törlése szükséges. És amint azt mindannyian tudjuk, nincs pontosan egyetlen folyamat vagy útmutató minden Android-eszköz rendszerbetöltőjének feloldásához, így nem lehet egységességet találni. Például a Samsung készülékek nem rendelkeznek gyorsindítással, míg a Xiaomi készülékek néhány ugrást tesznek lehetővé a rendszerbetöltő feloldásához. Ez egy kényelmes rendetlenség, amelyben megvan az a lehetőség, hogy valami egyszerűbb dologba bonyolódjon.
Itt jönnek be a dinamikus rendszerfrissítések.
Dinamikus rendszerfrissítések egyszerűen a GSI-k telepítésével
A Google rájött, hogy a GSI-k telepítésének jelenlegi módja nem tökéletes megoldás, ezért elkezdtek dolgozni egy jobb megoldáson. Android 10 esetén A Google megkezdte a dinamikus rendszerfrissítések tesztelését, vagy DSU. A DSU egy új módszer a GSI ideiglenes telepítésére anélkül, hogy gyorsindítási parancsokat kellene használnia a rendszerkép felvillantásához, felülírva az eredeti telepítést. A DSU segítségével elindíthatja a GSI-t, tesztelheti az alkalmazást, majd kényelmesen újraindíthatja az eredeti telepítést, amely érintetlen maradt.
A DSU az eredeti telepítés érintése nélkül tud GSI-t telepíteni, mert új rendszer- és adatpartíció-képeket hoz létre, amelyeket ideiglenesen a /data/gsi. Ezek a lemezképek az eredeti rendszer- és adatpartíciók helyett rendszerindításkor kerülnek felcsatolásra. Mivel a telefonnak további tárhelyre van szüksége ezekhez az új, ideiglenes képekhez, a telefonnak rendelkeznie kell "logikai partíciókkal", amelyek dinamikusan átméretezhető partíciók. A logikai partíciók egy új felhasználói terület particionáló rendszer Androidhoz, amely kötelező az Android 10 rendszerrel induló eszközökön. Ha eszköze Android 10 rendszerrel indult, akkor támogatnia kell a GSI-k DSU-n keresztüli telepítését.
Az Android 10 rendszerben mindössze annyit kell tennie, hogy telepítsen egy GSI-t DSU-n keresztül egy rendszertulajdonság módosítása, majd elindítása DynamicSystemUpdatesInstallationService egy intent küldésével a GSI elérési útját intent extraként.
Bár ez a folyamat ismeretlennek tűnhet, sokkal könnyebb és kevésbé tolakodó a használathoz képest gyorsindítási parancsokat, és mindent meg kell oldani, beleértve az eredeti telepítést is letörölték. A DSU használatához bizonyos ADB-ismeretekre és szándékokra van szüksége, de ez nem jelenthet problémát a legtöbb alkalmazásfejlesztő számára. Ennek ellenére nincs ok arra, hogy a folyamatot ne lehetne még egyszerűbbé tenni. Ráadásul a GSI DSU-n keresztüli telepítéséhez továbbra is fel kell oldania a rendszerbetöltőt, és a folyamat során minden felhasználói adatot törölnie kell. Ennek érdekében a Google változtatásokat hajtott végre a GSI-telepítés mindkét aspektusának javítása érdekében. Az Android 11-ben megszűnt a parancssor használata a GSI telepítéséhez. Külön-külön is lehetővé tették a GSI telepítését a rendszerbetöltő feloldása nélkül.
DSU Loader Android 11-ben
A DSU Loader egy új eszköz, amely az Android 11 fejlesztői beállításaiban található, és lehetővé teszi Letöltés és telepítés a Google legújabb GSI-je anélkül, hogy bármilyen gyorsindítási vagy ADB-parancsot kellene megadnia. Egyszerűen érintse meg a DSU Loader opciót a Beállításokban, és megjelenik egy párbeszédpanel a támogatott GSI-k listájával közvetlenül a Google-tól. Ezek a támogatott GSI-k a jelenlegi operációs rendszeren és architektúrán alapulnak, így csak olyan GSI-ket telepíthet, amelyek újabbak, mint az operációs rendszer verziója, és amelyek megfelelnek az Ön SoC-architektúrájának. Egyszerűen válassza ki a telepíteni kívánt GSI-t, és a rendszer letölti a Google szervereiről, és automatikusan telepíti a háttérben.
A DSU Loader segítségével a fejlesztőknek soha nem kell megérinteni a parancssort a GSI telepítéséhez. Legalábbis ez az álom, mert még mindig van egy megoldandó probléma.
Az út előre
Jelenleg a GSI DSU Loader segítségével történő telepítéséhez zárolatlan rendszerbetöltőre van szükség. Bár ez meghiúsíthatja az egész megpróbáltatás célját, ennek nem így kell lennie, és azt mondják, hogy megoldódik. A Google azt tervezte, hogy a felhasználók a Google által aláírt GSI-ket a DSU-n keresztül indíthatják el anélkül, hogy fel kellene oldaniuk a rendszerbetöltőt. Valójában a Google ezt írja elő minden Android 10 indítóeszközön megtalálható az Android Verified Boot nyilvános kulcsa a Google által aláírt Android 10, Android 11 és Android 12 GSI-k közül. Az AVB nyilvános kulcsainak az eszköz ramdiskjén való elhelyezése biztosítja, hogy az AVB ne utasítsa el az indítani kívánt GSI-t. Ez az oka annak, hogy a jelenlegi módszer magában foglalja a rendszerbetöltő feloldását - egy üres vbmeta kép felvillantásával a vbmeta partícióra letiltja az AVB-t, hogy az ne utasítsa el a felvillantandó GSI-t. Az AVB letiltása azonban komoly biztonsági kockázatot jelent, mivel azt jelenti, hogy minden módosítást rendszer/boot/termék/szállító partíció betölthető az eszközre, ezért a Google ezt szeretné el kell távolítani ezt a követelményt.
Mikor várható tehát, hogy a GSI-t DSU-n keresztül indítsa el anélkül, hogy fel kellene oldania a rendszerbetöltőt vagy bármilyen parancssori eszközt kellene használnia? Remélhetőleg hamarosan, mivel a Google megemlítette nekünk, hogy az Android 11 kezdeti fejlesztői előnézetével néhány hibájukat meg kellett oldaniuk, mielőtt mindezt megfelelően működni tudják. A jövőben várhatóan a Developer Preview GSI-k DSU-n keresztül telepíthetők anélkül, hogy fel kellene oldani a rendszerbetöltőt. Talán amikor elérhetővé válik az Android 12 fejlesztői előnézete, akkor akár teljes egészében elindíthatja azt az Android 11 fejlesztői beállításaiban található DSU Loader használatával. Az alkalmazásfejlesztők számára ez azt jelenti, hogy lesz még egy módja annak, hogy tesztelje alkalmazásait egy új Android-verziót futtató fizikai hardveren.