Как прошить android с meta inf

Зачем нужны, какие бывают и как ставить кастомные прошивки Android

Одна из сильнейших преимуществ смартов на Android — гибкость системы. Ее можно настроть под себя в самых широких пределах, да и заменить на альтернативную сборку. В этой статье разбираемся с видами ROM и особенностями их установки

Сегодня подавляющее число смартфонов работают на Android. И сколько критики не было бы в ее адрес, главное преимущество «зеленого робота» — открытость. А это безграничные возможности для производителей мобильных гаджетов, разработчиков программного обеспечения, да и самих пользователей. Открытый исходный код Android дает возможность модифицировать саму операционку — от графических элементов до изменения принципов функционирования системы под свои вкусы и требования. И практически каждая фирма производитель пользуется этим, примеры — TouchWiz от Samsung, Sense UI в HTC, MiUI у Xiaomi. Чистую ОС Android мы можем увидеть разве что в устройствах от Motorola и «гуглофонах» Nexus. А если вам не по душе официальная прошивка (как ее еще называют ROM), которая шла со смартфоном, вы можете выбрать одну из многих альтернативных. Правда, при условии, что они существует для вашего мобильного устройства.

Самая распространённая форма прошивки – это собранные и запакованные в zip архив компоненты операционной системы. Имя прошивки_номер версии_xxxxxx.zip – в таком виде мы видим файл прошивки чаще всего. Такой архив, как правило, состоит из таких компонентов:

• папка META-INF – в ней хранится информация о прошивке, включающая скрипты установки и обновления, сертификаты, манифест со списком файлов и их контрольными суммами;
• boot.img – ядро системы;
• папка system – самая интересная часть для разработчиков и любителей модифицировать прошивки. Ведь здесь находятся системные приложения, ресурсы системы, твики, конфигурации, настройки, шрифты, графика и многое другое. И даже без особых знаний любой пользователь может отредактировать эту часть – добавить свое приложение, шрифт, скрипт для оптимизации системы, изменить лаунчер, графику, настройки производительности.

Наиболее удобным и популярным способом установки кастомной прошивки является модифицированное рекавери – это загрузочный раздел, с помощью которого можно восстановить, обновить ОС, а также сбросить настройки и удалить данные. Они, в отличие от стоковых, обладают большим функционалом, а также позволяют прошивать кастомные ROM. Самыми известными модифицированными рекавери являються TWRP и ClockworkMod Recovery. Есть несколько способов их установки:

• Fastboot — утилита входящая в набор инструментов для отладки Android (ADB);
• RomManeger – приложение из Маркета;
• специальное ПО для компьютера – Odin для Samsung, SP Flash Tool – для смартфонов на SoC от Mediatek и другие.

В некоторых случаях нам будет необходим root – право на изменение некоторых настроек системы и полный доступ к файловой системе. При установке же посредством компьютера и программы прошивальщика рутирование устройства может произойти в процессе установки кастомного рекавери.

Нередко производитель блокирует загрузчик для того, чтобы пользователь не смог в процессе установки кастомных прошивок нанести вред смартфону. Для разблокировки в большинстве случаев вам понадобится инструменты ADB и специальный код, который вы сможете найти на на сайте разработчика.

После того, как наш смартфон получил новый раздел восстановления TWRP или ClockworkMod, процесс прошивки будет очень прост:

1. Перейти в режим восстановления — обычно требуется зажать одновременно клавиши питания и громкости + (или -) во время включения устройства.
2. Сделать полный Wipe — сброс к заводским настройкам, очистить кэш и далвик кэш, по желанию отформатировать систему (если важная информация на смартфоне отсутствует или предварительно сохранена).
3. Смонтировать внутреннюю или внешнюю память в рекавери и закинуть туда файл с прошивкой.
4. Зайти в меню прошивок, выбрать необходимый файл и запустить процесс установки.

Теперь давайте посмотрим, какие кастомные ROMы существуют, их плюсы и минусы.

CyanogenMod – сама распостраненный мод Android. Характеризуется широким выбором настроек и кастомизации системы, повышенной производительностью и стабильностью системы по сравнению с официальными прошивками. Основа команды CyanogenMod — это Стив Кондик (основатель проекта) и группа разработчиков с xda-developers. Они заявляют, что это прошивка от пользователей для пользователей. На ее базе создан коммерческий продукт Cyanogen OS, который в качестве предустановленной операционной системы используется в OnePlus One, YU Yureka, YU Yuphoria, Lenovo ZUK Z1, Wileyfox Swift, Wileyfox Storm. Последняя версия CM 13.0 основана на Android 6.0 Marshmallow.

