Вибір інструментів
Представлений тут метод спирається на вихідний код Android CyanogenMod.
У той час як AOSP від Google тільки надає інструмент для створення в boot.imgфайл, CyanogenMod також додає unpackbootimgінструмент , що дозволяє вам розпакувати його. Цей інструмент ні в якому разі не розроблений спеціально для CyanogenMod, тому більшість шансів на те, що він буде працювати і для інших ПЗУ.
Однак існує порівняно велика кількість альтернатив для розпакування boot.imgфайлу, які працюють у більшій чи меншій мірі однаково.
В основному такий інструмент розпакування витягне вміст boot.imgфайлу та відобразить набір параметрів, які вам доведеться передати mkbootimgінструменту Google, щоб створити файл, конфігурація якого (переважно параметри ядра та адреси пам'яті) буде відповідати початковій.
Ось декілька прикладів, я не перевіряв їх особисто, тому не можу рекомендувати жодних, і я представляю їх лише для довідки:
Усі ці інструменти (та інші, які ви можете знайти з будь-якою пошуковою системою) повинні працювати однаково, але деякі можуть працювати краще, ніж інші, в обробці певного крайнього випадку, з яким ви можете зіткнутися зі своїм пристроєм. Однак більшість з них, принаймні на арені з відкритим кодом, не підтримуються регулярно, тому найкраще, на мою думку, мати працюючі, підтримувані та задокументовані інструменти - це поєднувати з цією CyanogenMod.
Деякі виробники випускають ПЗУ, які більш-менш далекі від стандарту AOSP (незвичайні адреси, заголовки, формат файлу тощо). Якщо стандартна процедура нижче не працює, можливо, одне з цих альтернативних програм може зробити трюк. В іншому випадку вам доведеться перевірити проблеми, характерні для вашого пристрою: деякі, здається, потребують певної процедури або навіть певних інструментів (надайте це питання , наприклад, для пристроїв MediaTek).
Установка інструментів
Складання набору інструментів CyanogenMod для boot.imgупаковки та розпакування досить просто.
- Якщо ви вже встановили повне дерево вихідного коду Android (ви можете перевірити іншу мою відповідь, щоб отримати додаткову інформацію про це), перейдіть до
system/core/mkbootimg/каталогу (нагадаємо, вихідний код Google AOSP надає лише інструмент для створення boot.imgфайлу, вони не надайте будь-який інструмент для розпакування),
Якщо ви цього не потребуєте і не потребуєте ні з якою іншою метою, простішим і швидшим рішенням є лише клонувати сховище android_system_core CyanogenMod :
git clone https://github.com/CyanogenMod/android_system_core.git
cd android_system_core/mkbootimg/
Опинившись у потрібному каталозі, компілюйте та встановіть:
gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/
Зверніть увагу , що Google замінює C mkbootimgз версією Python , так що в майбутніх версіях немає компіляції може знадобитися більше для цієї команди.
Вам також потрібно буде встановити на свій комп’ютер інструменти Android, щоб вони могли спілкуватися з вашим телефоном. Вам знадобиться adb(Bridge Debug Bridge Android), утиліта оболонки, що дозволяє спілкуватися з підсистемою налагодження Android), adbd(пов'язана демон) та fastboot(утиліта оболонки, що дозволяє спілкуватися з системою завантажувача вашого телефону).
Ваш улюблений дистрибутив Linux може надавати їх в одному або окремому пакеті, але зазвичай їх завжди називають "android-tools":
- Debian / Ubuntu:
sudo apt-get install android-tools-{adb,adbd,fastboot}
- Fedora / CentOS:
sudo yum install android-tools
- openSUSE:
sudo zypper install android-tools
Витягніть boot.imgфайл
Витягніть boot.img або з .zip-файлу ROM або безпосередньо з пристрою:
- З біржового файлу ROM .zip: деякі програми, такі як SuperSU, можуть змінювати boot.img безпосередньо на пристрої, заміняючи його на запас, це порушує такі програми.
- Безпосередньо з пристрою: деякі люди повідомляють про проблему читання, що призводить до пошкодження
boot.img. ІМО, ці проблеми, швидше за все, пов'язані з використанням неякісних кабелів USB або концентратора USB, і їх можна просто уникнути, використовуючи кабелі хорошої якості, що безпосередньо підключають телефон до комп'ютера. Вам також потрібна можливість запускати ADB в кореневому режимі (залежно від використовуваного ПЗУ, це може бути тривіально чи ні).
Перший спосіб дуже очевидний: витягніть .zip файл будь-яким програмним забезпеченням ZIP, boot.imgфайл повинен бути прямо в корені архіву.
Для другого методу спершу вам доведеться визначити шлях (на жаль, що залежить від пристрою) до пристрою зберігання, де boot.imgвміст можна отримати. Я знаю два методи для цього:
ls /dev/block/platform/*/by-name/(Де *охоплює ще одне ім'я папки конкретного пристрою, швидше за все , це єдиний каталог нижче platform/), точна назва для пошуку також залежить від платформи , але має звичайний сенс (деякі приклади: boot, LNX(абревіатура для «Linux»)). Файли в цьому каталозі насправді є символічними посиланнями, і деякі люди намагаються вручну перейти до цілі, але я рекомендую дотримуватися шлях на базі вищого рівня, який, хоч і довше, залишається менш схильним до помилок. Таким чином, ви закінчите таким шляхом /dev/block/platform/sdhci-tegra.3/by-name/LNX.
- На деяких (старих?) Пристроях правильний пристрій можна було б знайти, дослідивши вихід
cat /proc/mtd. Якщо ви бачите пристрій, mtd2пов’язаний з "boot"міткою, ви скористаєтеся контуром /dev/mtd2.
Зараз:
- У меню розробника телефону:
- Увімкніть налагодження на телефоні,
- Дозволити кореневий доступ до ADB (цей крок стосується телефонів, на яких працює CynogenMod, для інших пристроїв може знадобитися якась більш складна процедура),
- Підключіть його до свого комп’ютера (а звідти до гостя VM, якщо ви користуєтеся інструментами Android з віртуальної машини).
Якщо цього ще не зроблено, рекомендую вручну запустити сервер ADB на стороні комп'ютера, це дозволить вам безпосередньо перевірити ключ RSA на стороні пристрою, не впливаючи на поведінку наступних команд ADB:
adb start-server
Потім перемкніть ADB в кореневому режимі:
adb root
Нарешті, ви зможете безпосередньо витягнути boot.imgфайл із пристрою за допомогою такої команди (вихідний шлях та шлях призначення та назви наведено як приклади, адаптуйте їх до ваших потреб та уподобань):
adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img
Команда скопіює весь розділ, як використаний, так і вільний простір, тому не дивуйтеся, що отриманий boot.imgфайл буде більшим, ніж вихідний boot.imgфайл, що надходить із запасом .zip-файлу ROM, сам вміст залишається схожим.
Після завершення передачі відключіть телефон і не забудьте відключити як налагодження, так і кореневий доступ з меню розробника.
Розпакуйте вихідний boot.imgфайл
Розпакуйте сам boot.imgфайл за допомогою команди, складеної раніше:
unpackbootimg -i ./boot.img
Це дозволить отримати декілька важливих відомостей, які дозволять вам відновити нову boot.imgз правильною структурою щодо запасу boot.img. Однак не поспішайте на свій блокнот, оскільки CyanogenMod upackbootimgтакож зберігає ту саму інформацію в декількох файлах, які ми будемо використовувати згодом.
Ця команда генерує кілька файлів із певними суфіксами, доданими до імені вхідного файлу:
*-second: Це завантажувач другого ступеня, необов'язковий і рідко використовується на телефонах кінцевих користувачів. Якщо цей файл порожній (найчастіший випадок), завантажувач телефону безпосередньо викличе ядро Linux.
*-zImage: Це ядро Linux.
*-ramdisk.gzабо *-ramdisk.lz4: диск ОЗУ, який використовується для заповнення кореневого каталогу пристрою. Розширення відрізняється залежно від використовуваного алгоритму стиснення.
*-dt: Дерево пристрою, заселення /dev .
- Решта - це невеликі файли, кожен з яких зберігає одне із значень, відображених у
unpackbootimgвихідному. Ці значення визначають параметр командного рядка для передачі до ядра Linux та адреси, куди завантажувачеві доведеться завантажувати кожен об'єкт під час завантаження.
Найчастіше випаковується, boot.imgщоб можна було редагувати вміст кореневого каталогу телефону. Як було показано вище, цей вміст зберігається у файлі *-ramdisk.gzабо *-ramdisk.lz4файлі, і його можна витягти за допомогою наведених нижче команд:
mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd
Для стисненого диска оперативної пам'яті LZ4 замініть останній крок на lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd.
Тепер ви можете зробити потрібні зміни, перш ніж продовжувати. Однак, можливо, варто дотримуватися повної процедури розпакування - перепакування - завантаження один раз, не змінюючи нічого, щоб забезпечити роботу ваших інструментів як очікувалося. В іншому випадку, у випадку виникнення проблеми, ви не будете впевнені, що причиною є ваша модифікація чи якась несумісність (див. Мої зауваження на початку про деяких виробників, які потребують нестандартних процедур чи інструментів).
Відновіть, щоб отримати нове new-boot.img файл
Процес побудови CyanogenMod ROM покладається на внутрішній інструмент, mkbootfsдля створення boot.imgфайлу (це відбувається у build / tools / releasetools / common.py ). Однак кроки зі створення цього інструменту здаються мені марно складними, тоді як використання наданої системи, cpioздається, працює так само добре. Основна відмінність між цими двома, як я розумію після (дуже) швидкої перевірки mkbootfsкоду соуса, здається, в тому, що останній застосовує певні заходи щодо безпечності, не включаючи пунктирні файли та /rootкаталог у результуючому архіві,cpio процедури, що базується нижче просто сліпо помістить все вибране дерево каталогів в архів.
Висновок: зайво складно компілювати з дуже мало переваг, тож давайте дотримуватись наданих системою інструментів!
Почніть зі створення нового диску оперативної пам’яті із ramdiskствореного вище каталогу:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Або якщо вам потрібно створити архів LZ4:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4
Мета полягає в тому, щоб створити новий файл диска оперативної пам’яті з властивостями, максимально наближеними до оригінального (наприклад, встановлення власника, як правило, відсутнє в процедурах, поділених на форумах і в блогах, однак цього потрібно було на моєму пристрої).
Перейдіть зараз у батьківський каталог, щоб створити сам new-boot.imgфайл.
cd ..
Як видно вище, unpackbootimgкоманда CyanogenMod генерує файл, що відповідає кожному параметру, очікуваному mkbootimg. Тому все, що вам потрібно зробити, - це mkbootimg -hстворити а, щоб отримати список усіх параметрів, а потім встановити для кожного з них відповідне значення, використовуючи відповідний файл. Зауважте, що деякі параметри очікують шлях до файлу, а інші очікують отримання вмісту файлу як значення. Дивіться приклад результуючої команди нижче:
mkbootimg --kernel ./boot.img-zImage \
--ramdisk ./new-boot.img-ramdisk.gz \
--second ./boot.img-second \
--cmdline "$(cat ./boot.img-cmdline)" \
--base "$(cat ./boot.img-base)" \
--pagesize "$(cat ./boot.img-pagesize)" \
--dt ./boot.img-dt \
--ramdisk_offset "$(cat ./boot.img-ramdisk_offset)"
--second_offset "$(cat ./boot.img-second_offset)" \
--tags_offset "$(cat ./boot.img-tags_offset)" \
--output ./new-boot.img
Тут не встановлено лише два параметри:
--board: Наскільки я розумію, це лише інформативне поле, що дозволяє вставити назву моделі в отримане зображення.
--id: Цей значення не очікує, він просто виводить унікальний ідентифікатор після побудови зображення (поєднує часову позначку та контрольну суму).
Прошийте new-boot.imgфайл на пристрій
- Запустіть пристрій у режимі швидкого завантаження (він же режим завантажувача, зазвичай, утримуючи кнопки живлення та збільшення гучності).
- Підключіть USB-кабель.
Перевірте, чи пристрій правильно виявлено:
sudo fastboot devices
Спробуйте завантажитися за допомогою нового ПЗУ (ще не прошиваючи його, тому у випадку випуску вам просто доведеться перезапустити телефон, щоб повернути його на стежки, замініть ./new-boot.imgім’я файлу власним):
sudo fastboot boot ./new-boot.img
Якщо телефон успішно працює з новим завантажувальним зображенням, поверніться у режим швидкої завантаження та промайструйте його постійно:
sudo fastboot flash boot ./new-boot.img
sudo fastboot reboot
Висновок
Спочатку ця процедура може здатися жахливою, але як тільки ви її отримаєте, ви побачите, що насправді це не так.
"Непростий" аспект пов'язаний з тим, що не існує єдиної "системи Android": багато виробників та постачальників ПЗУ вносять зміни, які можуть варіюватися від тонкої різниці шляху до абсолютно нестандартного середовища.
Що вам потрібно зробити, це визначити позицію вашого конкретного пристрою, а потім які кілька команд, що підходять у вашому випадку. Як тільки ви їх отримаєте, ви можете дотримуватися їх і навіть легко скриптувати їх, якщо вони вам часто потрібні.
Іноді я добровільно заглиблювався в деталі щодо низького рівня, оскільки це полегшить вирішення проблем. Чи використовуєте ви якусь "легшу" непрозору утиліту для створення та спалаху нового boot.imgфайлу і бачите, що ваш пристрій не може запустити з нього, важче буде визначити, який крок пішов не так. Тут на кожному кроці ви зможете порівнювати оброблювані вами дані з даними, отриманими з оригінального boot.imgфайлу, або з даними, які бачать на телефоні, або спробувати відновити boot.imgфайл з оригіналом або з новоствореними Файл диска оперативної пам’яті перевірити, чи це не має різниці (це дозволяє точно визначити, чи проблема виникає внаслідок процедури boot.imgабо генерування файлу диска ОЗУ).