Подробное объяснение того, почему устройства SD801 исключены из Nougat

Обновлено с учетом требований Vulkan или OpenGL ES 3.1 для Android 7.0.

В последнее время было написано много статей об обновлениях версий, взаимодействии между поставщиком и производителем чипсетов и о том, что это означает для устройств в будущем. Почему на этой неделе этот показатель увеличился?

На этой неделе выяснилось, что почтенный Nexus 5 не получит обновления до Android 7.0 (Nougat), а Qualcomm объявила, что этого не произойдет. обеспечение поддержки MSM8974 (более известного как Snapdragon 801) в версии 7.0. Эта статья была написана в сотрудничестве с XDA признанным. Разработчик шмель.

Эта тема вызвала значительный интерес на различных новостных сайтах, но многие упускают тонкие нюансы того, что на самом деле происходит за сценойс. В этой статье мы расскажем немного больше о том, как работают обновления программного обеспечения, используя наш опыт работы с OEM-производителями над их официальными обновлениями прошивки. Мы расскажем вам, что происходит за кулисами (и почему), и почему вы можете не получить последнюю версию программного обеспечения на свой телефон.

Первым шагом в обновлении прошивки Android является обновление основной версии. Это то, над чем Google работает внутри компании. В отличие от «открытых рабочих процессов», Android разрабатывается с использованием закрытого рабочего процесса, при этом исходный код выбрасывается за стену каждый год или около того, когда выходит новая версия. Первоначально Google заявил, что это сделано для предотвращения фрагментации со стороны людей, использующих новейшие версии. хотя в первые дни все быстро развивалось, но они, похоже, сохранили эту политику в место.

В какой-то момент, обычно перед публичным объявлением об обновлении (хотя с недавним появлением публичных бета-версий эти сроки смещаются), OEM-производители будут уведомлены о предстоящем обновлении. Затем они получат исходный код для окончательного обновления во второй момент времени (ранее это было иногда немного раньше запуска, хотя мы также знаем случаи, когда раннего запуска не было. выпускать).

Восходящие репозитории AOSP содержат поддержку только ограниченного числа устройств. Обычно это ваши устройства Nexus. Однако по причинам, которые вскоре станут ясны, важно отметить, что Google не имеет полного аппаратного контроля над этими устройствами; устройства производятся OEM-производителем, и этот OEM-производитель купит систему на кристалле (SoC) у производителя чипсета.

Как только исходный код будет выпущен, команда OEM-производителей прошивки (образно) сядет и поднимет ноги. Основное дерево исходного кода Android не имеет аппаратной поддержки множества чипсетов, используемых в поставляемых устройствах. Например, ваш чипсет Qualcomm, скорее всего, не поддерживается в AOSP. Ваш Exynos определенно нет. Медиатек или ХайСиликон? Забудь это!

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

Что сейчас необходимо, так это Пакет поддержки платы (BSP). Это сверхконфиденциальный пакет запатентованных компонентов, поставляемый производителем чипсета OEM-производителю. BSP содержит необходимый исходный код, позволяющий OEM-производителям создавать Android, а также необходимые драйверы для своих устройств.

Здесь стоит отметить, что OEM-производители, такие как Qualcomm, не обязательно полностью доверяют своим OEM-партнерам — BSP предоставляется по принципу «необходимости знать». OEM-производители обычно не получают доступа к исходному коду некоторых сверхсекретных частей устройства (например, программного обеспечения, работающего на основной полосе частот). Закрытие этой части, безусловно, также имеет потенциальные проблемы, как показывает недавний обильный и повторяющийся АСН.1 парсинг уязвимостей.

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

Пример HAL — ваш фонарик

Давайте представим, что на задней панели вашего устройства есть фонарик (если у вас Nexus 7 2013 года, вам придется воображать немного больше, чем всем остальным — извините!). Это контролируется водителем. Для нашего безумно простого примера предположим, что HAL v1 говорит, что у вас должна быть одна функция под названием «setLED», принимающая единственный параметр — состояние источника света. Это логическое значение — true или false. В C это будет выглядеть примерно так:

void setLED(bool ledState) {

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

}