Основные преимущества:

• удобный и красивый интерфейс;
• наличие большого количества тем, собственный магазин;
• встроенный эквалайзер;
• поддержка продвинутых жестов;
• настройки по оптимизации системы, например, повышение и понижение частоты процессора; профиля для быстрого изменения настроек;
• продвинутые функции безопасности — Privacy Guard (контролирует доступ приложений к функциям системы), клиент OpenVPN, SSH.

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

MIUI – изначально разработана для смартфонов фирмы Xiaomi, но стала такой популярной, что была портирована для большого количества мобильных устройств. Основатель Xiaomi Tech Лэю Цзюню очень импонировала продукция Apple, ее симбиоз аппаратной и программной части. На этих принципах и была построена MIUI. Она вобрала в себе все самое лучшее из Android, CyanogenMod и iOS.

Основные преимущества:

• плавность работы интерфейса;
• дружелюбность к пользователю;
• множество тем и прочих украшательств, свой магазин;
• встроенный системы резервирования, очистки системы, черный список, запись звонков, антивирус;
• свое облачное хранилище и синхронизация с ним;
• функции безопасности – контроль приложений, интернет-трафика;
• функциональный экран блокировки;
• частые обновления;
• отличная оптимизация работы смартфона (Xiaomi) и операционной системы.

К особенностям MIUI, которые не всем по душе, можно отнести отсутствие меню приложений и сильно отличающийся от гугловского Android дизайн (ранее напоминат скевоморфную iOS, теперь просто довольно пестрый). Основным недостатком стоит назвать наличие только китайской и английской официальных версий. А также ориентацию некоторых встроенных сервисов на Китай. Благо, есть на нашей земле умельцы, которые делают прекрасные локализации операционки. Это команды MultiROM, Miuipro, MIUI.su. На их сайтах вы всегда можете скачать свежую локализированную сборку и не только для смартфонов Xiaomi.

ParanoidAndroid. Прошивка основана на CyanogenMod и выделяется гибкой кастомизацией. Не такая популярная, как две предыдущих, но имеет немало поклонников. Официально поддерживаемые устройства — смартфоны от Samsung (Galaxy и Note), Nexus, Oppo, OnePlus. Существуют также неофициальные прошивки для других девайсов.

Основные преимущества:

• настройки внешнего вида любого элемента системы, включая размер, масштабирование, цветовую схему;
• Pie Controls – удобная навигационная панель; удобный планшетный интерфейс на смартфоне.

Также на просторах интернета вы можете найти еще много некоммерческих кастомных прошивок – AOKP, Slim Bean, PAC-man ROM. Это в основном разработки от команд-энтузиастов и самих пользователей. У некоторых китайских производителей смартфонов существуют свои кастомизированые прошивки, например, Flyme OS для Meizu, ColorOS – Oppo, Lewa – Huawei.

Среди такого количества модов Android каждый пользователь может найти то, что ему по душе!

Бесшовные A/B-обновления в Android: как они устроены

Всем привет. В SberDevices наша команда занимается разработкой различных железок и прошивок для них на базе AOSP.

Начиная с Android 8 (у некоторых вендоров с 7.1) в системе появился новый механизм накатки OTA-обновлений, т. н. Seamless A/B OTA Updates — бесшовные обновления. В этом посте я опишу общие принципы его работы, рассмотрю механизм с точки зрения разработчика, а также проведу сравнение со старым (будем его называть recovery-based) подходом применения обновлений. Всё нижесказанное будет справедливо только для чистого AOSP, т. к. конкретная реализация зависит от вендора.

Recovery-based OTA

Обновления для Android поставляются в виде zip-архива с образами обновляемых разделов (block-based updates). Во времена KitKat это был просто набор файлов, которые копировались на устройство прилагаемым скриптом. Я не стану подробно останавливаться на этом режиме, кратко опишу основные принципы его работы:

• zip-архив скачивается системой на устройство;
• система перезагружается в режим recovery;
• проверяется совместимость обновления с устройством, его подпись;
• если всё OK, выполняется updater-script из zip-архива;
• в процессе обновления устройство может несколько раз перезагрузиться (например, для обновления device tree);
• если всё прошло успешно, загружаемся в новую прошивку.

