Google vispārīgais kodola attēls ir nākamais solis Android sadrumstalotības problēmas risināšanā

Google gadiem ilgi ir strādājis, lai samazinātu sadrumstalotību operētājsistēmā Android, lai gan daļa no tā ir Android raksturīgā būtība un izvēles un brīvības abpusējais zobens. Telpā aktīvi darbojas neskaitāmi oriģinālo iekārtu ražotāji, un viņi visi vēlas veikt savas ierīces modifikācijas. Problēma ir tāda, ka šķiet, ka Android OS atjauninājumi tiek ieviesti lēni, taču Google nevar darīt daudz, lai piespiestu OEM atjaunināt savas ierīces. Tādējādi nākamā labākā lieta, ko Google var darīt, ir padarīt atjaunināšanas procesu pēc iespējas vienkāršāku un bezrūpīgāku.

Android atjaunināšanas problēmu atvieglošana

Pirmā lielā iniciatīva Google ilgtermiņa projektā, lai samazinātu attīstības slogu, bija Projekts Treble. Projekts Treble, kas tika paziņots kopā ar Android 8.0 Oreo 2017. gadā, modularizēja Android, atdalot OS sistēmu no pārdevēja ieviešanas (HAL un ierīcei raksturīgā Linux kodola dakšas). Tādējādi Android oriģinālo iekārtu ražotājiem bija vieglāk pārbūvēt savas operētājsistēmas, izmantojot jaunāko AOSP sistēmu, jo viņi varēja palaist jaunāko versiju, neprasot atjauninātu kodu no pārdevējiem. Rezultātā oriģinālo iekārtu ražotāji varēja ātrāk nekā iepriekš sagatavot savus pielāgotos Android dakšas, kā arī ātrāk ieviest galvenos OS atjauninājumus.

Nākamais solis Google plānos bija racionalizēt galveno Android komponentu atjauninājumu piegādi. Google nosauca šo iniciatīvu Projekta galvenā līnija kad tas 2019. gadā to ieviesa kopā ar Android 10. Google būtībā pārņēma kontroli pār galvenajiem OS komponentiem un aizliedza oriģinālo iekārtu ražotājiem tos modificēt. Pēc tam viņi izveido piegādes mehānismu, izmantojot pakalpojumu Google Play, lai viņi varētu attālināti ieviest šo galveno komponentu atjauninājumus, negaidot, kamēr oriģinālo iekārtu ražotāji paši uzliks ielāpus. Mainline ievērojami uzlaboja to, cik ātri ierīces saņem svarīgu OS komponentu atjauninātās versijas, tādējādi uzlabojot Android ekosistēmas drošību kopumā.

Tomēr, runājot par Treble, Linux kodolu reāli nevajadzētu apvienot ar slēgtā pirmkoda piegādātāja kodu. Tods Kjos plkst šī gada Linux santehniķu konference ir izskaidrojis grūtības, ar kurām jāsaskaras, kad runa ir par Android sadrumstalotību, un liela daļa no tām tagad ir vērsta uz Linux kodolu, ko OEM piegādā kopā ar savām ierīcēm. Kontekstam Google katru galveno Linux kodolu veido "Android kopējais kodols” (ACK) filiāle, kas rūpīgi izseko galvenās līnijas izlaišanai, bet pievieno dažus Android specifiskus ielāpus. SoC pārdevēji, piemēram, Qualcomm, MediaTek un Samsung, pēc tam atgriežas ka kodols katram SoC, ko tie ražo. Pēc tam oriģinālo iekārtu ražotāji izmanto šo SoC specifisko kodolu un pievieno papildu ielāpus, lai ieviestu atbalstu konkrētajai aparatūrai, kuru viņi vēlas nosūtīt.

