Google strādā pie APEX: sistēmas bibliotēku atjaunināšana, piemēram, standarta Linux distro. Paredzēts operētājsistēmā Android Q, APEX var būt lielākā lieta kopš Project Treble.
APEX ieviešana, iespējams, ir lielākās galvassāpes, ar kurām Google ir saskārusies kopš Project Treble ieviešanas. Kas ir APEX un kā tā ieviešana mainīs Android?
APEX ideja pati par sevi ir diezgan izplatīta ikdienas GNU/Linux izplatījumos: pakotņu atjauninājumi, kas vērsti uz noteiktām Linux bibliotēkas kopas sadaļām. Taču Google to nekad nemēģināja darīt, ņemot vērā, ka Android ir izmantojis RO (tikai lasāmu) nodalījumu, kurā ir visas sistēmas bibliotēkas un ietvari tiek glabāti salīdzinājumā ar parastajiem RW (lasīšanas un rakstīšanas) nodalījumiem, ko izmanto lielākajā daļā Linux izplatījumu, padarot standarta jaunināšanas procesu. nepiemērots.
Bibliotēkas ir iepriekš kompilēts kods, ko var izmantot citās programmās. Parasti izmantotās metodes var izveidot par bibliotēkām Android lietotnēm, lai tās varētu izsaukt, samazinot APK failu lielumu, jo viens un tas pats kods nebūs atkārtoti jāievieto vairākās lietotnēs. Daudzas iepriekš instalētas sistēmas bibliotēkas var atrast direktorijās /system/lib un /system/lib64. Android sistēmu bibliotēkas parasti netiek atjauninātas atsevišķi — tās tiek atjauninātas kā daļa no Android platformu jauninājumiem, izmantojot OTA atjauninājumu. No otras puses, bibliotēkas Linux distros var atjaunināt atsevišķi. Ieviešot APEX, sistēmas bibliotēkas operētājsistēmā Android var atjaunināt atsevišķi, piemēram, Android lietotnes. Galvenais ieguvums no tā ir tas, ka lietotņu izstrādātāji varēs izmantot atjaunināto bibliotēku sniegtās priekšrocības, negaidot, kamēr oriģinālā aprīkojuma ražotājs ieviesīs pilnu sistēmas jauninājumu. Iedziļināsimies tehniskās detaļās par to, kā darbojas APEX.
Kā APEX mainīs veidu, kā tiek atjauninātas bibliotēkas?
APEX ir ekosistēma, kas piespieda (vai drīzāk piespiež) Google pārskatīt veidu, kā Android ielādē visas bibliotēkas un failus no nestandarta nodalījuma, kas atšķiras no /system.
Pirmkārt, mums ir jānorāda atšķirība starp koplietojamo bibliotēku un statisko bibliotēku. Koplietojama bibliotēka ir bibliotēka (parasti fails ar nosaukumu libkind.so), kurā nav ietverts viss kods, kas nepieciešams, lai darbotos pati par sevi, bet ir faktiski saistīta ar citām bibliotēkām. sniedzot kodu, savukārt statiskā bibliotēka, kā jūs varat uzminēt, ir bibliotēka, kas nav atkarīga no citām bibliotēkām un kurā viss ir iekļauts statiski failu.
Android ir vēsturiski konfigurējis bibliotēkas ceļu (pazīstams kā LD_LIBRARY_PATH Linux pasaulē) ar vienu failu ko sauc par ld.config.txt [0], lai konfigurētu atļautos meklēšanas ceļus koplietotajām bibliotēkām, kas nepieciešamas binārajai vai citai bibliotēkai bibliotēka. Šie ceļi konfigurācijā ir iekodēti un nav paplašināmi. Šis izkārtojums, tostarp tikai lasāms sistēmas nodalījums, noved pie neatjaunināmām bibliotēkām, ja vien lietotājs neinstalē OTA Android atjauninājumu. Google novērsa šo problēmu, ļaujot paplašināt meklēšanas ceļu, ļaujot atsevišķām APEX pakotnēm nodrošināt savu ld.config.txt, kas ietvēra tajos esošos papildu (un atjauninātos) bibliotēku ceļus.
Lai gan šis solis atrisināja vienu no galvenajām problēmām, joprojām bija dažas nopietnas problēmas, kas jāpārvar. Pirmkārt: ABI (application binary interface) stabilitāte. Bibliotēkām vienmēr ir jāeksportē stabila saskarņu kopa, lai citas programmas un bibliotēkas varētu turpināt darbu ar to pašu protokolu pat ar jaunināto bibliotēku. Google aktīvi strādā pie tā, mēģinot izveidot stabilu C saskarni starp APEX bibliotēkām.
Bet APEX neaprobežojas tikai ar bibliotēkām un binārajiem failiem. Faktiski tajā var būt konfigurācijas faili, laika joslu atjauninājumi un daži Java ietvari (rakstīšanas laikā tiek šifrēti).
Šeit ir daži pašreizējo AOSP nodrošināto APEX pakotņu piemēri:
- com.android.runtime: ART un bioniskais izpildlaiks (binārie faili un bibliotēkas)
- com.android.tzdata: TimeZone un ICU dati (bibliotēkas un konfigurācijas dati)
- com.android.resolv: bibliotēka, ko Android izmanto, lai atrisinātu ar tīklu saistītus pieprasījumus (bibliotēkas)
- com.android.conscrypt: Java drošības nodrošinātājs (Java ietvars)
Kā tiek instalēta un strukturēta APEX pakotne?
APEX pakotne ir vienkāršs zip arhīvs (piemēram, APK), ko var instalēt mūsu parocīgais ADB (šajā izstrādes brīdī). un vēlāk lietotājs pats, izmantojot pakotņu pārvaldnieku (piemēram, Google Play vai manuāli, izmantojot Android pakotni uzstādītājs).
ZIP izkārtojums ir šāds:
Iedziļināsimies tajā.
Fails apex_manifest.json norāda pakotnes nosaukumu un versiju.
Apex_payload.img ir mikrofailu sistēmas attēls (formatēts kā EXT4).
Pārējie faili ir daļa no verifikācijas procesa, ko izmanto pakotnes instalēšanai. Paskatīsimies.
Klātbūtne AndroidManifest.xml, pat ja tas tiek izmantots galvenokārt lietojumprogrammās, palīdz mums saprast, ka lielākā daļa standarta APK instalēšanai izmantotās ieviešanas tiek atkārtoti izmantotas pat šīm pakotnēm. Faktiski tiek pārbaudīts tikai paplašinājums, lai tos atšķirtu.
The META-INF/ direktorijā ir pakotnes sertifikāts, un tas izmanto to pašu mehānismu kā parastie APK. Tātad šie iepakojumi tiek pārbaudīts ar privāto/publisko atslēgu pāris izpildlaikā, pirms lietotājs var instalēt atjauninājumu. Taču uzņēmumam Google ar to nepietika, tāpēc viņi pievienoja vēl 2 drošības līmeņus. Viņi izmanto dm-verity, lai pārbaudītu attēla integritāti, un AVB (Android Verified Boot) verifikācijas, lai pārliecinātos, ka attēls nāk no uzticama avota. Sliktākajā gadījumā APEX pakotne tiks noraidīta.
Ja visas verifikācijas darbības ir veiksmīgas, attēls tiks atzīmēts kā derīgs un nākamajā atsāknēšanas reizē aizstās sistēmas variantu.
Kā sāknēšanas laikā tiek instalēts attēls?
Sāksim, apskatot APEX, kas pašlaik ir instalēti manā ierīcē (emulators).
Kā redzat, iepriekš instalētās pakotnes tiek glabātas mapē /system/apex/, un tām visām pašlaik ir versija 1. Bet kas notiek, kad tiek aktivizēts APEX? Kā piemēru mēs atkal izmantosim com.android.tzdata.
Pārstartēsim ierīci un analizēsim logcat.
Pirmajās 2 rindiņās ir pietiekami daudz informācijas, lai saprastu iepakojuma izcelsmi un to, kur tā atradīsies instalēts: /apex/, jauns direktorijs, kas ieviests operētājsistēmā Android Q, kas tiks izmantots, lai saglabātu aktivizēto iepakojumiem.
Pēc tam, kad pakotne ir veiksmīgi pārbaudīta ar AVB un publiskā atslēga atbilst, APEX, izmantojot cilpas ierīci, tiek uzstādīts uz /dev/block/loop0, padarot EXT4 failu sistēmu pieejamu sistēmai. Cilpas ierīce ir pseidoierīce, kas padara failu pieejamu kā blokierīci, padarot šī faila saturu pieejamu kā stiprinājuma punktu.
Šobrīd APEX joprojām netiek izmantots @1 sufiksa dēļ (kas norāda pakotnes versiju). Lai beidzot paziņotu sistēmai, ka mūsu pakotne ir veiksmīgi aktivizēta, tā tiks piesaistīta /apex/com.android.tzdata, kur Android aktīvi sagaida tzdata darbību. Saistīšanas stiprinājums pārklāj esošu direktoriju vai failu zem cita punkta. [1]
APEX ieviešana pilnībā ir ietverta vienā AOSP repozitorijā. [2] Apexd (APEX dēmona) direktorijā ir kods, kas darbojas operētājsistēmā Android. Apexer direktorijā ir kods, ko izmanto būvēšanas sistēma, lai izveidotu APEX pakotnes.
Kāds ir mērķis?
Šobrīd viss, ko varu darīt, ir spekulēt. Mans labākais minējums ir tāds, ka Google mēģina izveidot APEX pakotņu pamatkopu, ko Google var atjaunināt, lai, iespējams, izveidotu vienots Android bāzes kodols, kas tiek koplietots starp pārdevējiem, padarot iespējamus tikai sistēmas atjauninājumus, bet izmantojot vienu pakotni atjauninājumus.
Vai visas ierīces atbalstīs APEX?
Nē. Piemēram, lai atjauninātu visus Android moduļus, funkcijai apexd ir jābūt pieejamai /data/apex tūlīt pēc sāknēšanas. Izmantojot FDE (pilna diska šifrēšanu), /data/apex tiek šifrēts, līdz lietotājs ir atbloķējis ierīci, padarot APEX būtībā nederīgu, jo sāknēšanas laikā tiks ielādēti tikai sistēmas APEX varianti. Izņemot to, visām ierīcēm ir jāatbalsta APEX, taču tām ir nepieciešami daži kodola ielāpi (daudzus no tiem Google ir atraduši labojumi, spēlējot ar cilpas ierīcēm). [3] [4]
Avoti [0], [1], [2], [3], [4]