Kaikki mitä sinun tulee tietää Androidin Project Mainlinesta

Yksi viime vuosien suurimmista Androidin muutoksista, joka lensi tutkan alle, suhteellisesti sen tärkeyttä vastaan, oli Projektin päälinja Android 10:ssä. Google velvoittaa sisällyttämään tiettyjä Mainline-moduuleja Android-julkaisuihin Android 11 tulossa sisään a yhteensä 25 pakollista päämoduulia. Tässä on selitys siitä, mitä Project Mainline on ja mitä sillä pyritään ratkaisemaan, sekä luettelo kaikista Androidin Project Mainline -moduuleista.

Mikä on Project Mainline?

Ymmärtääksemme Project Mainlinea oikein meidän on kelattava hieman taaksepäin. Jos palaat muutaman vuoden taaksepäin, suuri osa Android-päivityksiä koskevasta keskustelusta keskittyi pirstoutumisongelmaan. Fragmentointi oli yksi suurimmista haasteista, jotka Google ratkaisi Androidilla Ice Cream Sandwich - Lollipop -aikakauden aikana. Vaikka Android alustana sai säännöllisesti päivityksiä pitkälti ennakoitavissa olevan kaavan mukaan, näiden päivitysten saapuminen loppukuluttajien käsiin kesti aiemmin, jos ollenkaan. Joten vaikka Google korjasi kriittisiä virheitä ja tietoturvaongelmia alustatasolla, näiden muutosten todellinen käyttöönotto jätti paljon toivomisen varaa. Päivitysten toimittamisessa oli/on paljon välittäjiä (SoC-toimittaja, OEM-valmistajat, operaattorit jne.) ja paljon liikkuvia osia puhelimeesi, ja pirstoutumisongelma ei näyttänyt siltä, ​​että se ratkeaisi itsestään ilman kovia iskuja interventioita.

Yksi suurimmista ponnisteluista tämän ongelman ratkaisemiseksi tuli muodossa Projekti Treble rinnalla Android 8.0 Oreo, joka sisälsi Androidin suuren uudelleenarkkitehtuurin, jolloin Android-käyttöjärjestelmän kehyskomponentit erotettiin toimittajan HAL: ista ja Linux-ytimestä. Project Treble pohjimmiltaan modularisoi Androidin erottamalla käyttöjärjestelmän puitteet laitekohtaisista alemman tason ohjelmistoista. Tällä tavalla laitevalmistajien (OEM) ei tarvitse odottaa piin valmistajien (SoC-toimittaja) päivittävän toimittajan toteutuskoodinsa, ja OEM-valmistajat voivat päivittää Android-käyttöjärjestelmän puitteet itsenäisesti. Lopputuloksena on nopeampi uudempien Android-julkaisujen käyttöönotto OEM: ltä, koska heidän ei enää tarvitse odota, että välittäjä (SoC-toimittaja) saa työnsä valmiiksi, ennen kuin he voivat aloittaa sen heidän.

Vaikka Android-päivitystilanne ei kohentunut dramaattisesti heti Project Treblen myötä, se mahdollisti suurelta osin laajemman OEM-valmistajan. osallistuminen Android 10:n ja Android 11:n betaversioihin sekä OEM-valmistajien on helpompi päivittää useampia laitteitaan nopeammin aikajanalla. Lisäksi koko GSI: n (Generic System Image) konseptilla on ollut suuri vaikutus jälkimarkkinoiden kehitykseen foorumeillamme.

Kehittäjä käynnistää Android 11:n 22 vanhemmalla Project Treble GSI -laitteella