Iepriekš redzamā diagramma parāda, kā ierīces kodols iziet cauri vairākiem izmaiņu slāņiem, kas to abstrahē tālu no Linux LTS kodola. Lai to vienkāršotu, mēs sākam ar Linux kodolu, un tas tiek apvienots Android kopējā kodolā, veicot dažas izmaiņas. No turienes Android Common Kernel tiek apvienots pārdevēja kodolā (Qualcomm, MediaTek utt.) ar savām modifikācijām un izmaiņām. Visbeidzot, pārdevēja kodols tiek sapludināts ar OEM ierīces kodolu. Šajā posmā jebkuras ierīces kodols ir tālu no Linux LTS kodola, ar kuru tā sākās.

Visu šo dakšu rezultātā pat 50% koda, kas darbojas Android ierīcē, ir ārpus koka kods, kas nozīmē, ka tas nav no iepriekšējiem Linux vai AOSP parastajiem kodoliem. Tas padara neticami sarežģītu (nemaz nerunājot par laikietilpīgu un dārgu) iepriekšējo izmaiņu apvienošanu. Oriģinālo iekārtu ražotājiem nav stimula to darīt, taču šāda prakse var kaitēt ierīču drošībai. Tas ir arī iemesls, kāpēc daudzas Android ierīces ir atstātas vecākos LTS kodola laidienos, kā rezultātā ierīces zaudē piekļuvi jaunajām Linux kodola funkcijām.

Android ir sadrumstalota, un Google to zina

Google labi zina, ka tā ir problēma, un pat ir sadaļa ar nosaukumu "Sadrumstalotības izmaksas" Android izstrādātāja dokumentācijā. Google to saka "Lielākā daļa vadošo ierīču tiek piegādātas ar kodola versiju, kas jau ir vismaz 18 mēnešus veca". Vēl sliktāk, to saka arī Google "Android 10 atbalsta 3.18, 4.4, 4.9, 4.14 un 4.19 kodolus, kas dažos gadījumos nav uzlaboti ar jaunām funkcijām kopš Android 8 2017. gadā." Tas apgrūtina funkciju pievienošanu, kurām nepieciešamas jaunas Linux kodola versijas. Linux kodols 3.18 tika palaists 2014. gada decembrī, kad Android 5.0 Lollipop bija jaunākā Android versija. Tā nepārprotami ir problēma un var aizkavēt platformu.

Piemēram, Code Aurora Forum jeb saīsināti CAF mitina dažādu Qualcomm Snapdragon SoC pirmkodu. Qualcomm kā SoC pārdevējs, izplata Linux kodola dakšveida versiju oriģinālo iekārtu ražotājiem/ODM, un šie uzņēmumi pēc tam pievieno ierīcei specifiskas izmaiņas piegādes laikā. ierīces. Tas rada vairākus sadrumstalotības slāņus. Turklāt Qualcomm veic izmaiņas AOSP sistēmā, lai optimizētu Android katrai uzņēmuma Snapdragon mobilajai platformai. Qualcomm privāti izplata savu modificēto Linux kodolu, AOSP ietvaru un citus programmatūras rīkus saviem partneriem kā daļu no Board Support Package jeb BSP. CAF ir vieta, kur Qualcomm publiski publicē šīs Linux kodola izmaiņas un AOSP sistēmas izmaiņas.

Šis CAF laidiens var būt noderīgs pielāgotiem ROM izstrādātājiem, kuri vēlas to izmantot kā sākumpunktu, nevis tīru AOSP, tāpēc dažreiz jūs redzat “Uz CAF balstītas” ROM mūsu forumos. Vai atceraties Snapdragon 625, kas gadiem ilgi šķita darbināms tik daudziem vidējas klases viedtālruņiem? Tas tika palaists ar Linux kodolu 3.18, un tikai 2018. gada beigās (divus gadus pēc mikroshēmojuma palaišanas) Qualcomm atjaunināja kodola avotus un publicēja tos CAF msm8953 (Snapdragon 625 mikroshēmojuma nosaukums), kas nodrošina atbalstu Linux kodolam 4.9. Problēma ir tā, ka lielākā daļa OEM neatjauninās tālruņus uz šo jauno Linux kodola versiju, jo īpaši ne vidēja līmeņa tālruņus divus gadus pēc mikroshēmas ieviešanas. atbrīvots. Jāatzīst, ka ir ļoti reti gadījumi, kad šāds nozīmīgs kodola atjauninājums vispār notiek, taču būtība ir tāda, ka ir noticis, tāpēc tas nav tikai neiespējams scenārijs.

