Задълбочена капитулация защо устройствата SD801 са изключени от Nougat

Актуализиран, за да отрази или-или изискването Vulkan или OpenGL ES 3.1 за Android 7.0

Напоследък има много статии, написани за актуализации на версиите, взаимодействията между доставчика и производителя на чипсет и какво означава това за бъдещите устройства. Защо това се повиши тази седмица?

Е, тази седмица стана ясно, че почтеният Nexus 5 няма да получи актуализацията до Android 7.0 (Nougat) и Qualcomm обяви, че няма да бъде осигуряване на поддръжка за MSM8974 (по-известен като Snapdragon 801) на 7.0. Тази статия е написана в сътрудничество с XDA Recognized Разработчик земна пчела.

Темата привлече доста интерес от различни новинарски сайтове, но мнозина пропускат фините нюанси на това, което наистина се случва зад сценатас. Тази статия ще обясни малко повече за това как работят софтуерните актуализации, използвайки нашия опит в работата с OEM производители по техните официални актуализации на фърмуера. Ще ви преведем през какво се случва зад кулисите (и защо) и защо може да не получите най-новия софтуер на телефона си.

Първата стъпка в живота на актуализацията на фърмуера на Android е актуализацията нагоре. Това е, върху което Google работи вътрешно. За разлика от „отворените работни потоци“, Android се разработва чрез затворен работен процес, като изходният код се прехвърля през стената всяка година или така, когато излезе нова версия. Първоначално Google каза, че това е за предотвратяване на фрагментация от хора, които използват най-модерни версии докато нещата се развиваха бързо в ранните дни, но те изглежда са запазили тази политика място.

В даден момент от време, обикновено преди публичното обявяване на актуализация (въпреки че с неотдавнашното въвеждане на публични бета версии, тези срокове се изместват), OEM производителите ще бъдат уведомени за предстояща актуализация. След това те ще получат изходния код във втори момент за окончателната актуализация (в миналото беше понякога малко преди старта, въпреки че сме запознати и със случаи, в които няма ранен старт освобождаване).

Хранилищата на AOSP нагоре по веригата съдържат поддръжка на устройства само за ограничен брой устройства. Това обикновено са вашите устройства Nexus. Поради причини, които ще станат ясни скоро обаче, важно е да се отбележи, че Google няма пълен хардуерен контрол върху тези устройства; устройствата се произвеждат от OEM и този OEM ще закупи System-on-Chip (SoC) от производител на чипсет.

След като изходният код бъде пуснат, екипът на фърмуера на OEM (фигуративно) ще се отпусне и ще вдигне краката си. Основното изходно дърво на Android няма хардуерна поддръжка за безбройните чипсети, използвани в устройствата за доставка. Вашият чипсет Qualcomm най-вероятно не се поддържа от AOSP, например. Вашият Exynos определено не е такъв. Mediatek или HiSilicon? Забрави!

BSP съдържа драйверите и хардуерните абстракционни слоеве (HAL), необходими за стартиране на Android

Това, което е необходимо сега, е a Пакет за поддръжка на борда (BSP). Това е супер поверителен пакет от патентовани компоненти, доставен от производител на чипсет на OEM. BSP съдържа необходимия изходен код, за да позволи на OEM производителите да изградят Android и необходимите драйвери за тяхното устройство.

Тук си струва да се отбележи, че OEM производители като Qualcomm не се доверяват непременно напълно на своите OEM партньори - BSP се предоставя на базата на „необходимост да се знае“. Производителите на оригинално оборудване обикновено не получават достъп до изходния код за някои от суперсекретните части на устройството (като софтуера, работещ на основната лента). Затварянето на тази част със сигурност също има потенциални проблеми, както се вижда от близо обилно и повтарящи се ASN.1 анализиране на уязвимости.

BSP съдържа драйверите и хардуерните абстракционни слоеве (HAL), необходими за стартиране на Android на вашето устройство. AOSP съдържа набор от HAL, които действат като дефиниции за това какво операционната система очаква да внедри вашите драйвери. За да използваме абсурдно прекалено опростен (и измислен с цел демонстрация) пример, нека си представим фенерчето на телефона ви.

Примерен HAL - Вашето фенерче

