09:36 10-09-2012 
Arago
Новый способ создания update.zip для Android.
Когда я попробовал себя в написании хоть сколько нибудь сложного мода для Android — пришлось вплотную (а вернее с размаху носом) столкнуться с языком edify — на нём пишется updater-script в Android flashable пакетах. И столкновение это не прошло незамеченным для моей психики, вызвав ощущение собственной неполноценности, связанный с этим butthurt и лютобешеную ненависть к этому языку.
Почему невозможно заработать на бинарных опционах?
Соответственно я начал искать иные пути, чтобы использовать милый сердцу за свою мощь, красоту и простоту язык Unix Shell скриптов. И теперь хочу поделиться с Вами опытом.
Целью моих изысканий было найти возможность отображения состояния хода установки обновления на экране телефона, ведь без этого можно было и так использовать скрипт Shell, вызыывая его из edify скрипта. Собственно это и было успешно достигнуто.
Плюс несколько уменьшен размер Zip-обновления, оно занимает 91кБ, против 231 кБ у edify-версии.
Немного теории о том, как происходит установка Zip-архива из Recovery.
Recovery извлекает из архива с обновлением файл META-INF/com/google/android/update-binary в /tmp, делает ему chmod 777 и запускает передавая три параметра:
1. API level. Это число от 1 до 3 (в моём случае это было 2). Для нас полностью бесполезен.
2. Дескриптор Pipe для обратной связи с Recovery. С ним подробнее разберёмся позднее.
3. Полное имя Zip-обновления. Тут я полагаю всё ясно.
Немного поковырявшись в исходниках update-binary от edify и изучив состояние системы при установке и происходящие в ней процессы, был рождён следующий код
#!/sbin/sh
interface=»/proc/$$/fd/$2″
zip=»$3″
boot=»mmcblk0p20″
set_progress() ( echo set_progress 0.$1 > $interface )
ui_print() ( echo ui_print $1 > $interface )
##main
cd /tmp/
set_progress 02
if grep -q shooteru /default.prop ; then ui_print «Shooteru device!» ; else ui_print «This is not shooteru device!» ; exit 1 ; fi
grep -q /system /proc/mounts || mount /system || exit 2
release=`grep ‘ro.build.version.release’ /system/build.prop|cut -d ‘=’ -f 2`
set_progress 08
case $release in
4.1.1) ui_print «Android $release found, version is correct, continue»;;
4.0.3) ui_print «Android $release found, version is correct, continue»;;
Бинарные файлы C++. В чем прикол? Как с ними работать?
*) ui_print «Android $release found, version is incorrect, break»; exit 4
esac
set_progress 10
ui_print «Extracting temporary files»
unzip -o $zip tmp/* -d / >/dev/null || exit 5
set_progress 20
chmod 0755 /tmp/mkbootimg || exit 6
chmod 0755 /tmp/unpackbootimg || exit 7
set_progress 30
ui_print «Unpacking Your’s Boot»
/tmp/unpackbootimg /dev/block/$boot «/tmp/» || exit 8
set_progress 45
ui_print «Unpacking Your’s ramdisk»
rm -r ramdisk
mkdir ramdisk || exit 9
cd ramdisk || exit 10
zcat /tmp/$boot-ramdisk.gz | cpio -i || exit 11
set_progress 55
ui_print «Updating ramdisk»
echo sys.usb.config=adb >> /tmp/ramdisk/default.prop
cp `which adbd` /tmp/ramdisk/sbin/adbd || exit 13
cp /system/*bin/sh /tmp/ramdisk/sbin || exit 14
chmod 0755 «/tmp/ramdisk/sbin/adbd» || exit 15
chmod 0755 «/tmp/ramdisk/sbin/sh» || exit 16
set_progress 60
ui_print «Repacking new ramdisk»
find . | cpio -o -H newc | gzip > /tmp/new-ramdisk.gz || exit 17
cd —
set_progress 70
ui_print «Preparing newboot.img»
/tmp/mkbootimg —kernel /tmp/$boot-zImage —ramdisk /tmp/new-ramdisk.gz —cmdline «`cat /tmp/$boot-cmdline`» —base `cat /tmp/$boot-base` —output /tmp/newboot.img || exit 18
set_progress 80
ui_print «Flashing newboot.img to $boot»
dd if=/dev/zero of=/dev/block/$boot bs=65536
set_progress 90
dd if=/tmp/newboot.img of=/dev/block/$boot bs=65536 || exit 19
set_progress 95
rm /tmp/newboot.img /tmp/new-ramdisk.gz /tmp/$boot* || exit 20
set_progress 98
umount /system || exit 23
set_progress 99
Давайте разберёмся в нём.
#!/sbin/sh
Строка, указывающся ядру, что делать со скриптом (вернее чем его исполнять). Указывает на интерпретатор команд.
interface=»/proc/$$/fd/$2″
Определение переменной хранящей адрес канала по которому мы будем общаться с Recovery. $$ превращается в PID текущего процесса, а $2 — передвавемый нам из Recovery номер дескрпптора канала. Всё, что мы будем писать в него Recovery будет воспринимать как команды.
zip=»$3″
Получаем в переменную имя зипа, оно нам ещё пригодится.
boot=»mmcblk0p20″
Переменная будет хранить имя файла устройства, хранящего boot.img.
set_progress() ( echo set_progress 0.$1 > $interface )
ui_print() ( echo ui_print $1 > $interface )
Две строки, определяющие функции по работе с интерфейсом Recovery, аналогичные одноимённым командам edify. Как видим, используются две команды для этого интерфейса, ui_print (выводит текст в окошко на экране) и set_progress (передвигает прогресс-бар).
cd /tmp/
set_progress 02
Мы готовимся к работе, переходя в каталог /tmp/ и передвигаем прогресс-бар на уровень 2 процента. Далее я не буду описывать команду set_progress, её смысл одинаков везде.
if grep -q shooteru /default.prop ; then ui_print «Shooteru device!» ; else ui_print «This is not shooteru device!» ; exit 1 ; fi
Проверяем, запущен ли скрипт на правильном устройстве (ведь работа скрипта для одного устройства на другом может закончиться необратимым повреждением этого устройства) и прерываем процесс если это не так. Аналог getprop из edify, но неполный. Заставить настоящий gerprop работать у меня не вышло.
Обратите внимание на то, что мы пользуемся функцией ui_print которую определили выше. Далее я не буду описывать ui_print, из за его очевидности.
Также обратите внимание на команду exit 1 — она предназначена для облегчения отладки скрипта, и одновременно прерывания его работы в случае если что то пошло не так как надо. В случае ошибки при работе скрипта он будет прерван, а Recovery выведет код ошибки, по которому будет можно легко найти место где эта ошибка произошла.
grep -q /system /proc/mounts || mount /system || exit 2
Проверяем, смонтирован ли раздел /system, монтируем его если это не так, и прерываем работу с кодом 2 если монтирование не удалось. Далее я не буду описывать команду exit #, её смысл ясен и так.
release=`grep ‘ro.build.version.release’ /system/build.prop|cut -d ‘=’ -f 2`
Получаем в переменную версию Android установленную на устройстве. Аналог getprop_file из edify.
case $release in
4.1.1) ui_print «Android $release found, version is correct, continue»;;
4.0.3) ui_print «Android $release found, version is correct, continue»;;
*) ui_print «Android $release found, version is incorrect, break»; exit 4
esac
И тут же проверяем её. Это просто образец, на самом деле этот мод будет работать на любом устройстве и прошивке, где есть кастомное Recovery и установлен Busybox.
unzip -o $zip tmp/* -d / >/dev/null || exit 5
Извлекаем из Zip-архива с обновлением каталог tmp/ со всеми файлами в каталог / (корень ФС, параметр -d) с перезаписью файлов при необходимости (параметр -o)
chmod 0755 /tmp/mkbootimg || exit 6
chmod 0755 /tmp/unpackbootimg || exit 7
Придаём извлеченным файлам атрибут исполняемости, чтобы их можно было запустить.
/tmp/unpackbootimg /dev/block/$boot «/tmp/» || exit 8
Распаковываем boot.img прямо из памяти устройства в каталог /tmp/
rm -r ramdisk
Удаляем (на случай если какой-то скрипт ранее уже создал его) каталог ramdisk со всем его содержимым
mkdir ramdisk || exit 9
Создаём этот каталог
cd ramdisk || exit 10
И переходим в него.
Обратите внимание, что после rm -r нет проверки на ошибку. Это сделано специально, ошибка здесь допустима, и более того — в нормальном режиме rm -r обязан выдать ошибку.
zcat /tmp/$boot-ramdisk.gz | cpio -i || exit 11
Распаковываем GZip-упакованный CPIO-образ Ramidsk (также известен как initrd) в текущий каталог (ramdisk).
echo sys.usb.config=adb >> /tmp/ramdisk/default.prop
Записываем в конец файла /tmp/ramdisk/default.prop строку sys.usb.config=adb
cp `which adbd` /tmp/ramdisk/sbin/adbd || exit 13
Находим полный путь к файлу adbd командой which и копируем его в /tmp/ramdisk/sbin/adbd
cp /system/*bin/sh /tmp/ramdisk/sbin || exit 14
Копируем файл sh из каталога /system/bin/, /system/xbin/ или /system/xbin/ (уж где то shell то в системе обязан быть!) в /tmp/ramdisk/sbin/
chmod 0755 «/tmp/ramdisk/sbin/adbd» || exit 15
chmod 0755 «/tmp/ramdisk/sbin/sh» || exit 16
Придаём файлам права на исполняемость
find . | cpio -o -H newc | gzip > /tmp/new-ramdisk.gz || exit 17
Упаквываем образ нового ramdisk
cd —
И возвращаемся в предыдущий текущий каталог
/tmp/mkbootimg —kernel /tmp/$boot-zImage —ramdisk /tmp/new-ramdisk.gz —cmdline «`cat /tmp/$boot-cmdline`» —base `cat /tmp/$boot-base` —output /tmp/newboot.img || exit 18
Создаём новый boot.img
dd if=/dev/zero of=/dev/block/$boot bs=65536
Стираем старый boot.img, заполняя раздел для него нулями
dd if=/tmp/newboot.img of=/dev/block/$boot bs=65536 || exit 19
И записываем туда новый boot.img (на самом деле это всё вовсе не обязательно делать, можно было просто прописать —output /dev/block/$boot в команде создающей boot.img)
rm /tmp/newboot.img /tmp/new-ramdisk.gz /tmp/$boot* /tmp/ramdisk/ /tmp/mkbootimg /tmp/unpackbootimg || exit 20
Удаляем всё после себя (не знаю как вас, а меня учили прибирать за собой)
umount /system || exit 23
Размонтируем /system/
Всё. А мод этот добавляет поддержку ADB на значительно более ранней стадии загрузки системы, примерно спустя 8 секунд после включения, что даст возможность отлаживать процесс загрузки с гораздо более раннего момента, и даже вмешиваться в него.
Статья оригинальная, автор идеи, разработок и технической реализации — я. Статья будет выложена также на форуме 4pda (под другим ником), не считайте это плагиатом. Скрина нет, так как скринить по сути нечего.
Прикрепленный файл #1:
Источник: dimonvideo.ru
Как сделать кастомную прошивку для CWM/TWRP из заводской [Инструкция / Android Kitchen]
Инструкция по созданию кастомной прошивки в виде zip архива для прошивки через кастомное рекавери при помощи Android Kitchen
Что нам понадобится:
1. Установленная и настроенная «кухня» для Android: Как установить Android Kitchen на Windows [Инструкция]
2. Прошивка для вашего устройства под SP Flash Tool (папка с файлами вроде recovery.img, system.img, scatter.txt и так далее)
Инструкция по созданию прошивки для CWM/TWRP:
1. После того как установили Android Kitchen, берёте из папки с прошивкой файлы system.img и boot.img и копируете их в папку для работы с прошивками, а именно kitchenoriginal_update (если не понятно где это, то установите Android Kitchen по инструкции выше, все станет ясно после)
2. Далее запускаем Cygwin и Android Kitchen. Запускать Cygwin обазятельно на правах администратора, как всё это делается я описал в инструкции по настройке Android Kitchen, так что сначала установите «кухню», потом всё станет ясно
3. После того как вы вошли в меню Android Kitchen, выбираем первый пункт, то есть:
========================================================== Android Kitchen 0.224 — by dsixda (xda-developers.com) ========================================================== > MAIN MENU 1 — Set up working folder from ROM 2 — Add root permissions 3 — Add BusyBox 4 — Disable boot screen sounds 5 — Zipalign all *.apk files to optimize RAM usage 6 — Change wipe status of ROM 7 — Change name of ROM 8 — Show working folder information 0 — ADVANCED OPTIONS 00 — LEGACY OPTIONS (old and rarely used) 99 — Build ROM from working folder u — Kitchen Info/Update/Donate x — Exit Enter option: 1
4. После того как нажали 1 и Enter, появляется новое меню тут просто нажимаем Enter для продолжения, затем 1 и Enter, и после того как система определит наши system.img и boot.img (которые мы скинули в рабочую папку ранее), нам будет предложено переименовать ли папку куда будет распакованы все файлы прошивки для работы с ними, или не переименовывать, выберите «n», то есть не переименовывать):
CREATE WORKING FOLDER FOR ROM ========================================================== Ensure there is at least one ROM under the ‘original-update’ folder! Select an option: s — Show supported formats x — Abort, don’t create working folder Or press Enter to continue ? Please wait . Available ROMs: (1) system.img and boot.img Enter selection number (default=1, cancel=0, r=refresh): 1 Found original_update/system.img Found original_update/boot.img The new working folder will be named WORKING_032915_064017 Change the name (y/n)? (default n): n
5. Далее начинается распаковка прошивки, может занять некоторое время. Важно, во время распаковки появится окно распаковщика Ext2explore . Не закрывайте его, а внимательно прочтите что написано в окне Android Kitchen (если дружите с англ.):
###################################################################### READ INSTRUCTIONS BELOW TO EXTRACT FILES FROM ext4_system.img: 1) Ignore the ‘Cannot Read Disk’ warning dialog (press ‘OK’) if it appears! 2) When Ext2Explore appears, use ‘File-> Open Image’ to open: C:cygwinhomePC_UserkitchenWORKING_032915_064017systemext4_system.img 3) After it loads, right-click on the new icon displayed in the left frame, and select Save 4) Select C:cygwinPC_UserkitchenWORKING_032915_064017system 5) Wait for extraction to finish and then close Ext2Explore ######################################################################
6. Итак делаем что написано, в открывшемся окне Ext2Explore выбираем File -> Open Image и выбираем C:cygwinhomePC_UserkitchenWORKING_032915_064017systemext4_system.img . После чего в левой части Ext2Explore , делаем правый клик по пункту и выбираем Save (см. скриншот ниже), после чего указываем путь для сохранения распакованных файлов, а именно C:cygwinPC_UserkitchenWORKING_032915_064017system (начнётся распаковка, которая может занять некоторое время, не прерывайте).
7. После того как распаковка окончена, закройте окно Ext2Explore и нажмите Enter в окне Android Kitchen. Начнется завершающая стадия распаковки прошивки после которой вам будет предложено посмотреть информацию о данной прошивке, для выбора опции нажмите «y»:
Finished setting up working folder! Would you like to view this ROM’s info (y/n)? (default: y): y
8. Для примера показана рабочая информация по прошивке взятой с Lenovo A369i:
Working folder information (v0.224) Android OS version : 4.2.2 Device : A369i Model : Lenovo A369i ROM Name : A369i_ROW_S201_140610 Rooted (Supersu app + su) : NO Rooted (unsecured boot.img) : NO BusyBox installed : NO BuxyBox run-parts support : NO Apps2SD (Apps to EXT) enabled : NO /date/app enabled : NO Custom boot animation allowed : NO Nano text editor installed : NO Bash shell support : NO /system/framework is deodexed : NO /system/app is deodexed : NO radio.img found : NO ROM will wipe all data : NO Press Enter to continue
9. Всё, теперь прошивка, фактически готова. После нажатия Enter, вы будете возвращены в главное меню Android Kitchen, теперь выбираем пункт:
99 — Build ROM from working folder
10. Далее вам будет предложено выбрать в каком режиме будет создана прошивка, рекомендую выбирать первый пункт:
1 = Interactive Mode — recommended for most users (Guide me through the build)
11. Далее будет предложено оптимизировать все apk файлы при помощи «zipalign», можете нажать «y» или «n», не важно:
Would you like to optimize APK files by zipaligning them (y/n)? (default: y): y
12. Дальше будет очень важный пункт здесь, нам надо нажать «y» (то есть yes, согласиться). Будет создан файл updater-sсript, который мы отредактируем уже потом, когда создадим прошивку, так что нажмите просто «y» и пусть «кухня сама всё сделает»:
Use updater-sсript in ROM’s ZIP file (y/n)? (default: y) y
13. По завершению создания updater-sсript, нам будет предложено отредактировать его сейчас и внести нужные изменения, но как я сказал ранее, редактировать его удобнее потом, после того как прошивка уже собрана, поэтому оставляет тут все как есть:
Proceed with the change (y/n)? y = Proceed; updater-sсript and update-binary will be used inthe ZIP file; update- will remain in working folder. n = Cancel; updater-sсript and update-binary will be deleted and not used. ? (default: y): y
14. Далее начнется создание update.zip, после которого нам будет предложено подписать архив с прошивкой, соглашаемся на это (хотя по-идее можно и не подписывать, всё равно прошивку надо будет разбирать для редактирования updater-sсript):
It is recommended that you sign your ROM. Sign it (y/n)? (default: y): y
15. Далее последний пункт где нам будет предложено изменить название прошивки, можно оставить как есть:
The new ROM will be named A369i_signed_032915_073536.zip Change the name (y/n)? (default: n): n
16. Всё, прошивка создана, и находится в папке с кухней OUTPUT_ZIP/A369i_signed_032915_073536.zip . Копируем архив целиком и переносим в отдельную, удобную для вас папку. Теперь надо редактировать updater-sсript. Android Kitchen можно закрыть.
17. Распаковываем содержимое нашей прошивки в отдельную папку и видим следующее:
18. Заходим в папку META-INFcomgoogleandroid и открываем при помощь любого текстового редактора файл updater-sсript (бесплатный Note++ вполне подойдёт, при помощи блокнота лучше не открывать, там все в кучу сбивается, я использую Sublime Text 2). Находим в файле две следующие строки, которые нам надо поменять:
format(«MTD», «system»); mount(«MTD», «system», «/system»);
Меняем их на следующие строки:
format(«ext4», «EMMC», «/dev/block/mmcblk0p4», «0», «/system»); mount(«ext4», «EMMC», «/dev/block/mmcblk0p4», «/system»);
Важно: я специально выделил красным цветом самое важное. Это точка монтирования «system» на моём устройстве, на Lenovo A369i, для вашего устройства эти данные могут отличаться.
Поэтому, чтобы узнать какой блок у вас отвечает за «system», нам надо выполнить команду «dumchar_info» через adb, как это сделать написано более подробно здесь: Как получить dumchar_info (информация о блоках системы), читаем только первый пост и устанавливаем только adb драйвера и adb инструменты, остальное не надо.
Итак после того как вы получили данные из dumchar_info, посмотрите путь куда у вас смотнирован «android» (это и есть system в dumchar_info) и отредактируйте две строки в updater-sсript соответственно:
android 0x0000000028a00000 0x0000000004960000 2 /dev/block/mmcblk0p4
Важно: точку монтирования раздела можно получить без dumchar_info, а просто через MTK Droid Tools (нажмите на ссылку)
19. Всё, после того как вы отредактировали updater-sсript, закройте его и сохраните изменения. Теперь нам надо запаковать прошивку, просто возьмите и выделите все три файла прошивки и добавьте их в архив (обязательно zip архив, а не rar или 7z):
20. Почти всё, но не совсем. Далее пробуем прошивать прошивку через кастомное рекавери. Обязательно сначала сделайте в рекавери полный бэкап! . Если вылетает ошибка Status 0 или Status 1 , то, скорее всего у нас неправильный update-binary , который находится там же где и updater-sсript , то есть META-INFcomgoogleandroid . Поэтому пробуем менять update-binary и снова запаковывать прошивку и снова пробывать поставть.
Лучше всего взять update-binary из другой кастомной прошивки на ваше устройство, но если нету, я залил во вложений другие update-binary, которые должны подойти, пробуйте их. Вообще update-binary, это файл который трансформирует в понятные для системы команды, указания из updater-sсript, то есть указания по установке прошивки.
21. Всё, ваша первая кастомная прошивка на MediaTek устройство готова . Можно конечно еще было добавить root и busybox и еще чего в Android Kitchen, но я через эти пункты не шел, там все понятно в принципе в меню, если захотите добавите сами.
Источник: mdforum.su
Ошибки рекавери и их решение.
Status 0 — данный код ошибки возник из за того, что файл updater-script или update-binary отсутствуют в прошивке или обновлении
Status 255 — данный код ошибки возник из за того, что файл update-binary не подходит
В обоих случаях лечится одинаково, нужно взять update-binary из любой прошивки для вашего девайса
Status 1 — данный код ошибки возник из за того, что заданы неправильные пути монтирования разделов
Status 4 — данный код ошибки возник из за того, что архив прошивка либо архив-обновление рассчитаны на более раннюю версию СWM (там использовался updater-script без бинарника update-binary).
Status 6 — а) Обозначает что updater-scpript создан не в Unix формате, поэтому при установке Android не распознает что там написано и выдает ошибку Status 6. Для того чтобы это исправить советую скачать и установить NotePad ++ и поменять формат
Синтаксическая ошибка (пропущен какой-либо символ, например «;», пропущена буква в команде)
Status 7 — а) Прошивка не подходит для Вашего девайса и в updater-script прописано другое название модели. Открыть updater-script и удалить строки содержавшие название чужой модели и переподписать прошивку.
No space left on device — недостаточно места в прошиваемом разделе
Please upgrade to latest binary либо . binary — Файл update-binary не подходит, нужно взять update-binary из любой прошивки для вашего девайса.
Источник: lenovo-forums.ru