Kopumā pašreizējā Android sadrumstalotība, viegli izsakoties, ir haoss. Google jaunākie mēģinājumi novērst šo sadrumstalotību ir vispārīgā kodola attēla vai GKI veidā.

Iepazīstinām ar vispārējo kodola attēlu

Lai novērstu šo sadrumstalotību, Google strādāja pie Android vispārīgā kodola attēla (GKI). Tas būtībā ir kodols, kas kompilēts tieši no ACK filiāles. GKI izolē SoC pārdevēju un OEM pielāgojumus spraudņu moduļiem, novēršot ārpuskopienas kodu un ļaujot Google nosūtīt kodola atjauninājumus tieši galalietotājam. Vairāk nekā gadu Google ir strādājis pie veida, kā nodrošināt GKI atjauninājumus, izmantojot Play veikalu, izmantojot Mainline moduli.

Rezultātā ierīcēm, kas tiek palaistas ar operētājsistēmu Android 12 un kurās darbojas Linux kodols 5.10.43 vai jaunāka versija, ir jāveic viena no šīm darbībām. saskaņā ar Mišalu Rahmanu.

• Izvietojiet Google parakstītu sāknēšanas attēlu

VAI

• Izvietojiet sāknēšanas attēlu ar kodolu, kas eksportē KMI (Kernel Module Interface), kas ir GKI eksportētā KMI apakškopa, eksportē userspace API, kas ir UAPI superkopa, ko atklāj GKI, un atbalsta visas atbilstošās GKI funkcijas. versija

Pārdevēji var izveidot moduļus, kas pievienojami GKI, taču GKI ideja ir tāda, ka Google uzņemas atbildību par kodola izmaiņu apstrādi. Kodola moduļa interfeiss (vai KMI, vairāk par to raksta turpmākajās daļās) ir vieta, kur paredzēts izmantot ārpus koka esošo kodu.

Google Pixel 6 sērija tika izlaista ar operētājsistēmu Android 12 un tiek piegādāta ar Linux kodolu 5.10, un tas ir pirmais tālrunis, kas tiek piegādāts ar GKI. Tā kā Google varētu atjaunināt kodolu, izmantojot Play veikalu, mēs pat varētu redzēt biežus kodola atjauninājumus, jo LTS kodola atjauninājumi parasti tiek izlaisti katru nedēļu. Jebkurā gadījumā tā ir daudz labāka sistēma nekā pašlaik apgrūtinošā atjaunināšanas metode, izmantojot OTA, lai gan tas nozīmē, ka tā ir pēc būtības saistīta ar GMS sistēmu.

Google vienkārši definē GKI šādi:

• Tas ir veidots no ACK avotiem.
• Tas ir viena kodola binārs un saistīti ielādējami moduļi katrai arhitektūrai katrai LTS laidienai (šobrīd tikai arm64 android11-5.4 un android12-5.4).
• Tas ir pārbaudīts ar visiem Android platformas laidieniem, kas tiek atbalstīti saistītajam ACK. GKI kodola versijas darbības laikā netiek pārtraukta funkcija
• Tas parāda stabilu KMI vadītājiem noteiktā LTS ietvaros.
• Tas nesatur SoC vai plates kodu.

Google pat vēlas līdz 2023. gadam būt tādā pozīcijā, kurā tā varētu izmantot "pirmkārt" attīstības modeli. Tas palīdzēs Google nodrošināt, ka jaunais kods vispirms nonāk galvenajā Linux kodolā, samazinot "tehnisko parādu", kas uzkrāts ārpus koka Android ierīcēs.

Kodola moduļa interfeiss (KMI)

Kodola moduļa interfeiss jeb KMI ir daļa no Google risinājuma saistībā ar notiekošo Android sadrumstalotību. Būtībā SoC un plates atbalsts vairs neatrodas kodola kodolā, un tā vietā tiek pārvietoti ielādējamos moduļos. Gan kodolu, gan moduļus var atjaunināt neatkarīgi, jo moduļi tiek atjaunināti /lib/modules. Pašam GKI ir jābūt pēc iespējas tīrākam un vispārīgākam, kas ir iespējams, izkraujot to, kas tagad ir ārpus koka, atsevišķos moduļos.

