Гоогле ради на АПЕКС-у: ажурирање системских библиотека попут стандардне дистрибуције Линука. Очекује се у Андроид К-у, АПЕКС је можда највећа ствар од Пројецт Требле.
Имплементација АПЕКС-а је вероватно највећа главобоља са којом се Гоогле суочио од увођења Пројецт Требле. Шта је АПЕКС и како ће његово увођење променити Андроид?
Идеја која стоји иза АПЕКС-а сама по себи је прилично уобичајена у свакодневним ГНУ/Линук дистрибуцијама: ажурирања пакета циљају на одређене делове скупа Линук библиотека. Али то је нешто што Гоогле никада није покушао да уради с обзиром да је Андроид користио РО (само за читање) партицију на којој су све системске библиотеке и оквири се чувају у односу на уобичајене РВ (читање-уписивање) партиције које се користе у већини Линук дистрибуција, што представља стандардни процес надоградње неприкладан.
Библиотеке су унапред компајлирани код који се може користити у другим програмима. Често коришћене методе могу да се направе у библиотеке за позивање Андроид апликација, смањујући величину АПК-ова јер исти код неће морати да се поново примењује у више апликација. Можете пронаћи многе унапред инсталиране системске библиотеке у директоријумима /систем/либ и /систем/либ64. Андроид системске библиотеке се обично не ажурирају појединачно – уместо тога, ажурирају се као део надоградње Андроид платформи путем ОТА ажурирања. С друге стране, библиотеке у Линук дистрибуцијама могу се ажурирати појединачно. Са увођењем АПЕКС-а, системске библиотеке у Андроид-у могу се ажурирати појединачно попут Андроид апликација. Главна предност овога је што ће програмери апликација моћи да искористе предности ажурираних библиотека без чекања да ОЕМ изврши потпуну надоградњу система. Хајде да заронимо у више техничких детаља о томе како АПЕКС функционише.
Како ће АПЕКС променити начин на који се библиотеке ажурирају?
АПЕКС је екосистем који је приморао (тачније, присиљавао) Гоогле да преиспита начин на који Андроид учитава све библиотеке и датотеке са нестандардне партиције различите од /систем.
Пре свега, морамо да наведемо разлику између дељене библиотеке и статичке библиотеке. Заједничка библиотека је библиотека (обично датотека под називом либкинд.со) која не укључује сав код потребан за покретање у себи, али је заправо „повезана“ са другим библиотекама пружајући код, док је статичка библиотека, као што можете претпоставити, библиотека која не зависи ни од једне друге библиотеке и има све укључено статички унутар фајл.
Андроид је историјски конфигурисао путању библиотеке (познату као ЛД_ЛИБРАРИ_ПАТХ у Линук свету) са једном датотеком под називом лд.цонфиг.ткт [0] да конфигурише дозвољене путање за претрагу за дељене библиотеке које су потребне за бинарни или други библиотека. Ове путање су чврсто кодиране у конфигурацији и нису прошириве. Овај распоред, укључујући системску партицију само за читање, води до библиотека које се не могу ажурирати осим ако корисник не инсталира ОТА ажурирање за Андроид. Гоогле је решио овај проблем дозвољавајући проширење путање претраге тако што је дозволио да појединачни АПЕКС пакети обезбеде сопствени лд.цонфиг.ткт који је укључивао додатне (и ажуриране) путање библиотека које се налазе у њима.
Иако је овај потез решио један од главних проблема, остало је још неколико озбиљних проблема које је требало превазићи. Пре свега: стабилност АБИ (бинарни интерфејс апликације). Библиотеке увек треба да извозе стабилан скуп интерфејса како би омогућиле другим апликацијама и библиотекама да наставе да раде са истим протоколом чак и са надограђеном библиотеком. Гоогле активно ради на томе покушавајући да створи стабилан Ц интерфејс између АПЕКСед библиотека.
Али АПЕКС није ограничен само на библиотеке и бинарне датотеке. У ствари, може да садржи конфигурационе датотеке, ажурирања временске зоне и неке Јава оквире (конкриптоване у време писања).
Ево неколико примера тренутних АПЕКС пакета које обезбеђује АОСП:
- цом.андроид.рунтиме: АРТ и бионичко време извођења (бинарне датотеке и библиотеке)
- цом.андроид.тздата: Подаци о временској зони и ИЦУ (библиотеке и конфигурациони подаци)
- цом.андроид.ресолв: Библиотека коју користи Андроид за решавање мрежних захтева (библиотеке)
- цом.андроид.цонсцрипт: Јава безбедносни добављач (Јава оквир)
Како је АПЕКС пакет инсталиран и структуриран?
АПЕКС пакет је једноставна зип архива (као АПК) коју може да инсталира наш практични АДБ (у овом тренутку у развоју) а касније и сам корисник преко менаџера пакета (као што је Гоогле Плаи или ручно преко Андроид пакета инсталатер).
ЗИП изглед је следећи:
Уронимо у то.
апек_манифест.јсон наводи име пакета и верзију.
апек_паилоад.имг је слика микро фајл система (форматирана као ЕКСТ4).
Остале датотеке су део процеса верификације који се користи за инсталирање пакета. Хајде да погледамо.
Присуство АндроидМанифест.кмл, чак и ако се користи углавном у апликацијама, помаже нам да разумемо да се већина имплементације која се користи за стандардну инсталацију АПК-а поново користи чак и за ове пакете. У ствари, проверава се само проширење да би се разликовали између њих.
Тхе МЕТА-ИНФ/ директоријум има сертификат пакета и користи исти механизам као и нормални АПК-ови. Дакле, ови пакети верификовани су паром приватних/јавних кључева у току рада пре него што кориснику буде дозвољено да инсталира ажурирање. Али то није било довољно за Гоогле, па су додали још 2 слоја безбедности. Они користе дм-верити за проверу интегритета слике и АВБ (Андроид Верифиед Боот) верификације како би били сигурни да слика долази из поузданог извора. У најгорем случају, АПЕКС пакет ће бити одбијен.
Ако су сви кораци верификације успешни, слика ће бити означена као важећа и замениће варијанту система при следећем поновном покретању.
Како се слика инсталира при покретању?
Хајде да почнемо тако што ћемо погледати АПЕКС-ове који су тренутно инсталирани на мом уређају (емулатор)
Као што видите, унапред инсталирани пакети су ускладиштени у /систем/апек/ и сви су тренутно на верзији број 1. Али шта се дешава када се АПЕКС активира? Поново ћемо користити цом.андроид.тздата као пример.
Хајде да поново покренемо уређај и анализирамо логцат.
Прва 2 реда пружају довољно информација да разумете порекло пакета и где ће он бити инсталиран: /апек/, нови директоријум уведен у Андроид К који ће се користити за чување активираног пакети.
Након што је пакет успешно верификован помоћу АВБ-а и јавни кључ се подудара, АПЕКС се монтира помоћу уређаја петље на /дев/блоцк/лооп0, чинећи ЕКСТ4 систем датотека доступним систему. Уређај петље је псеудо-уређај који чини датотеци приступачна као блок уређај, чинећи садржај те датотеке доступним као тачку монтирања.
У овом тренутку, АПЕКС се још увек не користи због суфикса @1 (који означава верзију пакета). Да бисмо коначно обавестили систем да је наш пакет успешно активиран, биће повезан на /апек/цом.андроид.тздата где Андроид активно очекује да ће тздата живети. Повезивање прекрива постојећи директоријум или датотеку испод друге тачке. [1]
Имплементација АПЕКС-а је у потпуности садржана у једном спремишту под АОСП-ом. [2] Директоријум апекд (АПЕКС даемон) има код који ради на Андроиду. Директоријум апекер садржи код који користи систем за прављење АПЕКС пакета.
Која је сврха?
У овом тренутку, све што могу да урадим је да спекулишем. Моја најбоља претпоставка је да Гоогле покушава да направи основни скуп АПЕКС пакета које Гоогле може ажурирати да би евентуално креирао обједињено основно језгро Андроид-а које деле произвођачи, чинећи могућим само ажурирање „система“, али коришћењем једног пакета ажурирања.
Да ли ће сви уређаји подржавати АПЕКС?
Не. На пример, апекд захтева да /дата/апек буде доступан одмах након покретања да би се ажурирали сви Андроид модули. Са ФДЕ (шифровањем преко целог диска), /дата/апек се шифрује све док корисник не откључа уређај, чинећи АПЕКС у основи бескорисним јер ће се при покретању учитавати само системске АПЕКС варијанте. Осим тога, сви уређаји би требало да подржавају АПЕКС, али им је потребно неколико закрпа за језгро (од којих су многе исправке које је пронашао Гугл док се игра са уређајима петље). [3] [4]
Извори [0], [1], [2], [3], [4]