• Необходимость резервировать достаточное количество встроенной памяти для OTA-архива. Для этого служит раздел /cache. Некоторые вендоры используют /data, но это редкость. В итоге пользователю остаётся меньше места (да, приложения всё ещё могут использовать место в разделе /cache, но с некоторыми ограничениями).
• Перезагрузка и применение обновления занимает время, что может быть критично для некоторых видов устройств, например, для Smart TV.
• Прерывание процесса обновления может привести к boot loop.
• Нет возможности откатиться на старую версию прошивки.

Seamless A/B OTA

Ключевые компоненты и механизмы, необходимые для реализации бесшовных A/B-обновлений:

• слотовая разметка флеш-памяти;
• взаимодействие с загрузчиком, управление состоянием слотов;
• системный демон update_engine;
• генерация zip-архива с обновлением. В рамках данной статьи этот аспект рассматриваться не будет.

Слотирование

Основным принципом работы A/B OTA является слотирование. Все разделы, которые необходимо обновлять (это могут быть любые разделы, а не только системные), должны находиться в двух копиях или, иначе, в слотах. В Android-реализации поддерживается 2 слота, которые именуются соответственно A и B. Система загружается и работает из текущего слота, второй используется только в момент обновления. К имени раздела добавляется суффикс с именем слота.

Ниже приведена таблица сравнения двух вариантов организации разделов на устройстве.

Все слотируемые разделы помечаются опцией монтирования slotselect, чтобы система могла выбрать правильный слот. В зависимости от того, где они описаны, это может быть fstab либо dts.

Изменения в таблице разделов

• В /сache больше нет необходимости. Теперь обновление может сохраняться либо в /data, либо сразу прошиваться в неактивный слот (об этом ниже).
• Раздел recovery также больше не используется. Однако режимrecovery всё ещё существует, он необходим, например, для сброса устройства на заводские настройки (к этому может привести rescue party). Или для т. н. ручного обновления (sideload) через adb. Recovery ramdisk теперь лежит внутри boot-раздела, ядро общее.
• Для переключения режима загрузки (android/recovery) появилась новая опция в cmdline ‑ skip_initramfs.

Главным достоинством A/B-обновлений является возможность стриминга прошивки. Именно она обеспечивает бесшовность и прозрачность обновлений для пользователя: для обновления устройству достаточно перезагрузиться в новый слот. В этом режиме нет необходимости заранее скачивать zip-архив, занимая место в /data. Вместо этого система сразу пишет блоки данных из специально подготовленного файла (payload, см. ниже) в каждый раздел неактивного слота. С точки зрения реализации нет разницы, скачиваем ли мы предварительно обновление либо сразу стримим его в слот.

Слоты имеют следующие состояния:

• active – активный слот, из него будет загружена система при следующей перезагрузке;
• bootable – обновление успешно прошито в слот, прошло валидацию, совпали хеш-суммы и т. д.;
• successful – система смогла успешно загрузиться в новый слот;
• unbootable – слот поврежден. Система всегда помечает слот как unbootable перед началом процесса обновления.

Алгоритм работы загрузчика при выборе слота:

• Загрузчик определяет, что имеется один или более слотов с флагом bootable.
• Из них выбирается активный слот (либо слот с наибольшим приоритетом).
• Если система загрузилась успешно, слот помечается как successful и active.
• Иначе слот помечается как unbootable и система перезагружается.

Изменение состояний слотов во время обновления:

Необходимые компоненты для работы с Seamless A/B.

boot_control

Для поддержки A/B-обновлений вендор должен реализовать специальный HAL-интерфейс — boot_control. Он позволяет изменять состояния слотов и получать о них информацию. Для внешней работы (например, через adb shell) используется утилита – bootctl. Интерфейс используется как средство взаимодействия между ОС и загрузчиком.

update_engine

Основной компонент всей A/B-схемы. Занимается загрузкой, стримингом обновлений, проверкой подписи и многим другим. Изменяет состояния слотов через boot_control. Позволяет контролировать процесс обновления устройства: приостанавливать, возобновлять, отменять.
Компонент пришёл в Android из ChromeOS, где уже используется некоторое время. AOSP поддерживает update_engine в виде статической sideload-сборки. Именно она используется в recovery, т.к данный режим не поддерживает динамическую линковку.