Project Mainline laajentaa Project Treblen ponnisteluja. Vaikka Treble vähensi OEM-valmistajien riippuvuutta SoC-toimittajista jokaisen käyttöjärjestelmäpäivityksen osalta, Mainline vähentää Googlen riippuvuutta OEM-valmistajista toimittaessaan tietoturvapäivityksiä käyttöjärjestelmän tärkeimpiin komponentteihin. Project Mainline laajentaa Treble-filosofian Android-kehyksen kriittisempiin osiin poistaen OEM-valmistajat riippuvaisina välittäjinä tästä yhtälöstä. Project Mainlinen tarkoituksena on, että Google voi hallita kehyskomponentteja ja järjestelmäsovelluksia turvallisuuden kannalta kriittinen ja kehityksen johdonmukaisuuden säilyttäminen kaukana OEM-valmistajista. Projektin päälinjaa kutsutaan oikeutetusti nimellä the suurin muutos Androidiin sitten Project Treblen.

Google käyttää Project Mainlinessa Mainline-moduuleja, jotka toimitetaan Google Play Services -kehyksen ja Google Play Kaupan kautta. Jokainen Mainline-moduuli toimitetaan joko APK-tiedostona, APEX-tiedostona tai APK-in-APEX-tiedostona. Kun Mainline-moduulia päivitetään, käyttäjä näkee laitteellaan "Google Play System Update" (GPSU) -ilmoituksen. Toimittaakseen päivityksiä kriittisiin komponentteihin Google on käytännössä ohittanut tarpeen odottaa OEM: n julkaisevan päivityksen ja päättänyt suorittaa tehtävän itse.

Kuten Google toteaa Android-sivustolla:

Modulaaristen järjestelmäkomponenttien avulla Google ja Android-kumppanit voivat jakaa päivityksiä laajasti, nopeasti ja saumattomasti loppukäyttäjien laitteisiin häiritsemättömällä tavalla. Esimerkiksi mediakoodekkien pirstoutumisen ja kriittisten virheiden yhdistelmä voi dramaattisesti hidastaa sovellusten käyttöönottoa ja käyttäjien sitoutumista. Mediaan liittyvien moduulien säännölliset päivitykset voivat vähentää koodekkien pirstoutumista ja tehdä mediasovellusten käyttäytymisestä johdonmukaisempaa eri Android-laitteissa ja korjata kriittisiä virheitä käyttäjien luottamuksen lisäämiseksi.

Android 10 tai uudempi muuntaa valitut järjestelmäkomponentit moduuleiksi, joista osa käyttää APEX-säilömuotoa (joka on otettu käyttöön Android 10:ssä) ja osa APK-muotoa. Modulaarinen arkkitehtuuri mahdollistaa järjestelmän komponenttien päivittämisen kriittisillä virheenkorjauksilla ja muilla parannuksia tarpeen mukaan vaikuttamatta alemman tason toimittajatoteutuksiin tai korkeamman tason sovelluksiin ja palvelut.

Kuten Ars Technica mainitsee:

Project Mainline, alias "Google Play System Updates", otettiin käyttöön Android 10:ssä suurena pyrkimyksenä tehdä Androidin ydinjärjestelmäkomponenteista modulaarisempia ja päivitettävimpiä. Mainline esitteli uuden "APEX"-tiedostotyypin erityisesti järjestelmäkomponentteja varten. Tavoitteena on toimittaa ydin Android-koodi Play Kaupan kautta yhtä helposti kuin lähetät sovelluspäivityksen. Aiemmin Androidin ainoa toimitettava koodilohko oli APK, alun perin kolmannen osapuolen sovelluksille suunniteltu tiedostotyyppi. Tämä sisälsi kaikenlaisia ​​​​suojausrajoituksia, ja se voi käynnistyä vasta käynnistysprosessin myöhään, joten APEX luotiin tehokkaampia järjestelmäkomponentteja ajatellen. APEXeitä voi luoda vain Google tai laitteesi valmistaja, joten ne voivat olla huomattavasti tehokkaampia ja sisältävät tärkeitä käynnistyskomponentteja, kuten sovelluksen suoritusaikaa.

