Minden, amit az Android Project Mainline-ról tudnia kell

Az elmúlt évek egyik legnagyobb változása az Androidban, amely a radar alatt repült, viszonylagosan a fontossága ellenében, a Projekt fővonal Android 10-ben. A Google előírja bizonyos Mainline modulok beépítését az Android-kiadásokba Android 11 bejön a összesen 25 fővonali modul együttesen kötelező. Itt található egy magyarázat arról, hogy mi az a Project Mainline, és mi a célja, hogy megoldja, valamint az összes Android Project Mainline modul listája.

Mi az a Project Mainline?

A Project Mainline megfelelő megértéséhez egy kicsit vissza kell tekernünk. Ha visszamegyünk néhány évet, akkor az Android-frissítésekkel kapcsolatos beszélgetések nagy része a töredezettség problémája körül összpontosul. A töredezettség volt az egyik legnagyobb kihívás a Google számára, amelyet Androidon kellett megoldania az Ice Cream Sandwich – Lollipop korszak körül. Annak ellenére, hogy az Android, mint platform rendszeres frissítéseket kapott egy nagyrészt előre látható minta szerint, ezek a frissítések nagyon sokáig tartottak, míg eljutottak a végső fogyasztókhoz, ha egyáltalán eljutottak. Tehát miközben a Google a kritikus hibákat és a biztonsági problémákat platformszinten javította, a változtatások tényleges bevezetése sok kívánnivalót hagyott maga után. Sok közvetítő (SoC szállító, OEM-ek, szolgáltatók stb.) és sok mozgó alkatrész vett részt/van a frissítések szállításában telefonját, és a töredezettségi probléma nem úgy tűnt, mintha magától megoldódna anélkül, hogy valami kemény ütést igényelne beavatkozások.

A probléma megoldására tett egyik fő erőfeszítés a következő formában történt Projekt Treble az Android 8.0 Oreo mellett, amely az Android jelentős átépítésével járt, elválasztva az Android OS keretrendszer összetevőit a gyártói HAL-októl és a Linux kerneltől. A Project Treble lényegében úgy modularizálta az Androidot, hogy elválasztotta az operációs rendszer keretrendszerét az eszközspecifikus, alacsonyabb szintű szoftverektől. Így az eszközgyártóknak (OEM-eknek) nem kell megvárniuk, amíg a szilíciumgyártók (SoC-szállító) frissítik szállítói megvalósítási kódjukat, az OEM-ek pedig függetlenül frissíthetik az Android operációs rendszer keretrendszerét. A végeredmény az újabb Android-kiadások gyorsabb átvétele az OEM-től, mivel már nincs rá szükségük Várja meg, amíg a közvetítő (SoC szállító) befejezi a munkáját, mielőtt elkezdhetné övék.

Bár az Android frissítési helyzete nem javult drámaian azonnal a Project Treble révén, nagyrészt lehetővé tette a szélesebb körű OEM-eket. részvétel az Android 10 és Android 11 béta verzióiban, valamint megkönnyíti az OEM-ek számára, hogy több eszközüket gyorsabban frissítsék Idővonal. Ráadásul a GSI (Generic System Image) teljes koncepciója nagy hatással volt az utángyártott fejlesztésekre fórumainkon.

A fejlesztő 22 régebbi, Project Treble GSI-vel rendelkező eszközön indítja el az Android 11-et

A Project Mainline kiterjeszti a Project Treble erőfeszítéseit. Míg a Treble csökkentette az OEM-ek függőségét az SoC-szállítóktól minden egyes operációs rendszer-frissítésnél, a Mainline csökkentette, hogy a Google mennyire függ az OEM-től a kulcsfontosságú operációs rendszer-összetevők biztonsági frissítéseinek szállításában. A Project Mainline kiterjeszti a Treble filozófiáját az Android keretrendszer kritikusabb részeire, eltávolítva az OEM-eket, mint a függő közvetítőket ebből az egyenletből. A Project Mainline célja, hogy a Google átvegye a keretrendszer-összetevők és rendszeralkalmazások irányítását kritikus a biztonság és a fejlesztési konzisztencia fenntartása az OEM-ektől távol. A Project Mainline joggal nevezik a legnagyobb változás az Androidon a Project Treble óta.

A Project Mainline esetében a Google Mainline modulokat használ, amelyeket a Google Play Services keretrendszeren és a Google Play Áruházban szállítanak. Minden Mainline modul APK-fájlként, APEX-fájlként vagy APK-in-APEX-ként kerül szállításra. Amikor egy Mainline modult frissítenek, a felhasználó "Google Play rendszerfrissítés" (GPSU) értesítést lát az eszközén. A kritikus összetevők frissítése érdekében a Google megkerülte annak szükségességét, hogy megvárja, amíg egy OEM kiad egy frissítést, és úgy döntött, hogy maga végzi el a feladatot.