Нека си представим, че вашето устройство има фенерче на гърба (ако имате Nexus 7 2013, ще трябва да си представите малко повече от всички останали – съжалявам!). Това се управлява от водач. За нашия безумно прост пример, нека предположим, че v1 HAL казва, че трябва да имате една функция, наречена "setLED", приемаща един параметър, състоянието на светлината. Това е булево - вярно или невярно. В C това би изглеждало по следния начин:

void setLED(bool ledState) {

// here is the actual code to turn on or off the LED, based on ledState

}

Тази функция е дефинирана в изходния код на BSP. След това BSP се компилира от OEM по време на изграждането на ROM и това става една от частните библиотеки ".so" в дяла на доставчика или областта на вашето устройство. Това позволява на OEM да пази определени части от работата на своето устройство в тайна. Засега да приемем, че искат да спрат всички да виждат как включват и изключват този светодиод.

Сега си представете, че Google пуска актуализирана версия на своите HAL в бъдеща версия на Android. Сега те решават, че би било хубаво да ви позволят да актуализирате яркостта на вашия светодиод, вместо просто да го включвате или изключвате. Може би това е за адаптивна светкавица или може би е просто за принудително актуализиране на HAL и поддържане на производителите на чипсети в бизнеса? Ще позволим на вас, читателю, да достигнете до собственото си мнение по този въпрос. Някои актуализации на HAL имат очевидна полза (като новия HAL на камерата, излагащ необработено заснемане и подобни), докато други са малко по-малко ясни по предназначение.

С този нов (измислен) HAL за яркост, да предположим, че Google казва, че трябва да изложите отново функция, наречена setLED, но този път с цяло число, предадено за яркост. Сега 0 ще го изключи, а 255 ще го включи напълно.

Ако сте OEM, можете да вземете вашия супер таен код, за да включите този светодиод, и да го поставите в тази нова функция. Можете дори да използвате широчинно-импулсна модулация, за да регулирате яркостта на светодиода въз основа на числото. Променяте функцията да изглежда така сега:

void setLED(uint8_t ledBrightness) {

// some super-secret and ultra-confidential proprietary way to set LED brightness

}

Какво от това? Е, сега тази нова версия на Android е несъвместима със съществуващите „петна“. Вашият OEM трябва да използва тези нови петна, защото Android OS очаква да види новата дефиниция на функцията и няма да „намери“ старата, когато търси начин да настрои светодиода.

На този етап нека да направим кратка пауза, за да разгледаме как персонализираните ROM (създадени от източник) се справят тук. Това е, което проницателните сред вас ще викат на екрана ви в момента - все пак ние сме XDA, домът на HTC HD2, най-дълготрайният телефон в света... (само за протокола, лудите гении там бягат Android 6.0 на HD2 тези дни! Не е лошо за телефон, първоначално доставен с Windows Mobile 6.5 през 2009 г.)

Тук има различни подходи - понякога разработчиците хакват в ROM и казват на операционната система да използва старите дефиниции на функции. Това е малко объркващо и изисква много промени за поддържане. Другият подход е да се "измени" двоичният файл на OEM.

Подходът "shim" е да напишете и изградите сами малка нова библиотека, която съдържа очакваната дефиниция на функция - за нашия пример, ние бихме подкрепили цялото число за яркост. След това, в подложката, това се превежда, за да отговаря на изискванията на стария HAL. Така че за нашия пример може би бихме казали, че всяка поискана яркост над 128 ще включи светодиода, а всичко под това ще го изключи. Или можете да кажете, че всичко различно от нула ще го включи. Това зависи от разработчика. Те компилират шима и карат Android да го използва вместо родния. След това подложката извиква OEM blob.

Едно бързо `adb push` и рестартиране би трябвало да задейства подложката и да ви позволи да управлявате своя измислен светодиод, въпреки че имате само стария HAL.

Проблемът е, че това очевидно е несъвършен процес. Сега ще получите странности - това устройство ще има доста гадна светкавица, която е или напълно включена, или напълно изключена. Това не е идеално - операционната система смята, че прави много нежна светлина, но на действителния светодиод се казва, че се състезава в състезание за изкуствено слънце и се опитва да ви заслепи. Но хей, животът не е перфектен и вече имате работещ светодиод на стария си телефон!