Процесс работы данного компонента можно разделить на следующие шаги:

• загрузка обновления в слот. Загружать можно как из предварительно скачанного пакета с обновлением, так и напрямую по Сети через http/https. В процессе загрузки проверяется подпись, открытый ключ уже находится на устройстве (/system/etc/update_engine/update-payload-key.pub.pem);
• верификация загруженного обновления и сравнение хеш-сумм;
• выполнение post-install скриптов.

2009-01-01 00:00:00 . 360 360 META-INF/com/android/metadata 2009-01-01 00:00:00 . 107 107 care_map.txt 2009-01-01 00:00:00 . 384690699 384690699 payload.bin 2009-01-01 00:00:00 . 154 154 payload_properties.txt 2009-01-01 00:00:00 . 1675 943 META-INF/com/android/otacert

• care_map.txt — используется update_verifier-ом (см. ниже);
• payload_properties.txt — содержит хеши и размеры данных внутри payload;
• payload.bin — пакет обновления, содержит блоки всех разделов, метаданные , подпись.

update_engine_client

Клиент для управления демоном update_engine. Может напрямую вызываться вендором для применения обновления.

update_verifier

Утилита для проверки целостности системы при первом запуске (слот с флагом active, но еще не successful). Контроль целостности реализуется с помощью модуля ядра dm-verity. Если проверка закончилась успешно, утилита помечает текущий слот как successful. Иначе система перезагружается в старый слот. Верифицируются только блоки, указанные в файле care_map.txt.

UpdateEngineApi

Для реализации vendor-сервисов обновлений существует Java API. Также имеется пример реализации такого сервиса.

Рассмотрим пример сборки A/B update в AOSP. Для этого отредактируем Makefile целевой платформы:

#Включим поддержку A/B AB_OTA_UPDATER := true #Укажем необходимые разделы для слотирования: AB_OTA_PARTITIONS := boot system vendor #Добавим необходимые пакеты PRODUCT_PACKAGES := update_engine update_engine_client update_verifier #Отключим раздел recovery TARGET_NO_RECOVERY := true #Убедимся, что НЕ определяются переменные для раздела cache: #BOARD_CACHEIMAGE_PARTITION_SIZE := . #BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := . 

После вызова make otapackage получаем zip-архив с обновлением. В таком виде он уже подходит для sideload-режима. Можем выполнить перезагрузку в recovery и вызвать adb sideload ota.zip. Этот способ удобен для отладки.

Применение обновления изнутри рабочей системы обычно определяется вендором. Самый простой способ — выложить payload.bin на http-сервер и напрямую вызвать update_engine_client.

update_engine_client \ --payload=http://path/to/payload.bin \ --update \ --headers=" \ FILE_HASH=ozGgyQEddkI5Zax+Wbjo6I/PCR8PEZka9gGd0nWa+oY= \ FILE_SIZE=282344983 \ METADATA_HASH=GLIKfE6KRwylWMHsNadG/Q8iy5f786WTatvMdBlpOPg= \ METADATA_SIZE=26723"

В параметр headers передается содержимое файла payload_properties.txt. В logcat можно наблюдать прогресс обновления. Если передать ключ —follow, прогресс будет дублироваться в stdout.

Заключение

Плюсы нового механизма обновлений очевидны:

• обновление системы происходит в фоне, не прерывая работу пользователя. Да, всё так же потребуется перезагрузка (в новый слот), но пройдёт она значительно быстрее, чем перезагрузка в recovery для применения обновления;
• минимизируется вероятность boot loop (от ошибок в реализации никто не застрахован). Процесс обновления можно прерывать, на активный слот это никак не повлияет;
• появляется возможность отката на предыдущую версию прошивки. Даже если по каким-то причинам обновление прошло неуспешно, система просто вернётся к старой версии;
• благодаря стримингу устройство обновится быстрее;
• в зависимости от реализации можно полностью исключить пользователя из процесса обновления.

• A/B OTA становится зависимой от текущей разметки диска, т. к. обновление происходит во время работы системы. Т. е. становится невозможно накатить обновление с изменёнными разделами;
• относительная сложность реализации.

Как прошить android с meta inf