Mint A Google kijelenti az Android webhelyén:

A moduláris rendszerelemek lehetővé teszik a Google és Android partnerek számára, hogy széles körben, gyorsan és zökkenőmentesen, nem tolakodó módon terjesszék a frissítéseket a végfelhasználói eszközökre. Például a médiakodek töredezettsége és a kritikus hibák kombinációja drámaian lelassíthatja az alkalmazások elfogadását és a felhasználók elköteleződését. A médiával kapcsolatos modulok gyakori frissítései csökkenthetik a kodek töredezettségét, így a médiaalkalmazások viselkedése egységesebb lesz a különböző Android-eszközökön, és kijavíthatja a kritikus hibákat a felhasználói bizalom növelése érdekében.

Az Android 10 vagy újabb verziója a kiválasztott rendszerösszetevőket modulokká alakítja, amelyek egy része az APEX konténerformátumot használja (az Android 10-ben bevezetve), néhány pedig az APK formátumot használja. A moduláris architektúra lehetővé teszi a rendszerelemek frissítését kritikus hibajavításokkal és másokkal szükség szerinti fejlesztések, anélkül, hogy az alacsonyabb szintű szállítói megvalósításokat vagy magasabb szintű alkalmazásokat érintenének szolgáltatások.

Mint Ars Technica említi:

A Project Mainline, más néven „Google Play rendszerfrissítések”, az Android 10-ben került bevezetésre, annak érdekében, hogy az Android alapvető rendszerelemeit modulárisabbá és frissíthetőbbé tegye. A Mainline egy új „APEX” fájltípust vezetett be, kifejezetten a rendszerösszetevők számára, azzal a céllal, hogy az alapvető Android kódot a Play Áruházon keresztül ugyanolyan egyszerűen szállítsák, mint egy alkalmazásfrissítést. Korábban az Android egyetlen szállítható kódblokkja az APK volt, egy eredetileg harmadik féltől származó alkalmazásokhoz tervezett fájltípus. Ez mindenféle biztonsági megszorítással járt, és csak a rendszerindítási folyamat késői szakaszában indulhatott el, ezért az APEX-et a nagyobb teljesítményű rendszerelemek figyelembevételével hozták létre. Az APEX-eket csak a Google vagy az eszköz gyártója hozhatja létre, így észrevehetően erősebbek lehetnek, és olyan kritikus rendszerindítási összetevőket tartalmaznak, mint például az alkalmazás futtatókörnyezete.

A Mainline nem csak egy technikai megoldás, hanem arról is szól, hogy az Android több részét központilag terjesztjük A Google, amely magában foglalja az eszközgyártókkal való tárgyalásokat, és arra készteti őket, hogy mindannyian beleegyezzenek ugyanazon blokk szállításába kód. A Mainline modulok szállítása végül kötelezővé válik, így a Mainline valójában egy nagy együttműködés az eszközgyártókkal annak érdekében, hogy egyetlen ökoszisztéma-szintű modul megfeleljen mindenki igényeinek. Nem minden Mainline modul rendkívül erős APEX modul – némelyik csak APK, amely immár a Google által terjesztett Android-kód.

Projekt fővonal – modulok

Az Android 10 esetében a Google 13 speciális Mainline modul felvételét írta elő. Android 11 esetén a kötelező modulok száma összesen 25. Íme a teljes lista néhány fontos részlettel együtt:

A fenti oszlopok kontextusának megadása érdekében az „Eszköz frissítve Android 11-re vagy elindítva Android 11-re” című oszlop részleteket tartalmaz arról, hogy a modulnak jelen kell lennie (vagy nem jelen van, az időzóna adatok esetében az alternatíva beépítése miatt) minden olyan eszközön, amelyen vagy frissítették az Android 11-et, vagy amelyek Android 11-el indulnak. doboz. Hasonlóképpen, az Android 10 rendszerrel induló eszközöknek tartalmazniuk kell néhány modult, erősen ajánlott néhány további modult, és a többi nem támogatja őket. Az Android 10-re frissített eszközök esetében (szemben az Androiddal elindítottakkal) a szükséges modulok listája rövidebb.

Mit csinálnak az egyes Mainline modulok?

Íme egy rövid magyarázat az egyes Mainline modulokhoz:

Adbd

Az adbd modul kezeli a parancssori adb és IDE hibakeresési munkameneteket. Az adbd modularizálása lehetővé teszi a Google számára, hogy gyorsabban javítsa a teljesítményt és javítsa a hibajavításokat. Ez kulcsfontosságú, mivel néhány hiba a múltban az akkumulátor lemerüléséhez kapcsolódott, és az eszközök továbbra is 100%-os CPU-t használnak, amíg a telefon meg nem hal. Ezért ezeknek a javításoknak a kidolgozása kulcsfontosságú a Google számára, mivel az adb-t széles körben használják az alkalmazásfejlesztők és az OEM-ek tesztelésére.

