Без вихідного коду, як розробники отримують такі апаратні компоненти, як камери, які працюють у спеціальних ПЗУ? Відповідь: BLOB, прокладка та багато налагодження.
З випуском Android Oreo та багатьох пристроїв, таких як Xiaomi Redmi Note 3, Google Nexus 5 і інші отримують його неофіційно, мабуть, варто запитати, чому ті самі функції (переважно камера) зазвичай не працюють, коли розробники переносять ПЗУ на основі проекту Android Open Source Project (AOSP). Ви, мабуть, бачили теми дисків на форумі XDA з довгим списком несправних функцій. «Що працює», за яким іде список робочих функцій, а внизу — «Що не працює? Ти говориш мені!" два популярних рефрену на наших форумах, які практично стали мемами на таких сайтах, як Reddit і Twitter.
Чому стільки функцій порушується, коли розробник намагається перенести AOSP ROM на свій пристрій? Основна відповідь полягає в тому, що через те, що функції змінюються в різних версіях Android, старі драйвери пристроїв, упаковані як BLOB, не працюватимуть з новими версіями Android або навіть зі стандартним AOSP. Щоб подолати це, розробники використовують так звану «прокладку», але цей процес є складним, трудомістким і іноді його дуже важко налагодити.
У цій статті ми розповімо, як працюють прокладки, особливо щодо забезпечення належної роботи камери на ПЗУ на основі AOSP. Ми будемо використовувати OnePlus 3T як приклад. Зауважте, що труднощі, пов’язані з забезпеченням роботи цих функцій, дуже залежать від пристрою.
OnePlus 3T під керуванням OxygenOS. Хоча телефони OnePlus відомі своєю зручністю індивідуальної розробки, розробники виконують багато роботи, щоб створити стабільні порти AOSP.
Що таке прокладка чи BLOB?
Щоб навіть почати розуміти частину того, що роблять розробники, нам спочатку потрібно пояснити кілька речей. Незважаючи на те, що ОС Android є відкритим вихідним кодом (недаремно її називають Android Open Source Project), програмне забезпечення (без ядра), яке поставляється на тисячах пристроїв Android, не є таким. Розробники не мають доступу до вихідного коду Samsung Experience, EMUI, OxygenOS, або будь-який інший сторонній варіант Android.
Тепер розробникам, які переносять стандартний AOSP на пристрій, що не належить Google, можливо, байдуже до вихідного коду цих оболонок Android, оскільки вони не будуть модифікація та створення цих ПЗУ. Це було б правдою, якби не одна велика, серйозна причина: головним чином частини, необхідні для належної роботи камери в камера HAL (Hardware Abstraction Layer), є також закрите джерело.
Проблема з закритим вихідним кодом не лише камери HAL, але й ПЗУ полягає в тому, що розробники, які працюють над портуванням AOSP на свій пристрій, будуть робота наосліп. ПЗУ OEM із закритим вихідним кодом може добре взаємодіяти з HAL камери, оскільки OEM має доступ до джерела HAL камери. HAL камери – це те, що дозволяє ПЗУ «розмовляти» з апаратним забезпеченням камери — без нього камера не функціонуватиме. Подумайте про камеру HAL як про кермо та педалі автомобіля. Кермо/педалі дозволяють керувати внутрішніми компонентами транспортного засобу, надаючи водієві зовнішній інтерфейс (ПЗП), щоб використовувати внутрішні компоненти.
Оскільки апаратне забезпечення камери стає дедалі складнішим (the поява подвійних камер, наприклад), доступ до джерела HAL камери зробить перенесення ПЗУ AOSP із функціональною камерою набагато легшим.
Однак OEM-виробники не надають доступу до джерела HAL камери з різних причин. По-перше, якщо вони не мають усіх прав власності на камеру HAL (наприклад, коли вони включають інтелектуальну власність інших компаній), вони не можуть поширювати джерело. По-друге, оприлюднення джерела HAL камери може поставити під загрозу їх власну інтелектуальну власність. Нарешті, компанії не мають юридичних зобов’язань надавати цей вихідний код (на відміну від вихідного коду ядра, яким вони є зобов’язані випустити відповідно до GPL), тому вони не мають стимулу випускати його. Отже, без доступу до джерела HAL камери, як саме розробники змусять камеру працювати на ПЗУ AOSP? Відповідь: BLOB, прокладка та багато-багато налагодження.
Прилад BLOB (Binary Large OBject) містить попередньо запаковані двійкові файли, які є скомпільованою формою програмного забезпечення. У цьому випадку джерело HAL камери компілюється виробником обладнання та надсилається на пристрої як двійкові файли. Коли розробники говорять про BLOB, вони мають на увазі двійкові файли, які постачаються на живих пристроях, які вони можуть видобувати. Тепер у темі “camera BLOBs” є довго страждав OnePlus протягом багатьох місяців, але правда полягає в тому, що розробники завжди мали доступ до камери BLOB. The Вихідний код камери HAL є золотим квитком для розробників тут, хоча, але це буде ніколи, ніколи не буде звільнений через юридичну небезпеку, під яку потрапили б такі компанії, як OnePlus.
Таким чином, розробники, які бажають перенести AOSP на пристрій, залишаються лише з BLOB камери HAL, для яких вони не мають доступу до вихідного коду. Рідко, якщо взагалі, розробник може поєднати свій код AOSP ROM із камерою HAL BLOB і очікувати, що він працюватиме, тому, щоб подолати розрив між ними, розробники створюють те, що називається «прокладка.”
«Шимувати» означає «вклинювати (щось) або заповнювати простір». Фактично це те, що робить розробник написання прокладки — вони додають код, щоб дозволити BLOB взаємодіяти з вихідним кодом AOSP, над яким вони працюють з. Прокладки використовуються для того, щоб BLOB-об’єкти всіх різних типів працювали з AOSP, але зазвичай найбільше прокладок вимагає камера BLOB. Як ми вже згадували раніше, шиммінг потрібний не лише для портування нових версій Android на пристрій (наприклад, усі ці неофіційні ПЗУ Android Oreo), але також потрібні під час портування AOSP тієї ж версії Android на цей пристрій.
Рекомендована література: Від магазину до полиці: глибока капітуляція того, чому пристрої MSM8974 виключені з Nougat
OnePlus 2, наприклад, отримав своє останнє офіційне велике оновлення ОС у вигляді Android 6.0 Marshmallow. Пристрій, однак, насправді є повністю робочі спеціальні ПЗУ на основі AOSP базується на Android Nougat, і це завдяки наполегливій роботі розробників та їхніх прокладок. Ми розберемо деякі приклади прокладок, але спочатку нам потрібно поговорити про те, як саме працюють прокладки.
Як працює шиммінг?
Оскільки розробники не мають доступу до джерела HAL камери чи OEM ROM (а лише до попередньо скомпільованих двійкових файлів), вони не можуть знати, які функції очікує HAL камери. Через це часто виникає невідповідність між назвою функції, яку шукає HAL камери, та фактичною назвою функції в коді AOSP, з яким працює розробник.
Щоб вирішити цю проблему, розробник просто створює нову функцію, яка використовує те саме ім’я функція, яку очікує камера HAL BLOB, але ця нова функція просто виконує те, що хоче розробник це до. Ця нова функція, яка діє як посередник між BLOB і AOSP, є прокладкою. Цей конкретний сценарій, коли BLOB не може знайти потрібну функцію, є одним із найпоширеніших, де потрібна прокладка.
Можливо, все матиме трохи більше сенсу на гіпотетичному прикладі з OnePlus 3T. Ми створимо приклад за допомогою OxygenOS і камери OnePlus. Якщо ми використовуємо BLOB камери, взяті з OxygenOS Nougat для OnePlus 3T, щоб створити Nougat ROM на основі AOSP, у нас можуть виникнути проблеми. Це пов’язано з тим, що BLOB-файли камери (які спочатку були скомпільовані OEM) зможуть посилатися на всі необхідні функції в OxygenOS, але оскільки скомпільоване ПЗУ AOSP може не мати цих функцій або скомпільовано їх під іншою назвою (що призводить до невідповідності між символами функцій), буде помилка. Це можна виправити, створивши нову функцію в AOSP ROM із назвою, яку очікує BLOB — наша прокладка.
Символи в контексті програмування використовуються для позначення певних функцій у коді. Символи необхідні, оскільки позиція функції може змінюватися під час редагування коду, а отже, щоб уникнути жорсткого кодування посилань на функції, компілятор створює таблицю символів, яку інші функції можуть використовувати, щоб завжди посилатися на праву функція. Коли ви змінюєте назву функції перед компіляцією, її символ також змінюється, тому в основному будь-які зміни який OEM робить для джерела HAL камери перед компіляцією, розробникам потрібно буде створити новий прокладка.
Пояснення, яке ми пропонували досі, звучить так, ніби створити прокладки легко. Змінити кілька назв функцій тут і там не звучить надто важко, чи не так? Якби це було так легко. Реальність прокладок передбачає більше, ніж просто перейменування функцій. Ми розмовляли з визнаним XDA розробником Sultanxda, який зміг надати нам приклад однієї з найскладніших прокладок, над якою він працював.
Шимінг – не так просто, як здається
Для тих, хто не знайомий з OnePlus 3T, фронтальна камера спочатку була досить зламана. Спеціальні ПЗУ на основі AOSP. Почнемо з того, що спроба зробити будь-який знімок понад 8 МП призведе до збій. Намагаючись вирішити цю проблему, Султанда зробив кілька прокладки щоб передня камера OnePlus 3T працювала належним чином.
Прокладка №1 - Зміна назви пакета камери
Щоб запобігти збою передньої камери, коли користувач робив знімок із роздільністю понад 8 Мп, Sultanxda змусила камеру HAL ідентифікувати всі камери як камери OnePlus. Це зроблено тому, що OnePlus вирішив присвятити допоміжну функцію певним програмам (isOnePlusCamera, isFacebookCameraтощо) чомусь. Sultanxda виправив це, підшити камеру HAL, щоб вона вказувала на нову функцію, яка завжди повертає значення «true», наче користувач використовує камеру OnePlus, навіть якщо це не так.
Прокладка №2 - Вимкнути QuadraCfa
Для наступної прокладки йому довелося вимкнути QuadraCfa, яка, ймовірно, є власною технологією Qualcomm, пов’язаною з камерою. Ми говоримо, мабуть, тому що ні я, ні Sultanxda точно не впевнені, що таке QuadraCfa, але Sultanxda точно знає, що вона ламала фронтальну камеру, коли її вмикали.
Він помітив, що QuadraCfa якимось чином увімкнеться, але він не знав, чому і як це робиться. Вирішення цього вимагало досить нетрадиційної модифікації з його боку. У звичайній прокладці функція прокладки під час компіляції надає відсутній символ, який шукає BLOB. У цьому випадку BLOB вже мав необхідні символи — ті, які, імовірно, представляли функції, які запускали QuadraCfa.
Таким чином, йому потрібно було замінити символи, які використовує камера HAL, і, по суті, зробити їх «відсутніми», щоб його прокладки забезпечать ці «відсутні» символи. Єдиний спосіб зробити це через hex редагування самої камери HAL. Шістнадцяткове редагування — це в основному перегляд купи невпорядкованої тарабарщини у формі двійкових даних, щоб знайти голку в стозі сіна — або функцію, або рядок, який ви хочете редагувати.
Шістнадцяткове редагування функції значно складніше, ніж шістнадцяткове редагування рядка, але, на щастя, Sultanxda змогла уникнути необхідності шістнадцяткового редагування функцій, що стоять за QuadraCfa, замість цього шістнадцяткове редагування назв символів для анулювання цих символів.
Shim #3 - Виправлення збою в роботі Bright Light
Далі Sultanxda виявив, що зйомка з передньої камери в умовах яскравого освітлення призведе до збою камери. Для того, щоб відтворити цю помилку на власному пристрої, Sultanxda насправді увімкнув функцію ліхтарика свого OnePlus One і освітив світло перед фронтальною камерою OnePlus 3T щоб зробити його збій і створити придатні для використання журнали! Коли він виявив, яка функція спричинила збій, він створив прокладку, щоб змусити пристрій постійно використовувати режим слабкого освітлення для фронтальної камери.
Shim #4 – зображення передньої камери з низькою роздільною здатністю
Після усунення збою яскравого світла за допомогою попереднього шима Sultanxda виявив ще одну помилку, яка фактично виникла як прямий результат цього шима: зображення передньої камери з низькою роздільною здатністю. Замість того, щоб робити знімки з роздільною здатністю, заданою користувачем (наприклад, 16 МП), кінцеве зображення буде зроблено з роздільною здатністю 4 МП.
Вирішення цього вимагало, щоб він прокладав функції handleSuperResolution і isSuperResolution завжди повертати істину, але ТІЛЬКИ, коли фронтальна камера активна (оскільки в іншому випадку камера вийшла б з ладу під час фотографування із заднього датчика).
Засвоєний урок. Прокладка може бути важкою
Sultanxda визнає, що прокладки, які йому довелося створити, щоб запустити фронтальну камеру OnePlus 3T, не є типовим прикладом прокладки. Він досить пишається своєю прокладкою, враховуючи її складність і рідкісну необхідність шістнадцяткового редагування самого BLOB. Але цей приклад лише показує, наскільки важко змусити апаратне забезпечення камери працювати на певних пристроях.
Нехай ваші пригоди з регулюванням камери будуть менш болісними, ніж мої. -Султанджа
Колоди, колоди і ще більше колод. Без узгодженого способу відтворення збою та без журналів у розробників мало надії знайти джерело проблеми. Навіть якщо вони знайдуть причину проблеми, це не завжди легко вирішити. Увесь процес пошуку й усунення цих помилок може зайняти дні або тижні, тому виправлення камери на ПЗУ AOSP є одним із найважчих завдань.
Сподіваємось, якщо на вашому пристрої перенесено ПЗУ AOSP із повністю функціональним обладнанням, ви можете почати оцініть боротьбу, через яку могли пройти ці розробники, щоб надати вам їх особливості. Цінуйте їх за працю, адже це нелегко. Це велика робота, яку переважна більшість користувачів навіть не помітить, оскільки талановиті розробники на наших форумах піклуються про багато невидимих частин Android.
Ми хотіли б особливо подякувати Sultanxda за численні внески, які він запропонував у створенні цієї статті.