(Да, това е една от причините, поради които има странности и грешки, когато потребителите и разработчиците на XDA управляват своите луди и безумни подвизи на пренасяне. Искам да кажа, по дяволите, Galaxy S II е привидно използваем Android 6.0 ROM вече. Много телефони, пуснати миналата година, все още нямат 6.0!)

Нека се върнем към гледната точка на OEM. За съжаление, повечето производители на оригинално оборудване вече работят с поне 1 телефон по-напред от момента, в който сме ние в момента. Фокусът им е върху следващия телефон, който ще продадат - не можете да ги вините наистина, тъй като те правят пари само от устройства, които продават. Те не правят пари от устройства, които са продали преди година или две, така че трябва да продължат да пускат нови устройства, за да съществуват. Това е една от причините HTC и Blackberry да имат проблеми - няма значение колко ръководители са запазили здрава хватка върху стария си Blackberry Curve, тъй като там не се продават нови устройства.

Ако OEM не получи BSP, те няма да се придържат към XDA подхода на хакване заедно на компилация. Защо? Добре, те трябва да поддържат този фърмуер за своите клиенти. Ако пуснат фърмуер, който е наполовина работещ, потребителите ще ги мразят, ще злословят и ще се възмущават, а линиите им за поддръжка ще звънят с дни.

OEM производителите също трябва да се борят с превозвачите, поне на неевропейските пазари. Превозвачите не искат клиентите да имат проблеми с актуализациите на софтуера. Всъщност операторите често предпочитат да не пускат софтуерни актуализации.

За да разберете това, представете си пралеля Алис. Тя е тази, която ви се обажда по телефона в неудобно време на деня, за да ви помоли за помощ с „онова компютърно нещо“. След това описвате как да щракнете върху "менюто "Старт" и трябва да го идентифицирате като "голямото знаме в долния ляв ъгъл" и сте посрещнати с объркване. Около 45 минути (и много разочарование) по-късно се оказва, че леля Алис е плъзнала стартовото си меню до десния край на екрана и просто е трябвало да го плъзне обратно. Да, с левия бутон на мишката!

Сега си представете, че имате хиляда леля Алис. Всички се обаждат на отдела за поддръжка на клиентите ви, не могат да намерят Candy Crush на телефона си и се притесняват, че хакер го е изтрил от телефона им. О, и иконите изглеждат малко по-различно сега - може би хакерът все още е в телефона им?

Да, това е предназначено да бъде малко безгрижен хумор, но докато не изпитате причините, поради които хората ще се обадят на своя оператор за поддръжка, няма да повярвате какви проблеми имат. Софтуерна актуализация, която променя начина, по който работи телефонът или къде са нещата, ще доведе до значителни разходи за поддръжка. Най-малкото изисква повторно обучение на обслужващия персонал (тъй като повечето от тях не са вашите запалени читатели на XDA, за съжаление).

След като OEM получи BSP, те ще пренесат своя ROM и ще приложат всичките си промени към ROM. Те ще натрупат своя bloatware и ще добавят ужасяваща анимационна кожа, която би изглеждала по-удобно в аниме за тийнейджъри. След това ще го тестват.

Много.

Има всякакви изисквания, на които телефонът ви трябва да отговаря. Мобилните мрежи са проектирани да се доверяват на потребителското оборудване (това, което наричаме телефон) да се държи правилно. Това означава, че са необходими много тестове, за да бъде одобрено устройството. Софтуерните актуализации рискуват да променят поведението, така че нещата трябва да бъдат тествани отново. Ето защо често ще виждате информация за предстоящи софтуерни актуализации на Sony от външни услуги за тестване, които потвърждават, че фърмуерът е съвместим с изискванията за тестване.

Сега... какво се случва след актуализация или две (или в някои случаи нито една)? Производителят на SoC няма да даде на OEM актуализиран BSP. В крайна сметка, производителят на SoC няма да получи много от това. Производителят на оригинално оборудване не прави повече пари от вашия телефон, откакто беше продаден. И в този момент телефонът ви не получава повече актуализации на основни версии.

Намаляването на броя BSP, които OEM иска да бъдат доставени, е чудесен начин да спестите пари - ако имате нужда само от текущия и не възнамерявате да доставяте основна версия увеличава, това ще спести пари за първоначалната покупка и лицензиране на SoC, но за сметка на няколко ядосани маниаци на XDA надолу по линията, чудейки се защо не са получили актуализация.

