У овом чланку истражујемо истину о томе зашто Снапдрагон 801 уређаји не добијају Андроид Ноугат. Од произвођача чипсета до добављача, проблеми су бројни!
Ажурирано да одражава или-или Вулкан или ОпенГЛ ЕС 3.1 захтев за Андроид 7.0
Недавно је написано много чланака о ажурирањима верзија, интеракцији између продавца и произвођача чипсета и шта то значи за уређаје који ће бити у будућности. Зашто је ово порасло ове недеље?
Па, појавило се ове недеље с обзиром на то да поштовани Некус 5 неће добити ажурирање на Андроид 7.0 (Ноугат), а Куалцомм је најавио да неће бити пружа подршку за МСМ8974 (познатији као Снапдрагон 801) на 7.0. Овај чланак је написан као сарадња са КСДА Рецогнизед Девелопер бумбар.
Тема је изазвала прилично интересовање са разних сајтова са вестима, али многи пропуштају суптилне нијансе онога што се заиста дешава иза сценес. Овај чланак ће објаснити нешто више о томе како функционишу ажурирања софтвера, користећи наше искуство у раду са ОЕМ произвођачима на њиховим званичним ажурирањима фирмвера. Провешћемо вас кроз шта се дешава иза кулиса (и зашто) и зашто можда нећете добити најновији софтвер на свом телефону.
Први корак у животу ажурирања Андроид фирмвера је упстреам ажурирање. То је оно на чему Гоогле интерно ради. За разлику од „отворених токова посла“, Андроид је развијен коришћењем затвореног тока посла, са изворним кодом који се баца на зид сваке године или тако, када изађе ново издање. Првобитно, Гоогле је рекао да је ово било да спречи фрагментацију људи који користе најсавременије верзије док су се ствари брзо развијале у раним данима, али изгледа да су ову политику задржали унутра место.
У неком тренутку, обично пре јавног објављивања ажурирања (иако се са недавним увођењем јавних бета верзија, ови временски оквири померају), ОЕМ произвођачи ће бити обавештени о предстојећем ажурирању. Затим ће добити изворни код у другом тренутку за коначно ажурирање (у прошлости је то било понекад мало пре лансирања, мада смо такође свесни случајева где нема раног издање).
Упстреам АОСП спремишта садрже подршку за уређаје само за ограничен број уређаја. То су обично ваши Некус уређаји. Међутим, из разлога који ће ускоро постати јасни, значајно је напоменути да Гоогле нема потпуну контролу хардвера над овим уређајима; уређаје производи ОЕМ, а тај ОЕМ ће купити систем на чипу (СоЦ) од произвођача чипсета.
Када се објави изворни код, ОЕМ фирмвер тим ће (фигуративно) седети и подићи ноге. Главно стабло Андроида нема хардверску подршку за безброј скупова чипова који се користе у уређајима за испоруку. Ваш Куалцомм чипсет највероватније није подржан у АОСП-у, на пример. Ваш Екинос дефинитивно није. Медиатек или ХиСилицон? Заборави!
БСП садржи драјвере и слојеве хардверске апстракције (ХАЛ-ове) потребне за покретање Андроид-а
Оно што је сада потребно је а Пакет подршке одбору (БСП). Ово је супер-поверљиви пакет власничких компоненти, које произвођач чипсета испоручује ОЕМ-у. БСП садржи неопходан изворни код који омогућава произвођачима оригиналне опреме да направе Андроид и неопходне драјвере за своје уређаје.
Овде је вредно напоменути да произвођачи оригиналне опреме као што је Куалцомм не верују нужно у потпуности својим ОЕМ партнерима – БСП је доступан на основу „потребе да се зна“. Произвођачи оригиналне опреме обично не добијају приступ изворном коду за неке од супер-тајних делова уређаја (као што је софтвер који ради на основном опсегу). Затварање овог дела сигурно такође има потенцијалне проблеме, што показује ближа обилно и понављајући АСН.1 анализирање рањивости.
БСП садржи драјвере и слојеве хардверске апстракције (ХАЛ-ове) потребне да би Андроид радио на вашем уређају. АОСП садржи скуп ХАЛ-ова, који делују као дефиниције онога што оперативни систем очекује да ваши драјвери имплементирају. Да користимо смешно превише поједностављен (и измишљен, у сврху демонстрације) пример, замислимо батеријску лампу на вашем телефону.
Пример ХАЛ - Ваша лампа
Замислимо да ваш уређај има батеријску лампу на задњој страни (ако имате Некус 7 2013, мораћете мало више да замишљате него сви остали – извините!). Ово контролише возач. За наш лудо једноставан пример, претпоставимо да в1 ХАЛ каже да треба да имате једну функцију која се зове "сетЛЕД" која узима један параметар, стање светлости. То је боолеан - тачно или нетачно. У Ц-у би ово изгледало отприлике овако:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Ова функција је дефинисана у БСП изворном коду. БСП затим компајлира ОЕМ током прављења РОМ-а, и он постаје једна од власничких „.со“ библиотека на партицији или области добављача вашег уређаја. Ово омогућава ОЕМ-у да чува одређене делове рада свог уређаја у тајности. За сада, претпоставимо да желе да спрече све да виде како укључују и гасе ту ЛЕД лампицу.
Сада замислите да Гоогле издаје ажурирану верзију својих ХАЛ-ова у будућој верзији Андроид-а. Они сада одлучују да би било лепо да вам дозволе да ажурирате осветљеност свог ЛЕД-а, уместо да га само укључите или искључите. Можда је ово за адаптивни флеш, или је можда само за принудно ажурирање ХАЛ-а и одржавање произвођача чипсета у послу? Дозволићемо вама, читаоцу, да изнесете своје мишљење о томе. Нека ажурирања ХАЛ-а имају јасну корист (као што је нова камера ХАЛ која излаже необрађено снимање и слично), док су друге нешто мање јасне у сврху.
Са овим новим (измишљеним) ХАЛ-ом за осветљеност, претпоставимо да Гугл каже да морате поново да изложите функцију која се зове сетЛЕД, али овог пута са целим бројем предатим за осветљеност. Сада, 0 би га искључио, а 255 би га укључио у потпуности.
Ако сте произвођач оригиналне опреме, можете узети свој супер-тајни код да укључите ту ЛЕД диоду и ставите је у ову нову функцију. Можете чак користити модулацију ширине импулса да бисте подесили осветљеност ЛЕД-а на основу броја. Сада мењате функцију да изгледа овако:
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
Па шта? Па, сада је ова нова верзија Андроид-а некомпатибилна са постојећим „блобовима“. Ваш ОЕМ треба да користи ове нове мрље, јер Андроид ОС очекује да види нову дефиницију функције и неће „пронаћи“ стару када буде тражио начин да подеси ЛЕД.
У овом тренутку, хајде да направимо кратку паузу да погледамо како овде управљају прилагођени РОМ-ови (направљени из извора). То је оно што ће проницљиви међу вама тренутно викнути на ваш екран - на крају крајева, ми смо КСДА, дом ХТЦ ХД2, најдуготрајнији телефон на свету... (само да се зна, луди генијалци тамо трче Андроид 6.0 на ХД2 ових дана! Није лоше за телефон који је првобитно испоручен са Виндовс Мобиле 6.5 2009.)
Овде се користе различити приступи – понекад програмери хакују око РОМ-а и кажу ОС-у да користи старе дефиниције функција. То је мало неуредно и чини много промена за одржавање. Други приступ је „подметање“ ОЕМ бинарних података.
Приступ „шим“ је да сами напишете и направите малу нову библиотеку, која садржи очекивану дефиницију функције – за наш пример, ми бисмо подржали цео број за осветљеност. Затим, унутар подлошка, ово се преводи да испуни захтеве старог ХАЛ-а. Дакле, за наш пример, можда бисмо рекли да ће било која осветљеност захтевана изнад 128 укључити ЛЕД, а све испод тога би га искључило. Или можете рећи да ће се укључити било шта што није нула. То зависи од програмера. Они компајлирају схим и натерају Андроид да га користи уместо матичног. Подложак затим позива ОЕМ блоб.
Брзо `адб пусх` и поновно покретање требало би да покрене схим и омогући вам да контролишете свој измишљени ЛЕД, иако имате само стари ХАЛ.
Проблем је што је ово очигледно несавршен процес. Сада ћете имати неке недоумице - овај уређај ће имати прилично лош блиц, који је или потпуно укључен или потпуно искључен. То није идеално – ОС мисли да ствара веома нежно светло, али стварном ЛЕД-у је речено да се такмичи у такмичењу за вештачко сунце и покушава да вас заслепи. Али хеј, живот није савршен, а сада имате ЛЕД диода на старом телефону!
(Да, ово је један од разлога зашто постоје недостаци и грешке када КСДА корисници и програмери управљају својим лудим и сулудим подвизима у преношењу. Мислим дођавола, Галаки С ИИ је тотинг наизглед употребљив Андроид 6.0 РОМ сада. Многи телефони објављени прошле године још увек немају 6.0!)
Вратимо се на перспективу ОЕМ-а. Нажалост, већина ОЕМ-а већ ради најмање 1 телефон испред онога што смо тренутно. Њихов фокус је на следећем телефону који ће продати – не можете их кривити, јер зарађују само на уређајима које продају. Они не зарађују новац од уређаја које су продали пре годину или две, па морају да наставе да издају нове уређаје да би постојали. Ово је један од разлога зашто су ХТЦ и Блацкберри у невољи – није важно колико руководилаца задржава своју стару Блацкберри Цурве, јер тамо не добијају продају нових уређаја.
Ако ОЕМ не добије БСП, неће се спустити на КСДА приступ хаковања буилд-а. Зашто? Добро, они морају да подрже овај фирмвер за своје клијенте. Ако пусте фирмвер који је напола функционалан, корисници ће их мрзети, збијати и бунцати, а њихове линије подршке ће звонити данима.
ОЕМ произвођачи такође морају да се боре са превозницима, барем на неевропским тржиштима. Превозници не желе да купци имају проблема са ажурирањима софтвера. У ствари, оператери често радије не издају ажурирања софтвера.
Да бисте ово разумели, замислите своју тетку Алису. Она је та која те зове у незгодно доба дана да тражи помоћ око "оне компјутерске ствари". Затим описујете како да кликнете на "Старт мени" и морате да га идентификујете као "велику заставу у доњем левом углу", и наиђете на забуну. Отприлике 45 минута (и много фрустрације) касније, испада да је тетка Алис повукла свој старт мени на десну ивицу екрана и једноставно је морала да га повуче назад. Да, са левим тастером миша!
Сада замислите да имате хиљаду тетке Алице. Сви они зову вашу корисничку подршку, не могу да пронађу Цанди Црусх на свом телефону, забринути да га је хакер избрисао са њиховог телефона. Ох, и иконе сада изгледају мало другачије - можда је хакер још увек у свом телефону?
Да, ово би требало да буде мало лакомисленог хумора, али док не искусите разлоге због којих ће људи позвати свог оператера за подршку, нећете веровати у проблеме које имају. Ажурирање софтвера које мења начин на који телефон ради, или где се ствари налазе, проузроковаће значајне трошкове подршке. У најмању руку, то захтева поновну обуку особља за подршку (јер већина њих, нажалост, није ваш страствени КСДА читач).
Када ОЕМ добије БСП, он ће пренети свој РОМ и применити све своје промене на РОМ. Они ће нагомилати своје производе и додати ужасну кожу налик цртаном која би изгледала као код куће у тинејџерским анимеима. Онда ће то тестирати.
Много.
Постоје разни захтеви које ваш телефон мора да испуни. Мобилне мреже су дизајниране да верују да ће се корисничка опрема (оно што ми зовемо телефоном) исправно понашати. То значи да је потребно много тестирања да би се уређај одобрио. Ажурирања софтвера ризикују да промене понашање, тако да ствари треба поново тестирати. Због тога ћете обично видети информације о предстојећим ажурирањима софтвера компаније Сони од екстерних услуга тестирања, које потврђују да је фирмвер усклађен са захтевима тестирања.
Сада... шта се дешава након ажурирања или два (или у неким случајевима, ниједна)? Произвођач СоЦ-а неће дати ОЕМ-у ажурирани БСП. На крају крајева, произвођач СоЦ-а неће добити много од овога. ОЕМ не зарађује више на вашем телефону откако је продат. И у овом тренутку, ваш телефон не добија више значајних ажурирања верзије.
Смањење броја БСП-а које ОЕМ жели да испоручи је одличан начин да уштедите новац - ако вам је потребна само тренутна, а не намеравате да испоручите ниједну већу верзију повећава, ово ће уштедети новац на почетној куповини и лиценцирању СоЦ-а, али на рачун неколико љутих штребера на КСДА у наставку, који се питају зашто нису добили ажурирање.
Ажурирања су сложена. У ланцу је укључено много различитих људи. Ништа од овога не оправдава произвођаче оригиналне опреме за тренутно недовољно и патетично стање ажурирања на Андроид-у. Ипак, овде постоје прави изазови.
Многи ОЕМ произвођачи су криви за превише обећавајуће, и неизбежна недовољна испорука коју сада повезујемо. Тужна стварност је да су за већину ОЕМ-а ажурирања софтвера само сметња без које би могли.
Мобилни сектор је углавном заглављен у начину размишљања телефона са функцијама. То јест, где уређај никада не добија ажурирања. Тестирајте га једном, пошаљите и никад се не осврћите. Са безбедносним проблемима модерних паметних телефона и чистом сложеношћу покретања оперативног система пуне опште намене, са стотинама спољних библиотека, то више није опција. Или барем то не би требало бити. Гоогле је направио неке кораке ка поправљању овога, тако што је барем објавио безбедносне билтене и закрпе за постојећа издања Андроид-а (запамтите да је до недавно једини начин за добијање безбедносних ажурирања био преко нове главне верзије Андроид ОС-а!)
Нажалост, ово заправо није довољно. Иако Гоогле наставља да објављује ажурирања, безбедност вашег уређаја и даље зависи од произвођача СоЦ-а - пошто су произвођачи СоЦ-а толико окамењени неко открива како упали неколико ЛЕД диода или испушта звук преко звучника, шаље огромне количине бинарних мрља на своје уређаја. Ове мрље садрже неки прилично ужасно несигуран код (само погледајте претходне Гоогле безбедносне билтене ако мислите да је ово претеривање!), и треба их ажурирати. Што значи да су потребни ажурирани БСП-ови.
Стони рачунари (и даље, лаптопови) се по архитектури потпуно разликују од мобилних уређаја. Ваш мобилни телефон или таблет је заправо веома власничка груда силикона, коју су у журби дизајнирали неки људи који мисле добро, али немају ни приближно довољно времена да направе нешто добро. Тржиште се креће тако брзо да су једва у стању да држе корак са темпом којим маркетинг захтева лансирање нових производа.
То значи да се користе пречице – нећете пронаћи ваш телефон подржан од стране главног Линук кернела, а видећете да сваки телефон има другачији начин за покретање. Међутим, на вашем лаптопу или десктопу, продавци су се определили за неке стандардне начине покретања – раније је то био МБР (мастер боот рецорд) са БИОС-ом, а сада је то УЕФИ. Ова стандардизација омогућава покретање истог софтвера на сваком уређају.
Иако је недавно учињено неколико корака ка овоме, посебно са Сонијевим програмом ширења и њиховим унифиед кернел, није практично покретати главно језгро на већини телефона, због огромног броја нових хакова специфичних за добављаче који су уведени на сваки уређај.
Повезали сте прикључак за слушалице на погрешан начин? Само га хакирајте у драјвере! Нема времена да се то поправи у производном дизајну.
Производни тим је монтирао модул камере наопако у производној серији 1? Убаците хакирање да проверите интерни код верзије и окрените видео ако је верзија 1!
Овакви хакови решавају тренутни проблем, али само састружу површину чудних промена специфичних за производ. Дођавола, чак понекад постоје потпуно различити чипови у различитим ревизијама истог телефона, због комерцијалних одлука. Ово доводи до хаковања драјвера и чудних одлука које су имале смисла само у то време, да би телефон радио како би могао да буде испоручен следеће недеље.
Иако је у току рад на главној подршци за 64-битне АРМ чипове за покретање користећи УЕФИ, до сада је било нема јасног кретања ка стандардизованијем начину покретања АРМ уређаја. И то је тужно, јер то значи да ће телефони и даље бити избачени много пре краја њиховог радног века, јер је једноставно прескупо одржавати технички дуг и терет за њих софтвер.
С друге стране, међутим, ако ће ОЕМ зарађивати само на продаји уређаја, зар не морају да обезбеде да људи наставе да купују нове телефоне? Да ли би се тржиште рачунара преселило на овај модел да није било 30 година замаха и застарелог софтвера који већ користи отворену ПЦ платформу и стандард?
Ово је тешко питање без унутрашњег знања компаније Куалцомм, што нажалост тренутно немамо. Међутим, неке информације можемо извући из 7.0 Андроид драјвера АПИ и ЦТС захтева. ЦТС захтеви одређују шта Гоогле очекује од уређаја који користи дати фирмвер. „Велики чекић“ који се користи за спровођење ових захтева је Гоогле-ово лиценцирање за коришћење њиховог власничког пакета Гоогле Плаи услуга – ако се не придржавате, не можете да испоручујете Гоогле Аппс на уређају. Док, за неке, ово може се посматрати као предност, то очигледно није оно што корисници желе и очекују од уређаја.
Андроид 7.0 није много додао изменама у ХАЛ-у или драјверима (као што је горе описано), тако да је мало вероватно да ће било каква некомпатибилност доћи одатле. Међутим, вероватније је да ће представљати проблем увођење а нови захтев за Вулкан графички АПИ или ГЛЕС 3.1, бити доступан како би положио ЦТС.
Тренутно, многи системи на чипу (СоЦ) немају Вулкан подршку на свом графичком процесору, укључујући МСМ8974. Ово је такође највероватније где ће се појавити питање компатибилности са Андроидом 7.0. Опет, без унутрашњег знања компаније Куалцомм и њихових будућих планова, тешко нам је дати коначну изјаву без квалификације. У овом тренутку, међутим, верујемо да је вероватно да је ово „једноставан“ случај када је Куалцомм прекинуо подршку за (у њиховим очима) застарели МСМ8974 чипсет, а не пружа БСП (пакет подршке за плочу) за 7.0 на тој платформи. Да је то случај, то би значило да ОЕМ-ови готово сигурно неће испоручити 7.0 на уређају - морали би некако да пронађу Вулкан или ГЛЕс 3.1 подршку за свој ГПУ и ГПУ извор код је један од смешно строго чуваних делова мобилних стекова (без правог разлога, додали бисмо - погледајте АМД, отворено проналажење сопственог АМДГПУ драјвера на десктопу за Линук). Нажалост, међутим, Вулкан и убрзана (ГЛЕС) графика генерално су мало сложенији од једноставне ЛЕД диоде, тако да ово није нешто за шта ћемо видети подставке за увођење компатибилности.
Како 7.0 није дуго изашао, постоји реална могућност да други скупови чипова (осим малог броја у самом АОСП-у) остану заостаје за 6.0, било због проблема са хардвером и драјверима (тј. нема ажурираног БСП-а) или због недостатка подршке добављача СоЦ-а у вези са Вулканом или ГЛЕС 3.1 АПИ. Тренутно, ни Снапдрагон 800 ни 801 не подржавају једно од ових.
Најбоље је гледати овај простор - програмери на КСДА већ добро напредују са незваничним портовима на 7.0 за многе уређаје који не добијају званичну подршку за 7.0 од Гоогле-а. Међутим, они су без подршке за Вулкан или ГЛЕС 3.1 - можда ће програмери игара на Андроиду почети да доживите фрустрацију кроз фрагментацију ако довољно корисника почне да покреће прилагођене РОМ-ове без Вулкана или ГЛЕС 3.1 подршка?
Аппле има тенденцију да подржава своју линију иПхоне-а на најновијој верзији иОС-а око 5 година – иПхоне 4с је лансиран у октобру 2011. године и одржава се ажурираним до иОС 9. Међутим, неће добити предстојеће ажурирање за иОС 10, што би телефону дало ефективни животни век од 5 година, под претпоставком да иОС 10 буде лансиран око октобра. Вреди напоменути да Аппле не подржава увек подршку за графички АПИ за повратак – иПхоне 4с и иПхоне 5 немају садржи Аппле-ов Метал грапхицс АПИ, који је донекле сличан сценарио оном који се види са Андроид-ом Вулкан. Једина разлика је у томе што је Аппле наставио да подржава старије уређаје без новог графичког АПИ-ја.
Шта мислиш? Да ли ћете флешовати прилагођени РОМ на свом телефону да бисте продужили његов животни век? Да ли сте рекли у коментарима испод.