Android Neural Networks API Runtime

Ez egy olyan könyvtár, amely egy alkalmazás és a háttér-illesztőprogramok között helyezkedik el. Az API pedig egy Android C API, amely számításigényes gépi tanulási műveletek futtatására szolgál mobileszközökön, és lehetővé teszi a hardveresen gyorsított következtetési műveleteket.

CellBroadcast

A Cell Broadcast a vészhelyzeti és nem vészhelyzeti riasztásokra utal (mint például a BOROSTYÁNOS riasztások). Ez a modul az e riasztások körüli feladatokkal és egyéb kiegészítő funkciókkal foglalkozik, mint például az SMS-dekódolás és a vezeték nélküli vészriasztások geofencezése.

Conscrypt

A Conscrypt modul kezeli az Android TLS megvalósítását és más kriptográfiai funkciókat, például kulcsgenerátorokat, titkosításokat és üzenetkivonatokat. Ennek a modulnak a szállítása lehetővé teszi a Google számára, hogy felgyorsítsa a biztonsági fejlesztéseket anélkül, hogy OTA-frissítésekre kellene hagyatkoznia.

DNS-feloldó

Ahogy a név is sugallja, a DNS-feloldó feloldja a DNS-t, azaz az ember által olvasható URL-eket IP-címekké alakítja. A modul tartalmazza a DNS csonkfeloldót megvalósító kódot, és ennek modulként való szállítása lehetővé teszi a Google számára, hogy jobb felhasználói védelmet biztosítson a DNS-elfogással és a konfigurációfrissítési támadásokkal szemben.

Dokumentumok UI

A Dokumentumok felhasználói felülete az a modul, amely a dokumentumengedélyeket kezelő összetevők bizonyos fájljaihoz való hozzáférés vezérléséért felelős. Ahogy a Google kijelenti, a tárhely-hozzáférés és az engedélyek modulokba foglalása növeli a végfelhasználók adatvédelmét és biztonságát. a futásidejű erőforrás-átfedés (RRO) funkció lehetővé teszi az OEM-ek számára, hogy tematikázzák az élményt (a Fájlok alkalmazásra hivatkozva), ha szükségük van rá. nak nek. Modulként az összes Google-Android-eszközt ugyanazzal a Dokumentumok felhasználói felülettel szállítjuk.

ExtServices

Ez a modul keretösszetevőket tartalmaz az operációs rendszer alapvető funkcióihoz, mint például az értesítések rangsorolása, az automatikus kitöltési szövegegyeztetési stratégiák, a tárolási gyorsítótár, a csomagfigyelő és egyéb szolgáltatások.

IPsec/IKEv2 könyvtár

Ez a könyvtármodul az Interworking Wireless LAN körüli új és meglévő szolgáltatásokkal foglalkozik (IWLAN) és VPN-ek, például olyan biztonsági paraméterek egyeztetése, mint a kulcsok, algoritmusok és alagút konfigurációk. E funkciók modularizálásának az az ötlete, hogy elősegítse az ökoszisztéma konzisztenciáját, és lehetőséget biztosítson a biztonsági és interoperabilitási problémák gyors megoldására.

Ez három kétágú modul, de funkcióik egymásra vannak utalva. Ezek a médiamodulok kezelik a médiatípusokat és -kódokat, interakcióba lépnek az ExoPlayerrel, továbbítási vezérlőket és lejátszási információkat tesznek közzé a keretrendszer számára, optimalizálják az indexelt metaadatokat stb. Emlékezik Stagefright, a kihasználás, amely megváltoztatta az Androidot és magával hozta a platform havi biztonsági frissítéseinek koncepcióját? Ez a kizsákmányolás a médialejátszó könyvtár sérülékenységein alapult. A médiakomponensek modularizálása tehát lehetővé teszi a Google számára, hogy gyorsan és széles körben reagáljon, ha biztonsági hibákat találnak ebben a gyakran megcélzott összetevőben.

Ennek a modulnak a funkciója azonnal kiderül a nevéből, bár a célja nem az. A Modul metaadatai modul... metaadatokat tartalmaz az eszközön lévő modulok listájáról. És nagyjából ennyi.

Hálózati verem-összetevők, hálózati verem engedély konfigurálása, bejelentkezés a portálra

