Гоогле-ова генеричка слика кернела је следећи корак ка решавању проблема фрагментације Андроид-а

Гоогле годинама ради на смањењу фрагментације на Андроид-у, иако је део узрока томе инхерентна природа Андроид-а и мач са две оштрице избора и слободе. Постоји безброј ОЕМ-а активних у простору, и сви они желе да направе сопствене модификације за своје уређаје. Проблем је у томе што изгледа да се ажурирања Андроид ОС-а споро објављују широм света, али не постоји много тога што Гоогле може да уради да би приморао ОЕМ произвођаче да ажурирају своје уређаје. Као таква, следећа најбоља ствар коју Гоогле може да уради је да процес ажурирања учини што лакшим и лакшим.

Олакшавање проблема са ажурирањем Андроид-а

Прва велика иницијатива у Гооглеовом дугорочном пројекту за смањење терета развоја била је Пројецт Требле. Најављен уз Андроид 8.0 Орео 2017. године, Пројецт Требле је модуларизирао Андроид тако што је одвојио оквир ОС од имплементације добављача (ХАЛ-ови и виљушка за Линук кернел специфична за уређај). Ово је олакшало Андроид ОЕМ произвођачима да поново базирају своје оперативне системе на најновијим АОСП оквирима, јер су могли да покрену најновију верзију без потребе за ажурираним кодом произвођача. Као резултат тога, произвођачи оригиналне опреме могли би да припреме своје прилагођене Андроид виљушке брже него раније и да брже уведу главна ажурирања ОС-а.

Следећи корак у Гоогле-овим плановима био је да поједностави испоруку ажурирања кључних Андроид компоненти. Гугл је позвао ову иницијативу Пројецт Маинлине када га је представио уз Андроид 10 2019. Гоогле је у суштини преузео контролу над кључним компонентама ОС-а и забранио ОЕМ-има да их модификују. Затим су поставили механизам испоруке преко Гоогле Плаи-а како би могли даљински да уведу ажурирања за ове кључне компоненте без потребе да чекају да ОЕМ-ови сами примене закрпе. Маинлине је увелико побољшао брзину којом уређаји добијају ажуриране верзије важних компоненти ОС-а, што је заузврат побољшало безбедност Андроид екосистема у целини.

Међутим, када је реч о Требле-у, Линук језгро реално не би требало да се комбинује са затвореним кодом добављача. Тодд Кјос ат овогодишња конференција Линук водоинсталатера је у прошлости објаснио потешкоће са којима се суочавају када је у питању фрагментација на Андроиду, а много тога се сада концентрише на Линук кернел који ОЕМ-ови испоручују са својим уређајима. За контекст, Гоогле раздваја свако главно језгро Линука у „Андроид заједничко језгро” (АЦК) грана, која пажљиво прати главно издање, али додаје неколико закрпа специфичних за Андроид. Продавци СоЦ-а као што су Куалцомм, МедиаТек и Самсунг се затим рачвају то кернел за сваки СоЦ који направе. ОЕМ-ови затим узимају то језгро специфично за СоЦ и додају додатне закрпе за имплементацију подршке за одређени хардвер који желе да испоруче.

Горњи дијаграм показује како језгро уређаја пролази кроз неколико слојева промена које га апстрахују далеко од Линук ЛТС кернела. Да бисмо га поједноставили, почињемо са Линук кернелом и он се спаја са Андроид заједничким језгром уз неколико измена. Одатле, заједничко језгро Андроида се спаја са језгром произвођача (Куалцомм, МедиаТек, итд.) са сопственим модификацијама и променама. Коначно, језгро добављача се спаја са језгром специфичним за ОЕМ уређај. До ове фазе, језгро било ког уређаја је далеко од Линук ЛТС кернела са којим је почело.

Као резултат свих ових форкова, чак 50% кода који се покреће на Андроид уређају је код ван стабла, што значи да није из узводних Линук или АОСП уобичајених кернела. Ово чини невероватно тешким (да не спомињемо дуготрајно и скупо) спајање узводних промена. За ОЕМ произвођаче нема подстицаја да то учине, али та пракса може бити штетна по безбедност уређаја. То је такође разлог зашто је много Андроид уређаја остало на старијим издањима ЛТС кернела, што има нуспојаву да уређаји губе приступ новим функцијама Линук кернела.

Андроид је фрагментиран и Гоогле то зна