Актуализациите са сложни. Във веригата участват много различни хора. Нищо от това не извинява производителите на оригинално оборудване за текущото небрежно и жалко състояние на актуализациите на Android. Въпреки това тук има някои реални предизвикателства.

Много производители на оригинално оборудване са виновни за прекаленото обещание и неизбежно недостатъчно представяне, което сега свързваме. Тъжната реалност е, че за повечето производители на оригинално оборудване актуализациите на софтуера са само досада, без която могат да минат.

Мобилният сектор е заседнал най-вече в мисленето на функционалните телефони. Това означава, че устройството никога не получава никакви актуализации. Тествайте го веднъж, изпратете го и никога не поглеждайте назад. С проблемите със сигурността на съвременните смартфони и пълната сложност на работата на пълна операционна система с общо предназначение, със стотици външни библиотеки, това вече не е опция. Или поне то не трябва бъда. Google направи някои стъпки за коригиране на това, като поне публикува бюлетини за сигурността и корекции за съществуващи версии на Android (не забравяйте, че доскоро единственият начин да получите актуализации за защита беше чрез нова основна версия на Android OS!)

Уви обаче, това всъщност не е достатъчно. Въпреки че Google продължава да пуска актуализации, сигурността на вашето устройство все още зависи от производителя на SoC - тъй като производителите на SoC са толкова вкаменени от някой, който открие как включва няколко светодиода или издава звук през високоговорител, изпраща огромни количества двоични петна на устройства. Тези петна съдържат някакъв доста ужасяващо несигурен код (просто погледнете миналите бюлетини за сигурност на Google, ако смятате, че това е преувеличение!) и се нуждаят от актуализиране. Което означава, че са необходими актуализирани BSP.

Настолните компютри (и като разширение лаптопите) са напълно различни по архитектура от мобилните устройства. Вашият мобилен телефон или таблет всъщност е силно патентована буца силиций, проектирана в бързината от някои хора, които имат добри намерения, но нямат достатъчно време, за да направят нещо добро. Пазарът се движи толкова бързо, че те едва успяват да се справят с темпото, с което маркетингът изисква пускането на нови продукти.

Това означава, че се използват преки пътища - няма да откриете, че вашият телефон се поддържа от основното Linux ядро ​​и ще откриете, че всеки телефон има различен начин за зареждане. На вашия лаптоп или настолен компютър обаче доставчиците се спряха на някои стандартни начини за зареждане - преди това беше MBR (главен запис за зареждане) с BIOS, а сега е UEFI. Тази стандартизация прави възможно стартирането на един и същ софтуер на всяко устройство.

Въпреки че напоследък имаше някои стъпки към това, особено с програмата за популяризиране на Sony и тяхната унифицирано ядро, не е практично да се изпълнява основно ядро ​​на повечето телефони, поради големия брой нови хакове, специфични за доставчика, въведени на всяко устройство.

Свързахте жака за слушалки по грешен начин? Просто го хакнете в драйверите! Няма време да го коригираме в производствения дизайн.

Производственият екип монтира ли модула на камерата с главата надолу в производствена партида 1? Хвърлете хак, за да проверите вътрешния код на версията и обърнете видеоклипа, ако е версия 1!

Хакове като тези решават непосредствения проблем, но само остъргват повърхността на случващите се странни и специфични за продукта промени. По дяволите, дори понякога има напълно различни чипове в различни ревизии на един и същ телефон, поради търговски решения. Това води до хакове в драйвери и странни решения, които са имали смисъл само по това време, за да накарат телефона да работи, за да може да бъде доставен следващата седмица.

Макар да се работи по основна поддръжка за 64-битови ARM чипове за зареждане с помощта на UEFI, досега има няма ясно движение към по-стандартизиран начин за зареждане на ARM устройства. И това е тъжно, защото означава, че телефоните ще продължат да бъдат изхвърляни много преди края на техния срок работен живот, защото просто е твърде скъпо да поддържат техническия дълг и тежест върху тях софтуер.