Mainline ei ole vain tekninen ratkaisu, vaan se koskee myös useiden Androidin osien saamista keskitetysti jakeluun Google, johon kuuluu neuvotteleminen laitevalmistajien kanssa ja niiden saaminen suostumaan toimittamaan saman kappaleen koodi. Mainline-moduulit tulevat lopulta pakollisiksi toimitettaviksi, joten Mainline on itse asiassa suuri yhteistyö laitevalmistajien kanssa varmistaakseen, että yksi ekosysteeminlaajuinen moduuli täyttää kaikkien tarpeet. Kaikki Mainline-moduulit eivät ole erittäin tehokkaita APEX-moduuleja – jotkut ovat vain APK: ita, jotka ovat nyt Googlen jakamaa Android-koodia.

Projektin päälinja — moduulit

Android 10:ssä Google velvoitti sisällyttämään 13 erityistä Mainline-moduulia. Android 11:ssä pakollisten moduulien kokonaismäärä on 25. Tässä on täydellinen luettelo tärkeimpien yksityiskohtien ohella:

Jotta yllä oleviin sarakkeisiin saadaan hieman kontekstia, sarake "Laite päivitetty Android 11:een tai käynnistetty Android 11:n kanssa" sisältää tietoja siitä, onko moduulin oltava mukana (tai ei saa olla läsnä aikavyöhyketietojen tapauksessa sen vaihtoehdon sisällyttämisen vuoksi) kaikissa laitteissa, jotka on joko päivitetty Android 11:een tai jotka käynnistetään Android 11:llä. laatikko. Vastaavasti Android 10:llä käynnistettävien laitteiden on sisällettävä muutama moduuli, niitä suositellaan ehdottomasti lisäämään muutama muu, ja muut eivät tue niitä. Laitteissa, jotka on päivitetty Android 10:een (toisin kuin Androidin kanssa käynnistetyissä), tarvittavien moduulien luettelo on lyhyempi.

Mitä kukin Mainline-moduuli tekee?

Tässä on lyhyt selitys jokaiselle Mainline-moduulille:

Adbd

Adbd-moduuli hallitsee komentorivin adb- ja IDE-virheenkorjausistuntoja. Adbd: n modulointi mahdollistaa Googlen suorituskyvyn parannuksia ja virheenkorjauksia nopeammin. Tämä on ratkaisevan tärkeää, koska jotkin virheet aiemmin liittyivät akun tyhjenemiseen, ja ne saattoivat saada laitteet jatkamaan 100-prosenttisen suorittimen käyttöä, kunnes puhelin kuolee. Näiden korjausten saaminen on siis erittäin tärkeää Googlelle, sillä sovellusten kehittäjät ja OEM-valmistajat käyttävät laajasti adb: tä testaukseen.

Android Neural Networks API Runtime

Tämä on kirjasto, joka sijaitsee sovelluksen ja tausta-ohjainten välissä. API puolestaan ​​on Android C API laskennallisesti intensiivisten koneoppimistoimintojen suorittamiseen mobiililaitteissa ja mahdollistaa laitteistokiihdytetyt päättelytoiminnot.

Kännykkälähetys

Solulähetys tarkoittaa hätä- ja ei-hätähälytyksiä (kuten AMBER-hälytyksiä). Tämä moduuli käsittelee näitä hälytyksiä koskevia tehtäviä ja muita aputoimintoja, kuten SMS-dekoodausta ja langattomien hätähälytysten geoaitausta.

Conscrypt

Conscrypt-moduuli käsittelee Androidin TLS-toteutusta ja muita salaustoimintoja, kuten avaimen luojia, salauksia ja viestitiivisteitä. Kun tämä toimitetaan moduulina, Google voi nopeuttaa tietoturvaparannuksia ilman, että sinun tarvitsee luottaa OTA-päivityksiin.

DNS Resolver

Kuten nimestä voi päätellä, DNS-selvitin ratkaisee DNS: n, eli se muuntaa ihmisen luettavissa olevat URL-osoitteet IP-osoitteiksi. Moduuli sisältää koodin, joka toteuttaa DNS-tunnisteen ratkaisijan, ja sen toimittaminen moduulina antaa Googlelle paremman suojan käyttäjille DNS-sieppauksia ja konfiguraatiopäivityshyökkäyksiä vastaan.