Гугл добро зна да је ово проблем, па чак има и одељак под називом „Трошкови фрагментације“ у документацији за Андроид програмере. Гугл то каже „већина водећих уређаја се испоручује са верзијом кернела која је већ стара најмање 18 месеци“. Још горе, Гугл такође то каже „Андроид 10 подржава језгра 3.18, 4.4, 4.9, 4.14 и 4.19, која у неким случајевима нису побољшана новим функцијама од Андроида 8 2017. Ово отежава додавање функција које захтевају нове верзије Линук кернела. Линук кернел 3.18 је лансиран у децембру 2014. године, када је Андроид 5.0 Лоллипоп био најновија верзија Андроид-а. То је очигледно проблем и може да задржи платформу.

На пример, Цоде Аурора Форум, или скраћено ЦАФ, хостује изворни код за различите Куалцомм Снапдрагон СоЦ-ове. Куалцомм, као СоЦ добављач, дистрибуира рачвану верзију Линук кернела ОЕМ/ОДМ-овима, а те компаније затим додају промене специфичне за уређај приликом испоруке уређаја. То је оно што додаје неколико слојева фрагментације. Поред тога, Куалцомм прави промене у АОСП оквиру како би оптимизовао Андроид за сваку од Снапдрагон мобилних платформи компаније. Куалцомм приватно дистрибуира своје модификовано језгро Линука, АОСП оквир и друге софтверске алате својим партнерима као део Пакета подршке за плочу или БСП. ЦАФ је место где Куалцомм јавно објављује ове промене Линук кернела и промене АОСП оквира.

Ово ЦАФ издање може бити корисно за прилагођене РОМ програмере који желе да га користе као почетну тачку, а не као чисти АОСП, због чега понекад видите РОМ-ови „базирани на ЦАФ-у“ на нашим форумима. Сећате се Снапдрагона 625 који је годинама напајао толико паметних телефона средњег ранга? То је покренуто са Линук кернелом 3.18, а тек крајем 2018. (две године након лансирања чипсета) је Куалцомм ажурирао изворе кернела и објавио их на ЦАФ за мсм8953 (назив чипсета за Снапдрагон 625) који доноси подршку за Линук Кернел 4.9. Проблем је што већина ОЕМ-а неће ажурирати телефоне на ову нову верзију Линук кернела, посебно не телефоне средњег ранга две године након што је чип био ослобођени. Додуше, веома је ретко да се такво велико ажурирање кернела уопште деси, али поента је да има догодило, тако да то није само немогућ сценарио.

Све у свему, тренутна фрагментација у Андроиду је, благо речено, хаос. Гоогле-ови најновији покушаји да поправи ту фрагментацију долазе у облику генеричке слике кернела или ГКИ.

Представљамо генеричку слику кернела

Да би решио ову фрагментацију, Гоогле је радио на Андроид Генериц Кернел Имаге-у (ГКИ). Ово је у суштини кернел компајлиран директно из АЦК гране. ГКИ изолује прилагођавања произвођача СоЦ-а и ОЕМ-а за модуле додатака, елиминишући код изван стабла и омогућавајући Гоогле-у да прослеђује ажурирања кернела директно крајњем кориснику. Више од годину дана, Гоогле је радио на начину да испоручи ГКИ ажурирања преко Плаи продавнице, коришћењем главног модула.

Као резултат тога, уређаји који се покрећу са Андроидом 12 који покрећу Линук кернел 5.10.43 или новији морају да ураде једно од следећег: према Мишалу Рахману.

• Поставите слику за покретање коју је потписао Гоогле

ИЛИ

• Поставите слику за покретање са језгром које извози КМИ (Кернел Модуле Интерфаце) који је подскуп КМИ-а који извози ГКИ, извози АПИ корисничког простора који је надскуп УАПИ-ја изложеног од стране ГКИ-а и подржава све карактеристике одговарајућег ГКИ-а верзија

Продавци могу да креирају модуле који се прикључе на ГКИ, али идеја ГКИ-а је да Гоогле преузме терет одговорности за руковање променама кернела. Интерфејс модула језгра (или КМИ, више о томе у каснијим деловима чланка) је заправо тамо где се очекује да иде код ван стабла.

Серија Гоогле Пикел 6 лансирана је са Андроидом 12 из кутије и испоручује се са Линук кернелом 5.10, и то је први телефон који се испоручује са ГКИ. Пошто би Гоогле потенцијално могао да ажурира кернел преко Плаи продавнице, можда ћемо чак видети честа ажурирања кернела, пошто се ажурирања ЛТС кернела обично објављују сваке недеље. У сваком случају, то је много бољи систем од тренутно гломазног метода ажурирања путем ОТА-а, иако то значи да је инхерентно везан за ГМС оквир.