Редактирование Updater-script. Информация, решения, команды, подпись патчей.
Инструкция по установке системных и пользовательских приложений с помощью recovery
Редактирование установленной прошивки и удаление системных приложений
(ключевые слова)

Напоминаю, тут не стол заказов.. Посты с просьбой собрать zip для «хххх» Recovery оффтоп

Сообщения, не относящиеся к теме обсуждения (оффтоп), удаляются без предупреждения

• Добавление нескольких пользовательских/системных приложений «за один клик» (одним патчем).
• Добавление/удаление системных приложений без root прав и вспомогательных программ.
• Изменение прошивки (замена файлов, украшательства и т.д.).
• Обновление программы или прошивки.
• Переразметка памяти (обсуждения в другой теме)
• Получение root прав SuperUser, SuperSU, Magisk

1. Установленный на телефоне кастомный рекавери (CWM/TWRP)
   (редактор с сохранением Unix формата)
2. Zip_signer (подписчик архивов)
3. Файл-заготовка sample.zip (либо update-binary для ручной сборки)
   Zip_signer.rar ( 13,28 КБ )
   sample-patch.rar ( 4,77 МБ )
   update-binary.rar ( 113,25 КБ )
4. Дополнительные версии бинарника. binary_all.rar ( 649,36 КБ )
5. Бинарники (архив/исходники)

Исходники бинарника, основная ссылка:
https://android.google…ootable/recovery/+refs
выбираем к примеру «android-9.0.0_r18» , потом ищем папку «updater», в папке «updater» исходники бинарника

К примеру https://android.google…droid-9.0.0_r18/updater — можно глянуть все команды которые может выполнить бинари в андроид 9.0.0 (в файле install.cpp, в самом низу)

1. Собрать свой update.zip (из заготовки sample.zip)
2. Подписать update.zip утилитой Zip_signer(Не обязательно!)
3. Закинуть на флэшку и установить в аппарат через ClockWorkMod Recovery

1. Разархивировать архив sample.zip
2. Удалить файлы подписи META-INF/CERT.RSA, CERT.SF, MANIFEST.MF (т.к. 2м шагом мы их будем создавать для своей сборки)
3. Поместить в папку /data/app свое пользовательское приложение (xxxxx.apk)
4. При необходимости отредактировать файл updater-script (подробнее позже)
5. Заархивировать всё (META-INF и data) ZIP’ом без сжатия

1. Переименовать Ваш отредактированный (т.е. уже с приложением внутри) sample.zip в update.zip
2. Поместить его в папку с программой Zip_signer
3. Запустить файл zip_signer.bat
4. Дождаться, пока процесс будет завершен
5. В папке появится файл update-finished.zip — это и есть подписанный файл
6. Переименовать update-finished.zip по своему усмотрению (согласно логике патча)

1. Перекинуть (переименованный) update-finished.zip на флэшку и установить его в аппарат через TWRP или CWM (install zip from sdcard -> chooze zip from internal sdcard -> Yes, install sample.zip)
2. Перезагрузить аппарат