Asiakirjojen käyttöliittymä

Documents UI on moduuli, joka vastaa tiettyjen tiedostojen pääsyn hallinnasta asiakirjojen käyttöoikeuksia käsitteleville komponenteille. Kuten Google toteaa, tallennustilan käyttöoikeuksien ja käyttöoikeuksien lisääminen moduuliin lisää loppukäyttäjien yksityisyyttä ja turvallisuutta. Runtime Resource Overlay (RRO) -ominaisuuden avulla OEM-valmistajat voivat teemoida kokemuksen (viitaten Tiedostot-sovellukseen), jos he tarvitsevat to. Moduulina kaikki Google-Android-laitteet toimitetaan samalla asiakirjojen käyttöliittymällä.

ExtServices

Tämä moduuli sisältää kehyskomponentteja käyttöjärjestelmän ydintoimintoihin, kuten ilmoitusten luokitteluun, automaattisen täytön tekstin täsmäytysstrategioihin, tallennusvälimuistiin, pakettien valvontaan ja muihin palveluihin.

IPsec/IKEv2-kirjasto

Tämä kirjastomoduuli käsittelee uusia ja olemassa olevia Interworking Wireless LANin ominaisuuksia (IWLAN) ja VPN-verkot, kuten turvallisuusparametrien, kuten avainten, algoritmien ja tunnelin, neuvotteleminen kokoonpanot. Näiden toimintojen modularisoinnin ideana on edistää ekosysteemin johdonmukaisuutta ja tarjota tapa tarjota nopeita korjauksia turvallisuus- ja yhteentoimivuusongelmiin.

Nämä ovat kolme kaksihaaraista moduulia, mutta niillä on toisistaan ​​riippuvaisia ​​toimintoja. Nämä mediamoduulit käsittelevät mediatyyppejä ja koodeja, ovat vuorovaikutuksessa ExoPlayerin kanssa, paljastavat kuljetusohjaimet ja toistotiedot kehykselle, optimoivat indeksoidut metatiedot jne. Muistaa Stagefright, hyväksikäyttö, joka muutti Androidin ja toi alustan kuukausittaisten tietoturvapäivitysten konseptin? Tämä hyväksikäyttö perustui mediatoistokirjaston haavoittuvuuksiin. Joten mediakomponenttien modularisointi antaa Googlelle mahdollisuuden reagoida nopeasti ja laajasti, jos tästä usein kohdistetusta komponentista löytyy tietoturvavirheitä.

Tämän moduulin tehtävä on heti selvä sen nimestä, vaikka sen tarkoitus ei olekaan. Moduulin metatiedot -moduuli sisältää...metatietoja laitteen moduuliluettelosta. Ja siinä se.

Verkkopinon komponentit, verkkopinon käyttöoikeuksien määritys, sisäänkirjautuminen portaaliin

Network Stack Components -moduuli tarjoaa yleisiä IP-palveluita, verkkoyhteyksien valvonnan ja sisäänkirjautumisportaalin tunnistuksen. Käyttöoikeuksien määritysmoduuli määrittää käyttöoikeudet, joiden avulla muut moduulit voivat suorittaa verkkoon liittyviä tehtäviä. Captive Portal Login -moduuli käsittelee Captive Portals -verkkosivuja, jotka näytetään, kun yhteydessä tiettyihin julkisiin Wi-Fi-verkkoihin, joissa käyttäjää pyydetään antamaan tiedot Internetin saamiseksi pääsy.

Lupien valvoja

Tämä moduuli tarjoaa päivitettäviä tietosuojakäytäntöjä ja käyttöliittymäelementtejä käyttöoikeuksien myöntämiseen ja hallintaan. Jos tämä kuulostaa tutulta Package Installerin toiminnasta, se johtuu siitä, että se on sitä. Toiminnot, kuten ajonaikaisten käyttöoikeuksien myöntäminen, hallinta ja käytön seuranta, olivat osa Package Installer -sovellusta Android 9:ään asti. Android 10:ssä Package Installer -sovellus on jaettu osiin, jotta käyttöoikeuslogiikka voidaan päivittää. Permission Controller -moduuli toimitetaan APK-tiedostona, ja Android 11:ssä moduuli voi automaattisesti peruuttaa suorituksenaikaiset luvat sovelluksilta, joita ei ole käytetty pitkään aikaan.