Гоогле једноставно дефинише ГКИ на следећи начин:

• Направљен је од АЦК извора.
• То је бинарни систем са једним језгром и повезани модули који се могу учитати по архитектури, по ЛТС издању (тренутно само арм64 за android11-5.4 и android12-5.4).
• Тестиран је са свим издањима Андроид платформе која су подржана за повезани АЦК. Не постоји застарелост функција током трајања верзије ГКИ кернела
• Он излаже стабилан КМИ возачима унутар датог ЛТС-а.
• Не садржи СоЦ или код специфичан за плочу.

Гоогле чак жели да буде у позицији до 2023. године у којој може да узме модел развоја „прво узводно“. Ово ће помоћи Гоогле-у да обезбеди да нови код прво стигне у главно језгро Линука, смањујући „технички дуг“ нагомиланог кода ван стабла на Андроид уређајима.

Интерфејс модула језгра (КМИ)

Интерфејс модула језгра, или КМИ, део је Гоогле-овог решења за текућу фрагментацију у Андроид-у. У суштини, СоЦ и подршка за плочу више се не налазе у језгру језгра и уместо тога се премештају у модуле који се могу учитати. И кернел и модули могу се ажурирати независно тада, пошто се модули ажурирају у /lib/modules. Сам ГКИ би требало да буде што чистији и генеричнији, што је омогућено преношењем кода који је сада ван стабла у засебне модуле.

Као Тед Кјос објашњено на Овогодишња конференција Линук водоинсталатера, „велики вишегодишњи напор је да се сав хардверски специфичан код извуче из генеричког кернела у модуле добављача. Морамо да имамо стабилан интерфејс између тих модула произвођача и генеричког кернела како би могли да се испоручују асинхроно.“ ГКИ 1.0 је у суштини „тест усаглашености“.

У ствари, ГКИ компатибилност значи да уређај пролази ВТС и ЦТС-он-ГСИ+ГКИ тестове са генеричком сликом система (ГСИ) и ГКИ кернел инсталиран флешовањем слике за покретање ГКИ у партицију за покретање и ГСИ системске слике у систему подела. Вендор Тест Суите, или ВТС, је аутоматизовани тест који сви уређаји морају проћи да би се сматрали компатибилним са Пројецт Требле. Комплет за тестирање компатибилности или ЦТС је неопходан да бисте приступили Гоогле-овом пакету апликација.

Уређаји се могу испоручити са различитим језгром производа и могу користити модуле који се могу учитати које ГКИ не пружа. Међутим, и производ и ГКИ кернели морају да учитавају модуле са истих партиција вендор_боот и вендор. Због тога се од свих језгара производа захтева да имају исти интерфејс бинарног модула кернела (КМИ).

Горњи дијаграм показује шта Гугл жели и објашњава како намерава да то постигне. Генеричко језгро и ГКИ модули ће бити део АОСП-а, а ГКИ може да комуницира са Андроид оквиром и слојем хардверске апстракције (ХАЛ) који продавац може да примени. Специфични власнички код који произвођач жели у кернелу (на пример, драјвери камере) ће уместо тога бити гурнут у модул добављача који постаје проширење ГКИ-а преко КМИ-а.

Како ГКИ може помоћи у решавању проблема фрагментације Андроид-а

Гугл је уложио много посла на рационализацију процеса развоја паметних телефона. Сваки ОЕМ жели свој идентитет бренда, а сваки ОЕМ жели да буде у могућности да има власништво над својим уређајима. За разлику од Андроид Оне програма, Андроид паметни телефони могу бити шта год пожеле, све док се придржавају скупа правила која Гоогле поставља да би добили ГМС лиценцу. Међутим, у прошлости, Гоогле није учинио много да би владао у развоју Андроид уређаја промене као што су Пројецт Требле, Маинлине, а сада и ГКИ су много новије у Андроид-у историје.

Али да ли ће то помоћи? Требало би да буде, мада је вероватно да ће то бити вишегодишња афера која ће донети видљиве плодове касније. Ово ће се односити само на уређаје који се покрећу са Андроидом 12, што значи да ћемо у годинама које долазе видети уређаје који немају ГКИ. То је такође била критика пројекта Требле када је то најављено, иако га очигледно подржавају сви уређаји који су данас лансирани. За ове ствари је потребно време, а како Гоогле полако почиње да влада Андроидом, процес развоја је олакшан за све ОЕМ произвођаче у Андроид екосистем, чак и ако би неки од њих радије задржали потпуну контролу над Линук кернелом који се користи на Андроиду паметних телефона.