• Скачиваем signapk.zip и разархивируем в папку
• Назначаем права для всего содержимого — «rwxrwxrwx» (chmod -R 777

Внимание! Патчи создаются только для мод.рекавери и результативно работают только в них. В стоковых рекавери (на аппаратах «из коробки») патчи не работают.

• папка META-INF
• папка источник установки приложений (system, data, sdcard, cache, sd-ext)
  Обязательные файлы:
• META-INF/com/google/android/update-binary — системное средство запуска данного патча, также создает временную рабочую папку tmp
• META-INF/com/google/android/updater-script — выполняемый скрипт по которому и происходят операции копирования и т.д.

Разберем sample.zip
Патч добавляет пользовательское приложение MyPiano в Data.

• package_extract_dir
Синтаксис: package_extract_dir(«», «»);
Копирует содержимое в . Файлы в имеющиеся в перезаписываются.
Пример: package_extract_dir(«system», «/system»); Скопирует файлы из папки update.zip/system в /system

• package_extract_file
Синтаксис: package_extract_file(«», «»);
Копирует файл в . Если файл существует, то он перезаписывается.
Пример: package_extract_file(«test.sh», «/tmp/test.sh»); Скопирует файл test.sh из update.zip в /tmp/test.sh

• format
Синтаксис: format(«MTD», «»);
Форматирует раздел (см. приложение).
Пример: format(«MTD», «system»); Полностью отформатирует /system . Примечание: форматирование удаляет данные необратимо.
Пример 2: format(«ext4», «EMMC», «/dev/block/mtdblock5», «0», «/system»);
Определение номера блока под спойлером «инфо и материалы».

• delete
Синтаксис: delete(«»[, «file2», . «fileN»]);
Удаляет файл(ы)
Пример: delete(«/system/app/Calculator.apk»); Удалит Calculator.apk из папки system/app.

• delete_recursive
Синтаксис: delete_recursive(«»[, «dir2», . «dirN»]);
Рекурсивно удаляет папку(и) со всем содержимым
Пример: delete_recursive(«/data/dalvik-cache»); Удалит папку /data/dalvik-cache со всем содержимым.

• run_program
Синтаксис: run_program(«»[, «», «», «»]);
Запускает программу(скрипт) .
Пример: run_program(«/tmp/install_busybox.sh»); Запустит скрипт /tmp/install_busybox.sh.

• set_perm
Синтаксис: set_perm(, , , «»[, . «pathtofileN»]);
Устанавливает владельца, группу и разрешения для файла или папки, как ‘chmod’, ‘chown’, и ‘chgrp’ всё в одном
Пример: set_perm(0, 2000, 0550, «/system/etc/init.goldfish.sh»); Установит владельца, группу и разрешения для файла /system/etc/init.goldfish.sh

• set_perm_recursive
Синтаксис: set_perm_recursive(, , , , «»[, . «»])
Рекурсивно устанавливает владельца, группу и разрешения для содержимого папки. — для папок, — для файлов.
Пример: set_perm_recursive(0, 0, 0755, 0644, «/system/app»); Установит права для содержимого /system/app, для папок — 0755, для файлов — 0644.

• show_progress
Синтаксис: show_progress(, );
Продвижение прогрессбара на долю за секунд. может быть нулевым для продвижения его по командe set_progress, а не по времени.
Пример: show_progress(0.100000, 1); Увеличит прогресс на 0.1 часть за 1 секунду

• set_progress
Синтаксис: set_progress();
Устанавливает положение прогрессбара на долю , для самого последнего вызова команды show_progress.
Пример: set_progress(0.500000);

• symlink
Синтаксис: symlink(«», «», «»]);
Создает символическую ссылку (как ‘ln-s’). пишется в формате root:path, а в формате целевой файловой системы (и может быть относительным). Википедия Symlink.
Пример: symlink(«/data/app_s», «/system/app»); Создаст символическую ссылку на папку /data/app_s для папки /system/app

• mount
Синтаксис: mount(«», «», «»);
Монтирует в путь . должно быть название раздела, если это «MTD», или блок памяти если это «vfat»
Пример: mount(«MTD», «userdata», «/data»);

• unmount
Синтаксис: unmount(«»);
Отключает .
Пример: unmount(«/data»);

• ui_print
Синтаксис: ui_print(«»);
Выводит на экран сообщение
Пример: ui_print(«Formatting SYSTEM. «);

• sleep
Синтаксис: sleep();
Пауза процесса на секунд
Пример: sleep(5); — пауза 5 секунд, после чего код скрипта выполняется дальше.