От друга страна обаче, ако OEM ще печели пари само от продажба на устройство, не трябва ли да гарантира, че хората ще продължат да купуват нови телефони? Щеше ли пазарът на персонални компютри да се насочи към този модел, ако вече нямаше 30 години инерция и наследен софтуер, използващ отворената платформа и стандарт за компютър?

Това е труден въпрос без вътрешни познания от Qualcomm, които за съжаление не разполагаме в момента. Въпреки това можем да извлечем малко информация от API на драйвера за Android 7.0 и изискванията на CTS. Изискванията на CTS уточняват какво Google очаква от устройство, работещо с даден фърмуер. „Големият чук“, използван за налагане на тези изисквания, е лицензирането на Google за използване на техния собствен пакет услуги за Google Play – ако не ги спазвате, не можете да изпратите Google Apps на устройството. Докато за някои това може да се разглежда като предимство, това очевидно не е това, което потребителите искат и очакват от едно устройство.

Android 7.0 не е добавил много чрез промени в HAL или драйвери (както е описано по-горе), така че всяка несъвместимост е малко вероятно да идва конкретно от там. Това, което обаче е по-вероятно да създаде проблем, е въвеждането на a ново изискване или за графичния API на Vulkan, или за GLES 3.1, да бъде на разположение, за да премине CTS.

В момента много системи върху чип (SoC) нямат поддръжка на Vulkan на своя графичен процесор, включително MSM8974. Тук най-вероятно ще възникне и проблемът със съвместимостта с Android 7.0. Отново обаче, без вътрешна информация от Qualcomm и техните бъдещи планове, за нас е трудно да дадем окончателно изявление, без да го квалифицираме. В момента обаче смятаме, че е вероятно това да е „простият“ случай на прекратяване на поддръжката на Qualcomm за (в техните очи) застаряващ чипсет MSM8974 и липса на BSP (пакет за поддръжка на платка) за 7.0 на тази платформа. Ако случаят беше такъв, това би означавало, че производителите на оригинално оборудване почти сигурно няма да доставят 7.0 на устройството - те ще трябва по някакъв начин да намерят поддръжка на Vulkan или GLEs 3.1 за техния GPU и GPU източник кодът е една от абсурдно строго охраняваните части на мобилните стекове (без истинска причина, бихме добавили - вижте AMD, отваряне на собствен AMDGPU драйвер на работния плот за Linux). За съжаление обаче Vulkan и ускорената (GLES) графика като цяло са малко по-сложни от обикновения светодиод, така че това не е нещо, за което ще видим подложки, за да представим съвместимост.

Тъй като 7.0 не е излизал от дълго време, има реална възможност други чипсети (освен малкия брой в самия AOSP) да останат изоставане на 6.0 поради проблеми с хардуера и драйвера (т.е. липса на актуализиран BSP) или липса на поддръжка от доставчика на SoC по отношение на Vulkan или GLES 3.1 API. Понастоящем нито Snapdragon 800, нито 801 поддържат едно от тях.

Най-добрият залог е да наблюдавате това пространство - разработчиците на XDA вече постигат добър напредък с неофициални портове към 7.0 за много от устройствата, които не получават официална поддръжка за 7.0 от Google. Те обаче са без поддръжка на Vulkan или GLES 3.1 - може би разработчиците на игри за Android ще започнат изпитайте разочарование поради фрагментация, ако достатъчно потребители започнат да изпълняват персонализирани ROM без Vulkan или GLES 3.1 поддържа?

Apple са склонни да поддържат своята линия iPhone на най-новата версия на iOS от около 5 години - iPhone 4s беше пуснат на пазара през октомври 2011 г. и беше поддържан актуален до iOS 9. Той обаче няма да получи предстоящата актуализация на iOS 10, което ще даде ефективен живот на телефона от 5 години, ако приемем, че iOS 10 бъде пусната около октомври. Струва си да се отбележи, че Apple не винаги поддържа back-port graphics API поддръжка – iPhone 4s и iPhone 5 не го правят разполагат с Metal graphics API на Apple, което е донякъде подобен сценарий на този, наблюдаван с Android в Вулкан. Единствената разлика е, че Apple продължи да поддържа по-старите устройства без новия графичен API.

Какво мислиш? Ще флашвате ли персонализиран ROM на телефона си, за да удължите живота му? Кажете ли в коментарите по-долу.