У цій статті ми досліджуємо правду про те, чому пристрої на Snapdragon 801 не отримують Android 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 сказав, що це було зроблено для запобігання фрагментації від людей, які використовують найновіші версії хоча на початку все швидко розвивалося, але, здається, вони зберегли цю політику місце.
У певний момент часу, зазвичай перед публічним оголошенням про оновлення (хоча з нещодавнім запровадженням загальнодоступних бета-версій ці часові масштаби зміщуються), Виробники комплектного обладнання будуть повідомлені про майбутнє оновлення. Потім вони отримають вихідний код у другий момент часу для остаточного оновлення (раніше це було іноді трохи завчасно до запуску, хоча ми також знаємо про випадки, коли немає раннього випуск).
Вихідні репозиторії AOSP містять підтримку пристроїв лише для обмеженої кількості пристроїв. Зазвичай це ваші пристрої Nexus. З причин, які стануть зрозумілими незабаром, важливо зазначити, що Google не має повного апаратного контролю над цими пристроями; пристрої виробляє OEM, і цей OEM придбає систему на кристалі (SoC) у виробника чіпсетів.
Щойно вихідний код буде опубліковано, команда виробника мікропрограмного забезпечення (фігурально) сяде, склавши руки. Основне дерево вихідних кодів Android не підтримує апаратне забезпечення для безлічі наборів мікросхем, які використовуються в пристроях для доставки. Ваш чіпсет Qualcomm, швидше за все, не підтримується в AOSP, наприклад. Ваш Exynos точно ні. Mediatek чи HiSilicon? Забудь це!
BSP містить драйвери та апаратні рівні абстракції (HAL), необхідні для запуску Android
Зараз потрібно a Пакет підтримки плати (BSP). Це суперконфіденційний пакет запатентованих компонентів, доставлений виробником чіпсета виробнику комплектного обладнання. BSP містить необхідний вихідний код, щоб OEM-виробники могли створювати Android і необхідні драйвери для своїх пристроїв.
Тут варто зазначити, що OEM-виробники, такі як Qualcomm, не обов’язково повністю довіряють своїм OEM-партнерам – BSP надається на основі «потрібно знати». Виробники оригінального обладнання зазвичай не мають доступу до вихідного коду для деяких надсекретних частин пристрою (наприклад, програмного забезпечення, що працює на базовій смузі). Закриття цієї частини, безсумнівно, також може спричинити потенційні проблеми, як показано на ближньому рясний і повторювані АСН.1 розбір вразливостей.
BSP містить драйвери та апаратні рівні абстракції (HAL), необхідні для роботи Android на вашому пристрої. AOSP містить набір HAL, які діють як визначення того, що операційна система очікує від ваших драйверів. Щоб використати надзвичайно спрощений (і вигаданий, для демонстрації) приклад, уявімо ліхтарик на вашому телефоні.
Приклад HAL - ваш ліхтарик
Уявімо, що на задній панелі вашого пристрою є ліхтарик (якщо у вас Nexus 7 2013, вам потрібно буде трохи більше пофантазувати, ніж усім іншим — вибачте!). Цим керує водій. Для нашого неймовірно простого прикладу припустімо, що HAL версії 1 каже, що у вас повинна бути одна функція під назвою «setLED», яка приймає один параметр, стан світла. Це логічне значення - істинне чи хибне. У C це виглядатиме приблизно так:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
Ця функція визначена у вихідному коді BSP. BSP потім компілюється OEM під час створення ПЗУ, і це стає однією з власних бібліотек «.so» у розділі постачальника або в області вашого пристрою. Це дозволяє виробникам обладнання зберігати в таємниці певні частини роботи свого пристрою. Наразі припустімо, що вони хочуть, щоб усі не бачили, як вони вмикають і вимикають цей світлодіод.
А тепер уявіть, що 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 очікує побачити нове визначення функції та не «знайде» старе, коли шукатиме спосіб налаштувати світлодіод.
На цьому етапі давайте зробимо невелику перерву, щоб поглянути на те, як користувацькі ПЗУ (створені з вихідного коду) тут працюють. Це те, що кмітливі з вас будуть кричати прямо зараз у свій екран - зрештою, ми XDA, дім HTC HD2, найдовговічніший телефон у світі... (тільки для запису, божевільні генії там біжать Сьогодні Android 6.0 на HD2! Непогано для телефону, який спочатку поставлявся з Windows Mobile 6.5 у 2009 році)
Тут використовуються різні підходи - іноді розробники зламують ПЗУ та кажуть ОС використовувати старі визначення функцій. Це трохи заплутано, і потрібно підтримувати багато змін. Інший підхід полягає в "прокладці" двійкового файлу OEM.
Підхід "прокладки" полягає в тому, щоб самостійно написати та створити крихітну нову бібліотеку, яка містить очікуване визначення функції - у нашому прикладі ми підтримаємо ціле число для яскравості. Потім у прокладці це перекладається відповідно до вимог старого HAL. Отже, для нашого прикладу ми можемо сказати, що будь-яка яскравість, яка вимагається вище 128, увімкне світлодіод, а будь-яка яскравість, яка є нижче, вимкне його. Або ви можете сказати, що будь-що, відмінне від нуля, увімкне його. Це залежить від розробника. Вони компілюють shim і змушують Android використовувати його замість рідного. Потім прокладка викликає OEM-блоб.
Швидке `adb push` і перезавантаження мають запустити прокладку та дозволити вам контролювати свій вигаданий світлодіод, навіть якщо у вас є лише старий HAL.
Проблема в тому, що це явно недосконалий процес. Тепер ви отримаєте примхи - цей пристрій матиме досить поганий спалах, який або повністю ввімкнено, або повністю вимкнено. Це не ідеально – ОС вважає, що випромінює дуже м’яке світло, але фактичному світлодіоду кажуть, що він бере участь у конкурсі штучного сонця, і намагається засліпити вас. Але привіт, життя не ідеальне, і тепер у вас є робочий світлодіод на вашому старому телефоні!
(Так, це одна з причин, чому виникають дивацтва та помилки, коли користувачі та розробники XDA керують своїми божевільними та божевільними подвигами майстерності портування. Я маю на увазі, до біса, Galaxy S II носить, здавалося б, придатний для використання Android 6.0 ROM зараз. Багато телефонів, випущених минулого року, досі не мають 6.0!)
Давайте повернемося до точки зору OEM. На жаль, більшість виробників обладнання вже працюють принаймні на 1 телефон раніше, ніж ми зараз. Їхня увага зосереджена на наступному телефоні, який вони збираються продати – ви не можете звинувачувати їх, оскільки вони заробляють гроші лише на пристроях, які продають. Вони не заробляють на пристроях, які продали рік чи два тому, тому їм доводиться випускати нові пристрої, щоб існувати. Це одна з причин, чому HTC і Blackberry мають проблеми - не має значення, скільки керівників тримають свій старий Blackberry Curve, тому що вони не продають нові пристрої там.
Якщо OEM не отримає BSP, вони не збираються відмовлятися від підходу XDA і спільного злому збірки. чому Добре, вони повинні підтримувати цю мікропрограму для своїх клієнтів. Якщо вони випустять прошивку, яка наполовину працює, користувачі будуть ненавидіти їх, лаяти та лютувати, а їхні лінії підтримки дзвонитимуть днями.
Виробникам оригінального обладнання також доводиться боротися з перевізниками, принаймні на неєвропейських ринках. Перевізники не хочуть, щоб клієнти мали проблеми з оновленнями програмного забезпечення. Насправді оператори часто не хочуть випускати оновлення програмного забезпечення.
Щоб зрозуміти це, уявіть свою двоюрідну тітку Алісу. Саме вона дзвонить вам у незручний час доби, щоб попросити допомоги з «цією комп’ютерною штукою». Потім ви описуєте, як натиснути на «меню «Пуск», і повинні ідентифікувати його як «великий прапорець у нижньому лівому куті», і зустрічаєтеся з плутаниною. Приблизно через 45 хвилин (і багато розчарування) з’ясовується, що тітка Аліса перетягнула своє меню «Пуск» до правого краю екрана, і їй просто потрібно було перетягнути його назад. Так, лівою кнопкою мишки!
А тепер уявіть, що у вас є тисяча тітоньки Аліси». Вони всі дзвонять у вашу службу підтримки клієнтів, не можуть знайти Candy Crush на своєму телефоні, стурбовані тим, що хакер видалив його з телефону. О, і значки тепер виглядають трохи інакше - можливо, хакер все ще в їх телефоні?
Так, це трохи легковажного гумору, але доки ви не дізнаєтесь, чому люди звертаються до свого оператора служби підтримки, ви не повірите, які у них проблеми. Оновлення програмного забезпечення, яке змінює роботу телефону або місце розташування, призведе до значних витрат на підтримку. Як мінімум, це вимагає перенавчання персоналу служби підтримки (оскільки більшість із них, на жаль, не є вашими завзятими читачами XDA).
Коли OEM отримає BSP, він перенесе свій ROM і застосує всі свої зміни до ROM. Вони нагромаджують своє програмне забезпечення та додають жахливий мультяшний скін, який виглядав би як вдома в підлітковому аніме. Тоді вони перевірять це.
Багато.
Існує безліч вимог, яким має відповідати ваш телефон. Мобільні мережі розроблені таким чином, щоб довіряти правильному поводженню обладнання користувача (те, що ми називаємо телефоном). Це означає, що для схвалення пристрою потрібно провести багато випробувань. Оновлення програмного забезпечення ризикують змінити поведінку, тому все потрібно перевірити ще раз. Ось чому ви зазвичай бачитимете інформацію про майбутні оновлення програмного забезпечення Sony від зовнішніх служб тестування, які підтверджують, що мікропрограмне забезпечення відповідає вимогам тестування.
зараз... що відбувається після одного або двох оновлень (або в деяких випадках жодного)? Виробник SoC не надасть OEM оновлений BSP. Зрештою, виробник SoC не отримає від цього багато. OEM більше не заробляє на вашому телефоні після того, як його продали. І на цьому етапі ваш телефон більше не отримує основних оновлень версій.
Зменшення кількості BSP, які хоче надати OEM, є чудовим способом заощадити гроші, якщо вам потрібен лише поточний і ви не маєте наміру постачати будь-яку основну версію збільшується, це заощадить гроші на початковій купівлі SoC та ліцензуванні, але за рахунок кількох розлючених ботанів на XDA, які дивуються, чому вони не отримали оновлення.
Оновлення складні. У ланцюжку задіяно багато різних людей. Жодне з цього не виправдовує виробників комплектного обладнання за поточний безладний і жалюгідний стан оновлень Android. Тим не менш, тут є деякі реальні виклики.
Багато OEM-виробників винні в надмірних обіцянках, і неминуче недопостачання, яке ми зараз асоціюємо. Сумна реальність полягає в тому, що для більшості OEM-виробників оновлення програмного забезпечення – це лише роздратування, без якого вони могли б обійтися.
Мобільний сектор здебільшого застряг у думці про функціональні телефони. Тобто, де пристрій ніколи не отримує жодних оновлень. Протестуйте один раз, надішліть і ніколи не оглядайтеся назад. З огляду на проблеми з безпекою сучасних смартфонів і величезну складність запуску повноцінної операційної системи загального призначення з сотнями зовнішніх бібліотек, це більше не варіант. Або принаймні це не повинен бути. Google зробив певні кроки, щоб виправити це, принаймні опублікувавши бюлетені безпеки та виправлення для існуючих випусків Android (пам’ятайте, що донедавна єдиним способом отримати оновлення системи безпеки була нова основна версія ОС Android!)
Але, на жаль, цього недостатньо. Незважаючи на те, що 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 на цій платформі. Якби це було так, це означало б, що OEM-виробники майже напевно не постачатимуть 7.0 на пристрої – їм доведеться якимось чином знайти підтримку Vulkan або GLE 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 почнуть це робити випробуйте розчарування через фрагментацію, якщо достатньо користувачів почнуть запускати спеціальні ПЗУ без Vulkan або GLES 3.1 підтримка?
Apple, як правило, підтримує свою лінійку iPhone на останній версії iOS протягом приблизно 5 років - iPhone 4s був випущений у жовтні 2011 року та оновлювався до iOS 9. Однак він не отримає оновлення iOS 10, яке дасть телефону ефективний термін служби 5 років, якщо iOS 10 буде випущено приблизно в жовтні. Варто зазначити, що Apple не завжди підтримує бек-порт графічного API – iPhone 4s і iPhone 5 цього не роблять. мають графічний API Metal від Apple, який є дещо схожим сценарієм до того, що спостерігається з Android у Вулкан. Єдина відмінність полягає в тому, що Apple продовжувала підтримувати старі пристрої без нового графічного API.
Що ти думаєш? Чи будете ви прошивати спеціальну ПЗУ на своєму телефоні, щоб продовжити термін його служби? Ви скажете в коментарях нижче.