• set_metadata / set_metadata_recursive
Синтаксис: set_metadata (. );
Устанавливает владельца, группу и разрешения (новая команда взамен set_perm для andriod 4.4.*)
Примеры: Android update-script (Пост #32151495)
Создание патча update.zip для прошивки через рекавери (Пост kory-vadim #81945464)

• set_metadata / set_metadata_recursive
Синтаксис:
set_metadata(«имя файла», «ключ1», «значение1», «ключ2», «значение2», . )
set_metadata_recursive(«имя директории», «ключ1», «значение1», «ключ2», «значение2», . )
Ключи:
* uid
* gid
* mode (set_perm_extd only)
* fmode (set_perm_extd_recursive only)
* dmode (set_perm_extd_recursive only)
* selabel
* capabilities
первые три (uid, gid, mode) это тоже самое что и в chmod, заполняется «uid», 0, «gid», 1000, «mode», 06754.
для установки прошивки хватает трех ключей «uid», 0, «gid», 1000, «mode», 06754.
Пример: set_metadata(«/system/xbin/shelld», «uid», 0, «gid», 1000, «mode», 06754, «capabilities», 0x0, «selabel», «u:object_r:system_file:s0»);
set_metadata_recursive(«/system/xbin», «uid», 0, «gid», 2000, «dmode», 0755, «fmode», 0755, «capabilities», «0x0», «selabel», «u:object_r:system_file:s0»);

• команды для Nexus’ов
block_image_update(«/dev/block/platform/msm_sdcc.1/by-name/system», package_extract_file(«system.transfer.list»), «system.new.dat», «system.patch.dat»);
Синтаксис: block_image_update(«Путь к блоку раздела», package_extract_file(«список информации для патча (?) «), «образ», «патч образа»);
я так понимаю, что так прошивается сильно сжатая прошивка (образ системы).
Еще ifelse
Пример: ifelse(is_mounted(«/system»), unmount(«/system»)); — если раздел сустем смонтирован дается команда на его размонтирование, если размонтиовать то нечего не происходит.

• Информация по атрибутам set_metadata и подобным командам на Android 4.4+
Android update-script (Пост blackeangel #50803606)
Описание откуда берутся «u:object_r:uncrypt_exec:s0» и подобные атрибуты. . .

• Пример скрипта который может удалять\перемещать\бекапить файлы и вести лог действий
Android Script Creator (Пост Octanium #51085030)

• Временный Busybox

Используется при отсутствии busybox, либо чтоб не привязываться к его расположению в системе.

Как прошить android с meta inf

Инструкция будет короткая и простая, сейчас вы в этом убедитесь сами.

Обычно, большинство прошивок сделаны для FlashTool, и порой неудобно прошивать их через PC. Например у одних возникает проблема с установкой драйверов, у других просто нет желания так прошивать, но не суть. Перейдем к делу.

1) Первое что нужно сделать, это скачать прошивку естественно.
2) Открываем ее WinRar'ом или 7ZIP'ом, и видим примерно такую картину:

Разработка и модификация прошивки для Android телефонов на примере HTC Hero GSM. Часть 1

Стоит учитывать, что в распакованном архиве содержатся символические ссылки, которые будут утеряны на файловых системах не поддерживающих оные (fat/ntfs). Которые мы можем восстановить через скрипт обновления, о чем будет рассказано в другой статье.

Также нам понадобиться boot-раздел, который по сути является linux ядром (для выбранной прошивки это 2.6.29 armv6l) с ramdisk-ом и имеет следующий формат:

Похожие публикации:

1. Что подключается в meta html
2. Что такое meta в html
3. Что такое кодировка страницы в html meta
4. Как прошить android

How to Extract META-INF from Stock ROM

Hi,
I am new in Android Development.
Question : The exact way to extract META-INF from Stock ROM & its Location in Stock ROM.
I searched many forums & read many posts but cannot find a way to extract META-INF from Stock ROM.
I even cannot find folder name META-INF in Stock ROM.
I have uploaded Snapshot of files in Stock ROM for GT-S6312. As we can see there are total 11 Files & Folders:
.disk
boot
efi
isolinux
[BOOT]
initrd.img
install.img
kernel
ramdisk.img
system.sys
TRANS.TBL

Droidriven

Senior Member

Jan 27, 2014 16,173 14 5,596 NC Verizon Samsung Galaxy S III HTC Thunderbolt

Hi,
I am new in Android Development.
Question : The exact way to extract META-INF from Stock ROM & its Location in Stock ROM.
I searched many forums & read many posts but cannot find a way to extract META-INF from Stock ROM.
I even cannot find folder name META-INF in Stock ROM.
I have uploaded Snapshot of files in Stock ROM for GT-S6312. As we can see there are total 11 Files & Folders:
.disk
boot
efi
isolinux
[BOOT]
initrd.img
install.img
kernel
ramdisk.img
system.sys
TRANS.TBL

META-INF is typically part of a flashable zip that is meant to be flashed in recovery such as custom ROMs, Gapps and other flashable zips, they are not part of a stock firmware file. META-INF can be found in a flashable zip by extracting the whole zip and you’ll see the META-INF.

If you’re trying to port a ROM and the guide you’re following mentions META-INF then that guide is probably for porting preexisting custom ROMs and not for porting a stock ROM.

Take a step back, read everything, get your head straight and make sure you understand what you’re doing, I think you’ve overlooked something because you’re using the wrong files for what you’re trying to do.

I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS FOR EVERYONE TO SHARE