Эта функция определена в исходном коде BSP. Затем BSP компилируется OEM-производителем во время сборки ПЗУ, и он становится одной из проприетарных библиотек «.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 ожидает увидеть новое определение функции и не «находит» старое, когда ищет способ установить светодиод.

На этом этапе давайте сделаем небольшой перерыв, чтобы посмотреть, как здесь работают пользовательские ПЗУ (созданные из исходного кода). Это то, что самые проницательные из вас будут кричать прямо сейчас на ваш экран — в конце концов, мы — XDA, дом HTC HD2, самый долговечный телефон в мире... (для справки: там бегают сумасшедшие гении Android 6.0 на HD2 в наши дни! Неплохо для телефона, изначально поставляемого с Windows Mobile 6.5 в 2009 году)

Здесь используются различные подходы - иногда разработчики взламывают ПЗУ и говорят ОС использовать старые определения функций. Это немного беспорядочно и требует много изменений, которые нужно поддерживать. Другой подход — «подшить» двоичный файл OEM.

Подход «шим» заключается в том, чтобы самостоятельно написать и построить небольшую новую библиотеку, содержащую ожидаемое определение функции — в нашем примере мы будем поддерживать целое число для яркости. Затем внутри оболочки это преобразуется в соответствии с требованиями старого HAL. Итак, в нашем примере мы могли бы сказать, что любая яркость, запрошенная выше 128, включит светодиод, а все, что ниже этого значения, выключит его. Или вы можете сказать, что все, что не равно нулю, включит его. Это зависит от разработчика. Они компилируют прошивку и заставляют Android использовать ее вместо родной. Затем прокладка вызывает OEM-блоб.

Быстрое нажатие adb и перезагрузка должны запустить прошивку и позволить вам управлять своим вымышленным светодиодом, даже если у вас есть только старый HAL.

Проблема в том, что это явно несовершенный процесс. Теперь у вас есть странности: у этого устройства будет довольно неуклюжая вспышка, которая либо полностью включена, либо полностью выключена. Это не идеально — ОС думает, что излучает очень мягкий свет, но реальному светодиоду говорят, что он участвует в конкурсе искусственного солнца и пытается вас ослепить. Но эй, жизнь не идеальна, и теперь на вашем старом телефоне есть работающий светодиод!

(Да, это одна из причин, почему возникают странности и ошибки, когда пользователи и разработчики XDA совершают свои сумасшедшие и безумные подвиги по портированию. Я имею в виду, черт возьми, Галактика С II носит с собой, казалось бы, годный к употреблению Android 6.0 ПЗУ сейчас. Многие телефоны, выпущенные в прошлом году, до сих пор не имеют 6.0!)

Давайте вернемся к точке зрения OEM-производителя. К сожалению, большинство OEM-производителей уже работают как минимум на 1 телефон впереди, чем мы сейчас. Их внимание сосредоточено на следующем телефоне, который они собираются продать — их нельзя винить, поскольку они зарабатывают деньги только на устройствах, которые продают. Они не зарабатывают денег на устройствах, которые продали год или два назад, поэтому им приходится продолжать выпускать новые устройства, чтобы существовать. Это одна из причин, по которой у HTC и Blackberry проблемы: неважно, сколько руководителей держат в мертвой хватке свой старый Blackberry Curve, потому что там они не продают новые устройства.

Если OEM-производитель не получит BSP, он не собирается использовать подход XDA по сбору сборки. Почему? Хорошо, им необходимо поддерживать эту прошивку для своих клиентов. Если они выпустят прошивку, которая наполовину работает, пользователи будут их ненавидеть, разглагольствовать и неистовствовать, а их линии поддержки будут звонить несколько дней.

OEM-производителям также приходится конкурировать с операторами связи, по крайней мере, на неевропейских рынках. Операторы связи не хотят, чтобы у клиентов возникали проблемы с обновлениями программного обеспечения. Фактически, операторы связи часто предпочитают не выпускать обновления программного обеспечения.