A Network Stack Components modul közös IP-szolgáltatásokat, hálózati kapcsolat figyelést és rögzített bejelentkezési portál észlelést biztosít. Az engedélykonfigurációs modul határozza meg azt az engedélyt, amely lehetővé teszi más modulok számára a hálózattal kapcsolatos feladatok végrehajtását. A Captive Portal Login modul a Captive Portalokkal foglalkozik – azokkal a weboldalakkal, amelyek akkor jelennek meg, amikor csatlakozik bizonyos nyilvános Wi-Fi hálózatokhoz, ahol a felhasználónak meg kell adnia az adatokat az internet eléréséhez hozzáférés.

Engedélyvezérlő

Ez a modul frissíthető adatvédelmi szabályzatokat és UI-elemeket biztosít az engedélyek megadásával és kezelésével kapcsolatban. Ha ez ismerősnek hangzik a Package Installer programhoz, az azért van, mert így van. Az olyan funkciók, mint a futásidejű engedélyek megadása, kezelése és a használat nyomon követése a Package Installer alkalmazás részét képezték egészen az Android 9-ig. Az Android 10 rendszerben a Package Installer alkalmazás szakaszokra van felosztva, hogy lehetővé tegye az engedélyek logikájának frissítését. A Permission Controller modult APK-fájlként szállítjuk, és az Android 11-ben a modul automatikusan visszavonhatja a hosszabb ideig nem használt alkalmazások futásidejű engedélyeit.

SDK-bővítmények

Ezt a modult kissé nehéz megérteni és következésképpen elmagyarázni. Minden Android-kiadáshoz hozzá van rendelve egy SDK-szint (általában +1 az elődjéhez képest). Ha egy alkalmazás egy adott SDK-t céloz meg, akkor feltételezhető, hogy a fejlesztő figyelembe vette az Android-kiadás által hozott platform viselkedési és API-módosításait.

Az SDK Extensions modul meghatározza az eszköz „kiterjesztés SDK” szintjét, és megjeleníti az API-kat az alkalmazások számára, hogy lekérdezzék a bővítmény SDK szintjét. Körülbelül ennyit ír a hivatalos dokumentáció. ArsTechnica, bár megemlíti hogy ez valószínűleg egy másodlagos API-réteg, amelyet a Play Áruházban szállítanak majd.

Statsd, telemetriai vonatverziós csomag

A Statsd felelős az eszközmutatók összegyűjtéséért. A Telemetry Train Version Package viszont nem tartalmaz aktív kódot vagy saját funkcionalitást. Egyszerűen tartalmazza a "telemetriai vonat" verziószámát, amely a Google szerint a mérőszámokhoz kapcsolódó modulok készlete. A verziószám alapján a Google Play megjeleníti a biztonsági javítás verzióját a végfelhasználók számára, és kitalálja, hogy elérhető-e frissítés a mérőszámmal kapcsolatos modulokhoz.

Internetmegosztás

Az internetmegosztási modul Wi-Fi, USB, Bluetooth vagy Ethernet kapcsolaton keresztül megosztja az eszköz internetkapcsolatát más csatlakoztatott klienseszközökkel. A modul tartalmazza a tethering összetevőket és azok függőségeit. Az internetmegosztási modul használatával az OEM-ek egyetlen, szabványos referencia-megvalósításra támaszkodhatnak, és egységes élményt biztosíthatnak az eszközökön.

Időzóna adatok

Az időzóna adatmodul frissíti a nyári időszámítást (DST) és az időzónákat az Android-eszközökön, szabványosítva mind az adatokat (amelyek meglehetősen gyakran változik vallási, politikai és geopolitikai okok miatt), valamint az ökoszisztéma frissítési mechanizmusa miatt. Az Android 8.1 és Android 9 APK-alapú időzóna-adatfrissítési mechanizmust használt, az Android 10 pedig APEX-alapú modulfrissítési mechanizmussal váltja fel. A Google kijelenti, hogy az AOSP továbbra is tartalmazza az APK-alapú frissítésekhez szükséges platformkódot, így Az Android 10-re frissítő eszközök továbbra is megkaphatják a partner által biztosított időzóna-adatok frissítéseit a következőn keresztül APK. A Google azonban figyelmeztet, hogy az APK-alapú frissítések felülírják az APEX-alapú frissítéseket.

Wi-Fi

Ez a Wi-Fi funkció modulja. A végfelhasználók mostantól egységes Wi-Fi-élményt kaphatnak az Android-eszközökön, valamint javíthatják az interoperabilitási problémákat a modulfrissítések és az alkalmazások révén. A fejlesztők csökkenthetik a platform töredezettségét, az OEM-ek pedig teljesíthetik a szolgáltatói követelményeket, miközben csökkentik az egyének költségeit testreszabások.

---

Remélhetőleg ez a cikk rávilágít arra, hogy a Project Mainline mennyire fontos a Google Android-ökoszisztémája számára.