SDK-laajennukset

Tämä moduuli on hieman vaikea ymmärtää ja siten selittää. Jokaiselle Android-julkaisulle on määritetty SDK-taso (yleensä +1 edeltäjästään). Kun sovellus kohdistaa tiettyyn SDK: hen, oletetaan, että kehittäjä on ottanut huomioon Android-julkaisun tuomat alustan käyttäytymisen ja API-muutokset.

SDK Extensions -moduuli määrittää laitteen "laajennuksen SDK"-tason ja paljastaa sovellusten sovellusliittymiä, jotka voivat kysellä laajennuksen SDK-tasoa. Siinä on kaikki, mitä viralliset asiakirjat mainitsevat. ArsTechnica, kuitenkin mainitsee että tämä on todennäköisesti toissijainen API-kerros, joka toimitetaan Play Kaupan kautta.

Statsd, telemetriajunan versiopaketti

Statsd vastaa laitemittareiden keräämisestä. Telemetriajunan versiopaketti sen sijaan ei sisällä aktiivista koodia tai mitään omaa toimivuutta. Se yksinkertaisesti sisältää versionumeron "telemetriajunalle", jonka Google sanoo olevan joukko mittareita koskevia moduuleja. Versionumeron perusteella Google Play näyttää tietoturvakorjausversion loppukäyttäjille ja selvittää, onko päivityksiä saatavilla mittareihin liittyville moduuleille.

Jaettu yhteys

Jaettu moduuli jakaa laitteen Internet-yhteyden muiden liitettyjen asiakaslaitteiden kanssa Wi-Fin, USB: n, Bluetoothin tai Ethernetin kautta. Moduuli sisältää jakokomponentit ja niiden riippuvuudet. Käyttämällä tätä jaettua moduulia OEM-valmistajat voivat luottaa yhteen, vakiomuotoiseen referenssitoteutukseen ja tarjota yhdenmukaisen käyttökokemuksen eri laitteissa.

Aikavyöhykkeen tiedot

Time Zone Data -moduuli päivittää kesäajan (DST) ja aikavyöhykkeet Android-laitteissa standardoimalla sekä tiedot (joka voi ja muuttuu melko usein vastauksena uskonnollisiin, poliittisiin ja geopoliittisiin syihin) ja päivitysmekanismiin kaikkialla ekosysteemissä. Android 8.1 ja Android 9 käyttivät APK-pohjaista aikavyöhyketietojen päivitysmekanismia, ja Android 10 korvaa sen APEX-pohjaisella moduulipäivitysmekanismilla. Google toteaa, että AOSP sisällyttää edelleen APK-pohjaisiin päivityksiin tarvittavan alustakoodin, joten Android 10:een päivitetyt laitteet voivat edelleen vastaanottaa kumppanin toimittamia aikavyöhyketietojen päivityksiä APK. Google kuitenkin varoittaa, että APK-pohjaiset päivitykset korvaavat APEX-pohjaiset päivitykset.

Wi-Fi

Tämä on Wi-Fi-toimintojen moduuli. Loppukäyttäjät voivat nyt saada yhtenäisen Wi-Fi-kokemuksen Android-laitteissa sekä korjata yhteentoimivuusongelmia moduulipäivitysten ja sovellusten kautta. kehittäjät voivat vähentää alustan pirstoutumista, ja OEM-valmistajat voivat täyttää operaattorin vaatimukset ja samalla vähentää yksittäisten kustannuksia mukautuksia.

---

Toivottavasti tämä artikkeli korostaa, kuinka tärkeä Project Mainline on Googlen Android-ekosysteemille.