Чтобы понять это, представьте себе свою двоюродную бабушку Алису. Это она звонит вам в неудобное время дня и просит помощи с «этой компьютерной штукой». Затем вы описываете, как нажать на «меню «Пуск», и вам приходится идентифицировать его как «большой флаг в левом нижнем углу», и вы встречаетесь с замешательством. Примерно через 45 минут (и с большим разочарованием) выясняется, что тетя Алиса перетащила свое меню «Пуск» к правому краю экрана, и ей просто нужно было перетащить его обратно. Да, левой кнопкой мыши!

А теперь представьте, что у вас есть тысяча теток Алисы». Они все звонят в вашу службу поддержки, не могут найти Candy Crush на своем телефоне и обеспокоены тем, что хакер удалил ее с их телефона. Да, и значки теперь выглядят немного иначе — может быть, хакер все еще в их телефоне?

Да, это должно быть немного беззаботного юмора, но пока вы не поймете, почему люди обращаются к своему оператору за поддержкой, вы не поверите, какие у них проблемы. Обновление программного обеспечения, которое меняет работу телефона или его местоположение, приведет к значительным затратам на поддержку. Как минимум, это требует переподготовки персонала службы поддержки (потому что, к сожалению, большинство из них не являются вашими заядлыми читателями XDA).

Как только OEM-производитель получит BSP, он перенесет свое ПЗУ и применит все свои изменения к ПЗУ. Они нагромоздят свое раздутое ПО и добавят ужасающий мультяшный скин, который больше смотрелся бы в подростковом аниме. Потом они это проверят.

Много.

Ваш телефон должен соответствовать множеству требований. Мобильные сети спроектированы таким образом, чтобы доверять пользовательскому оборудованию (тому, что мы называем телефоном) правильному поведению. Это означает, что для одобрения устройства необходимо провести множество испытаний. Обновления программного обеспечения могут изменить поведение, поэтому все необходимо протестировать еще раз. Вот почему вы часто будете видеть информацию о предстоящих обновлениях программного обеспечения Sony от внешних служб тестирования, которые подтверждают, что встроенное ПО соответствует требованиям тестирования.

Сейчас... что происходит после одного-двух обновлений (или, в некоторых случаях, ни одного)? Производитель SoC не предоставит OEM-производителю обновленный BSP. В конце концов, производитель SoC от этого многого не получит. OEM-производитель больше не зарабатывает на вашем телефоне с момента его продажи. На данный момент ваш телефон больше не получает обновлений основных версий.

Сокращение количества BSP, которые хочет поставить OEM-производитель, — отличный способ сэкономить деньги, если вам нужна только текущая версия и вы не собираетесь поставлять какие-либо основные версии. увеличивается, это сэкономит деньги на первоначальной покупке и лицензировании SoC, но за счет нескольких разгневанных ботаников на XDA в дальнейшем, задающихся вопросом, почему они не получили обновлять.

Обновления сложны. В цепочке задействовано много разных людей. Ничто из этого не оправдывает OEM-производителей за нынешнее вялое и жалкое состояние обновлений для 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 или драйверах (как описано выше), поэтому какая-либо несовместимость вряд ли связана именно оттуда. Однако более вероятно, что возникнет проблема с введением новое требование для графического 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 для своего графического процессора и источник графического процессора. код — одна из смехотворно тщательно охраняемых частей мобильных стеков (мы бы добавили, что без всякой причины — см. AMD, открывающую исходный код своего собственного драйвера AMDGPU для настольных компьютеров для Линукс). Однако, к сожалению, Vulkan и ускоренная графика (GLES) в целом немного сложнее, чем простой светодиод, поэтому мы не увидим прокладок для обеспечения совместимости.

Поскольку версия 7.0 вышла совсем недавно, существует реальная вероятность того, что другие чипсеты (кроме небольшого количества внутри самого AOSP) останутся без внимания. отставание от версии 6.0 либо из-за проблем с оборудованием и драйверами (т. е. отсутствия обновленного BSP), либо из-за отсутствия поддержки поставщика SoC в отношении Vulkan или GLES 3.1. API. В настоящее время ни Snapdragon 800, ни Snapdragon 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.

Что вы думаете? Будете ли вы устанавливать на свой телефон специальную прошивку, чтобы продлить срок его службы? Скажите ли вы в комментариях ниже?