Kā Teds Kjoss paskaidroja plkst Šī gada Linux santehniķu konferencē "lielais vairāku gadu uzdevums ir iegūt visu aparatūrai raksturīgo kodu no vispārējā kodola un iekļaut pārdevēju moduļos. Mums ir jābūt stabilam interfeisam starp šiem pārdevēja moduļiem un vispārējo kodolu, lai tos varētu nosūtīt asinhroni." GKI 1.0 būtībā ir "atbilstības pārbaude".

Faktiski GKI saderība nozīmē, ka ierīce iztur VTS un CTS-on-GSI+GKI testus ar vispārējo sistēmas attēlu (GSI). un GKI kodols, kas instalēts, mirgojot GKI sāknēšanas attēlu sāknēšanas nodalījumā un GSI sistēmas attēlu sistēmā nodalījums. Vendor Test Suite jeb VTS ir automatizēts tests, kas jāiztur visām ierīcēm, lai tās uzskatītu par saderīgām ar Project Treble. Saderības testa komplekts jeb CTS ir nepieciešams, lai piekļūtu Google lietojumprogrammu komplektam.

Ierīces var piegādāt ar citu produkta kodolu un var izmantot ielādējamus moduļus, ko GKI nenodrošina. Tomēr gan produktam, gan GKI kodoliem ir jāielādē moduļi no viena un tā paša vendor_boot un vendor partition. Tādēļ visiem produktu kodoliem ir jābūt vienam un tam pašam binārā kodola moduļa interfeisam (KMI).

Iepriekš redzamā diagramma parāda, ko Google vēlas ko darīt, un paskaidro, kā tā plāno to sasniegt. Generic Kernel un GKI moduļi būs daļa no AOSP, un GKI var sazināties ar Android sistēmu un aparatūras abstrakcijas slāni (HAL), ko pārdevējs var ieviest. Tā vietā konkrētais patentētais kods, ko pārdevējs vēlas iekļaut kodolā (piemēram, kameras draiveri), tiks ievietots pārdevēja modulī, kas kļūst par GKI paplašinājumu, izmantojot KMI.

Kā GKI var palīdzēt atrisināt Android sadrumstalotības problēmu

Google ir ieguldījis daudz darba, lai racionalizētu viedtālruņu izstrādes procesu. Katrs OEM vēlas savu zīmola identitāti, un katrs OEM vēlas iegūt īpašumtiesības uz savām ierīcēm. Atšķirībā no Android One programmas Android viedtālruņi var būt tādi, kādi tie vēlas, ja vien tie ievēro Google noteikto noteikumu kopumu, lai saņemtu GMS licenci. Tomēr iepriekš Google nav darījis daudz, lai valdītu Android ierīču izstrādē, ar izmaiņas, piemēram, Project Treble, Mainline un tagad GKI ir daudz jaunākas Android ierīcēs vēsture.

Bet vai tas palīdzēs? Tam vajadzētu būt, lai gan tas, visticamāk, būs vairākus gadus ilgs pasākums, kas vēlāk nesīs redzamus augļus. Tas attieksies tikai uz ierīcēm, kas tiek palaistas ar operētājsistēmu Android 12, kas nozīmē, ka turpmākajos gados mēs redzēsim ierīces, kurām nebūs GKI. Tas bija arī projekta Treble kritika, kad tas tika paziņots, lai gan acīmredzot visas mūsdienās palaistās ierīces to atbalsta. Šīs lietas prasa laiku, un Google lēnām pārņem Android valdīšanu, tāpēc izstrādes process tiek atvieglots visiem oriģinālo iekārtu ražotājiem Android ekosistēmu, pat ja daži no tiem labprātāk saglabātu pilnīgu kontroli pār Linux kodolu, kas tiek izmantots operētājsistēmā Android viedtālruņi.