vendor image что это

Vendor image что это

1)Root права
2)Root explorer
3)мозги
4)наличие рекавери для Вашего телефона. (стоковое подойдет)

Берём чужой образ рекавери, переименовываем его в recovery.img, копируем в папку /data/boot_unpacked. Далее щелкаем по скрипту unpackR.sh, выбираем выполнение, дожидаемся окончания.
Ура, теперь Кастомное рекавери распаковано. Меняем имя папки recovery_unpacked на любое другое и забываем про него.
Берём стоковое рекавери, меняем имя на recovery.img, кладем в папку со скриптами, распаковываем. Заходим в папку с ним recovery_unpacked/ramdisk_unpacked/etc сохраняем оттуда файл recovery.fstab на КАРТУ ПАМЯТИ. Теперь меняем папку ramdisk_unpacked из чужого рекавери в Ваше. Из своего рекавери эту папку предварительно удалите.
Теперь идем обратно, к скриптам, используем скрипт packR. Получившийся файл устанавливаем. Если рекавери запустилось, идем дальше, нет-слишком большое, надо искать что-либо поменьше, или посмотреть в спойлер ниже

Помним файл recovery.fstab скопированый на карту памяти? Берём его, открываем, переписываем пути к разделам куда-нибудь на листочек. Теперь идем в папку со скриптами, заходим в папку recovery_unpacked/rmdisk_unpacked/etc, открываем файл recovery.fstab и сравниваем его содержимое с тем что на листочее. И либо меняем его, либо если все одинаковое выходим. Еще раз собираем рекавери и все..

Далее нам нужны еще
4.Стоковый boot.img
5.Карта блоков (нижу опишу как ее получить)
6.Донор рекавери (желательно чтоб разрешение экрана было ниже вашего или соответствовало, процессор должен ОБЯЗАТЕЛЬНО быть такой же как у вас)

Самый легкий способ это через MTK Droid Tools
1.Запускаем MTK Droid Tools
2.Включаем на телефоне откладку по USB
3.Втыкаем его в комп, ждем установки драйверов (если не установлены)
4.После того как появился тел в Дроид тусле кликаем на кнопочку КАРТА БЛОКОВ

Второй способ посложнее, в основном для тех кто «шарит», но результат тот же
В терминале или adb shell пишем

И получаем что-то типо этого. В терминале перед командой не забываем прописать

[color=»#000000″]Буду показывать на примере моего тела (MFLoginPH MTK6582), так что для каждого тела может быть по-разному
1.Кидаем на рабочий стол стоковый boot и переименовываем его в boot.img
2.Кидаем на рабочий стол рекавери донора и переименовываем его в recovery.img
3.Заходим в MTK Droid Tools (Тело не подключаем)
4.Заходим во вкладку root,backup,recovery
5.Находим кнопочку Recovery and Boot и ставим рядом с ней галочку на «Выбрать файл Boot.img»
6.Нажимаем на саму кнопку и затем указываем путь сначала к boot.img, затем к recovery.img
7.Вводим модель телефона (Тут без разницы)
8.Ждем пока создастся рекавери (может написать что не подходит по размеру, это не важно)
9.Теперь идем в папку с MTKDriodTools, далее папка recovery и там должен лежать файлик типо «MFLoginPH_recovery_150607-133528», главное чтоб в названии было recovery

На этом мы закончили «быстрое» портирование рекавери, это еще не все. Конечно способ не для опытных, в основном ориентирован для новичков

Теперь «MFLoginPH_recovery_150607-133528» переносим в папку с «Boot_Recovery_Repack_Util_v4_win7-8_x64», буду называть его «репаком»

Наш файл переносим (удерживая левой кнопкой мыши) на батник «MTK_unpack» И ждем, затем когда все надписи пройдут, нажимаем любую кнопку
В созданной папке идем по пути rmdisk>etc>recovery.fstab (в старых twrp может называться типо «twrp.fstab») и открываем этот файлик с помощью Notepad++

Видим разделы system cache data и пути к ним «/dev/block/mmcblk0p7» для data в данном случае, нам нужно подправить их чтоб они были так же как в нашей карте блоков

После того как подправили все что нужно в Notepad++ сверху где написано recovery.fstab нажимаем на крестик и сохраняем

Теперь попробуем запустить наше recovery, заходим в папку репакера и всю нашу папку «MFLoginPH_recovery_150607-133528» переносим на батник MTK_pack, дожен появится файлик new_image, это и есть наше рекавери
После тестов обычно должна быть проблема с sd картой или внут.памятью, внут. память я не знаю как чинить (на моем теле не знаю, а на других обычно на карте блоков видно или путь к ней /dev/block/mmcblk0p8 или универсальный /[email protected]) (может кто подскажет, ну ее вообще закрыл (для twrp))
Закрыть память так
Везде где написано /emmc перед ними ставим #, т.е. как на скрине выше, должно получится примерно так

SD карта если не видит то пишем такой путь, для 6582 обычно такой, но для других тоже должно пойти

Если у вас сразу проблем не было, то отлично
Если не выйдет разбираем стоковое рекавери репакером и смотрим там
Все писал на примере TWRP, на cwm немного по другому, но суть та же

Лучше написать гайд не смог, постарался сделать так чтоб каждый смог портировать рекавери, + я еще не имел дело с другими процами (не 6582), но отличий наверно нет. Пишите в лс что подправить
Если есть какие притензии к инструкции, то сразу пишите какие, чтоб подправить.

Источник

Как исправить невозможность смонтировать хранилище в TWRP Recovery

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

Единственное требование — разблокировать загрузчик устройства. Как только вы этого добьетесь, вы сможете запустить множество пользовательских двоичных файлов, модов, пользовательских ПЗУ и даже Magisk для рутирования вашего устройства. Однако стандартное восстановление не может установить эти файлы. Вам нужно будет установить кастомное рекавери, например TWRP.

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

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

Причина невозможности смонтировать хранилище в TWRP

Первая причина, по-видимому, связана с тем, что внутреннее хранилище вашего устройства зашифровано. В результате TWRP не может расшифровать его на ходу и, следовательно, не может получить доступ к файлам, хранящимся на вашем устройстве.

Это причина, по которой эта ошибка чаще всего возникает, когда вы собираетесь прошить файл с помощью этого восстановления.

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

Читайте также: Что такое латка одежда

Но не волнуйтесь, это не так, и ваши данные на данный момент могут быть все еще нетронутыми. Итак, с учетом сказанного, вот различные методы исправления невозможности монтировать хранилище в TWRP Recovery.

Как исправить невозможность смонтировать хранилище в TWRP Recovery

Мы поделимся тремя разными способами решения этой проблемы. Следуйте инструкциям в том же порядке, как указано. Просто убедитесь, что ваше устройство уже загружено в TWRP. Е

Исправление 1: удалить экран блокировки

Если вы используете графический ключ на своем устройстве, TWRP не сможет его расшифровать. Рекомендуется переключиться на пин-код или пароль.

Теперь попробуйте прошить нужные файлы и посмотрите, исправлена ли проблема с невозможностью монтировать хранилище в TWRP Recovery.

Исправление 2: восстановить или изменить файловую систему

Вы также можете попробовать восстановить или изменить файловую систему вашего устройства. Все это можно было сделать прямо из самого TWRP.

Убедитесь, что вы по-прежнему получаете сообщение об ошибке «Невозможно смонтировать хранилище при восстановлении TWRP».

Исправление 3: форматирование внутренней памяти

Убедитесь, что вы создали эту резервную копию на SD-карте или USB OTG, а не в памяти телефона, так как мы собираемся полностью стереть этот раздел. Когда вы закончите резервное копирование, выполните следующие действия.

Мы поделились тремя разными методами для одного и того же, дайте нам знать, какой из них сработал за вас.

Источник

Vendor image что это

1)Root права
2)Root explorer
3)мозги
4)наличие рекавери для Вашего телефона. (стоковое подойдет)

Второй способ посложнее, в основном для тех кто «шарит», но результат тот же
В терминале или adb shell пишем

И получаем что-то типо этого. В терминале перед командой не забываем прописать

Теперь «MFLoginPH_recovery_150607-133528» переносим в папку с «Boot_Recovery_Repack_Util_v4_win7-8_x64», буду называть его «репаком»

После того как подправили все что нужно в Notepad++ сверху где написано recovery.fstab нажимаем на крестик и сохраняем

SD карта если не видит то пишем такой путь, для 6582 обычно такой, но для других тоже должно пойти

Источник

Кастомный Android: делаем свою прошивку из стоковой, не копаясь в исходниках

Содержание статьи

Начнем с того, что тебе нужен Linux. В Windows ты сможешь только разобрать прошивку, но собрать обратно уже не получится по чисто техническим причинам. Теперь о прошивке. Обычно они распространяются в виде ZIP-архивов, прошиваемых через кастомные рекавери. Именно один из них нам и понадобится для опытов. Начинать путь ромодела я рекомендую с какой-нибудь максимально приближенной к AOSP кастомной прошивки, потому что в ней зачастую проще разобраться, чем в стоке.

Нужный ZIP можно найти на XDA Developers или 4PDA. Но имей в виду, что нужна прошивка конкретно для твоей модели аппарата, — у того же Galaxy S7 есть несколько модификаций для разных рынков, не всегда совместимых между собой.

Структура ZIP-файла с прошивкой

После загрузки распакуем архив с помощью любого архиватора. Внутри будет следующий набор файлов и папок:

Реверс малвари

Распаковываем system.new.dat

Файлы system.new.dat и system.transfer.list представляют для нас наибольший интерес. Точнее, не они, а содержащаяся в них система. Но добраться до нее не так просто.

Скрипт

Самые ленивые могут разобрать прошивку с помощью скрипта System_Extractor-Linux.

Ручной способ

Распаковываем архив с прошивкой в любую папку (например, в rom ):

Скачиваем нужные нам инструменты в эту папку:

Содержимое образа system

Структура каталогов Android

После распаковки system появится следующая каталоговая структура:

Ознакомившись с базовой структурой Android, начнем вносить изменения.

Удаляем и добавляем приложения

Все предустановленные программы можно найти в двух папках:

Друг от друга они отличаются привилегиями доступа. Если программы из app имеют такие же полномочия, как сторонние программы (например, установленные из Play Store), то приложения из priv-app могут использовать привилегированные API (права privileged). Подробнее об этом можно узнать из нашей статьи.

Главное, помни: стоковые программы могут быть связаны между собой. Поэтому удаление одной проги вполне может привести к полной неработоспособности другой (к примеру, CalendarProvider и Calendar: удалив первый, ты сделаешь неработоспособным не только стоковый, но и любой другой календарь). К счастью, в чистых AOSP-прошивках взаимосвязей не так много.

Меняем анимацию загрузки

Анимация хранится в виде PNG-картинок, упакованных в архив /system/media/bootanimation.zip без сжатия. Внутри архива находятся:

Файл desc.txt может содержать нечто вроде

Назначение этих строк интуитивно понятно: 1920 × 1080 — разрешение картинки, 60 — число кадров в секунду. Part0 и part1 указывают на папки, из которых будет воспроизводиться анимация, и последовательность воспроизведения. Вообще, может быть как одна часть, так и несколько (три и больше).

Четыре части в bootanimation.zip для LineageOS

Изменяем звуковое оформление

В alarms, notifications, ringtones можно накидать сколько угодно любых мелодий. Взять их можно, например, здесь:

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

Добавляем шрифты

Меняем системные настройки (build.prop)

Дополнительный файл для Gigaset ME и ME Pro

Build.prop содержит (или может содержать) огромное количество настроек. Некоторые из них ничего не меняют, некоторые улучшают одно за счет ухудшения другого, но есть те, которые действительно полезны:

Внедряем в прошивку Google Apps

Почти всегда кастомные прошивки поставляются без сервисов Google и магазина приложений. Разработчики предлагают нам установить их отдельно с помощью пакета GApps. Однако его можно интегрировать прямо в прошивку.

Для начала необходимо скачать пакет GApps. Я рекомендую брать архивы Open GApps. Выбираешь версию Android, архитектуру процессора и вариант комплектации (Pico, Nano, Stock. ), который определяет, сколько различных приложений Google содержит архив. Я рекомендую скачать версию Pico. Она содержит только Play Store и набор необходимых для его работы библиотек.

Интеграция GApps в прошивку выполняется так:

Свободное место

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

Инфа о разделе system

Второй вариант: поставить на устройство терминал и набрать команду

Размер раздела в байтах можно узнать, установив на смартфон BusyBox и выполнив в терминале команду

Или то же самое с помощью ADB:

Место, занимаемое прошивкой, будет приблизительно равно размеру system в распакованном виде. Вообще, при создании прошивки необходимо учитывать, что юзер также может прошить поверх нее различные модификации (SuperSU, Xposed) или перенести приложения в раздел system. Например, минимальный пакет приложений Google (Pico) требует минимум 150 Мбайт дополнительного пространства для установки.

Сборка

Преобразовываем нашу папку обратно в RAW-образ. Назовем его system_new.img :

1073741824 меняем на размер раздела system в байтах. Желательно даже сделать его чуть меньше. Делаем из RAW-образа sparse-образ:

Отделим файлы прошивки от лишней шелухи (файлов, которые мы загружали для работы. Для этого удобно пользоваться архивом с прошивкой). Удалили? Теперь нужно запаковать прошивку в ZIP-архив (любым архиватором).

Осталось подписать архив. Сделать это можно как на самом Android с помощью ZipSigner, так и на ПК (потребуется установленная Java):

Подводные камни

Во время сборки system.new.dat ты можешь столкнуться с несколькими проблемами, вызванными постоянными изменениями в механизмах формирования прошивок Android. Описанный выше способ должен хорошо сработать в случае основанной на Android 5.1 прошивки, в более новых могут возникнуть сложности, так что потребуется использовать другие версии инструментов сборки. К сожалению, мы не можем описать все нюансы сборки, поэтому, возможно, придется погуглить.

Установка

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

Выводы

Эта статья описывает лишь верхушку огромного айсберга под названием «модификация прошивок». «Серьезные» прошивки не только дополняют ядро и саму прошивку со стоковыми приложениями множеством функций (которые зачастую вырваны из других ядер и прошивок), организовывая или даже меняя принципы их взаимодействия, но и вполне могут кардинально менять принципы работы ОС. Правда, такая поделка — это уже не Android, а отдельная ОС, даже если Play-сервисы получится туда поставить (кстати, такие действия, мягко говоря, не поощряются Google). Ну и не забываем: все оболочки от производителей — TouchWiz, ZenUI, HTC Sense и так далее — всего лишь обычные кастомы, максимально привязанные к железу устройства и друг к другу.

Источник

Всего лишь меняем модель эмулятора Android устройства

Пролог

Казалось бы, на первый взгляд весьма простая задача. Некоторые читатели могли еще в те бородатые времена лазить по всяким 4пда, рутить свой сенсорный самсунг, менять содержимое файла build.prop и показывать наивным ламерам свой iPhone 15+ Max Pro. Однако, как оказалось, и как оно часто бывает, не все так просто и здесь есть свои подводные камни. Статья призвана помочь простым работягам избежать все кочки да ямы на пути к своей цели!

Дисклеймер

Сразу предупрежу, что люблю писать подобные статьи довольно подробно, не ради объема и многобукав, а ради максимального погружения в проблему и способ ее решения. Обратите внимание, что я работаю на macOS, поэтому все команды в терминале будут ориентированы под данную ОС. Также, следует отметить, что проворачиваю все это для API 30, то есть для самого последнего на момент написания статьи. Как говорят интернеты, сложности по этой теме начались с API 29.

Зачем это нужно?

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

Ради контекста вкратце расскажу зачем это понадобилось мне. Я получил .apk с багом где-то внутри приложения. Однако пройти дальше первого экрана в этом приложении я не смог. Дело в том, что при запуске, с сервера приходит список разрешенных для запуска устройств и ни мой народный Ксяоми, ни мой эмулятор в этот список не входит. Вот и додумался поменять имя модели устройства на одно из разрешенных. Рутить свой личный телефон не хотелось, поэтому решил шаманить с эмулятором.

Экран не пустивший меня дальше

Достаем build.prop

Как уже говорилось в начале статьи, за имя производителя и модель устройства отвечает системный файл build.prop, который находится в корне устройства в папке system/. Однако при попытке просмотреть его, не говоря уже о редактировании, мы получим отказ в доступе:

Отлично, теперь мы видим содержимое файла build.prop:

Редактируем build.prop

Сохраним файл build.prop в любое удобное место для дальнейшего редактирования выделенной красным области на скриншоте выше. Я сохранил прямо на рабочий стол:

Вносим необходимые изменения. Просмотрев логи запросов и ответов предоставленного мне .apk я нашел приходящий с сервера список разрешенных устройств. То есть, для моих целей нужно поменять два значения на PIXEL 3A XL (как вы поняли, здесь вы можете указывать необходимую именно вам модель):

Сохраняем изменения и заливаем файл обратно на эмулятор. Делается это при помощи команды adb push (кстати, скачать файл с эмулятора можно при помощи adb pull если у вас вдруг аллергия на GUI).

Вводим команду в терминал: adb push build.prop system/

adb: error: failed to copy ‘build.prop’ to ‘system/build.prop’: remote couldn’t create file: Read-only file system

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

Запускаем эмулятор с доступом на перезапись системных файлов

Для этого нужно выполнить следующую команду в терминале ~~(чтобы скорее всего получить еще одну ошибку)~~:

После у нас либо запустится эмулятор (несколько секунд запускается, так что если тупит то так и должно быть) либо получаем ошибку следующего типа:

PANIC: Missing emulator engine program for ‘x86’ CPU.

Что бы и нам решить с этим нужно в файле .bash-profile (или если у вас zsh то в файле .zshenv) находящийся в корне вашего профиля macOS, добавить дополнительные пути. Вот как это выглядит у меня:

есть такая переменная ANDROIDHOME и с ее участием редактируем переменную PATH:

Чтобы изменения вступили в силу перезапускаем терминал (или вводим source

/.bash_profile ) (или source

Пробуем запустить эмулятор еще раз.

Теперь он должен был успешно запустится.

Активируем доступ на перезапись системных файлов

Из описания флага -writable-system:

-writable-system make system & vendor image writable after ‘adb remount’

Теперь делаем adb shell avbctl disable-verification

Если вы вдруг остались в shell то введите exit

Перезагружаем эмулятор adb reboot и ждем

Снова делаем adb root

И вот теперь можно делать adb remount

Редактируем правильный build.prop

Вернемся к началу и заметим, что значения ro.product.product.name и ro.product.product.model не соответствует тому, что отображается в настройках устройства. Изучив структуру системных папок я заметил, что существует несколько файлов build.prop, которые располагаются в папках: system, system_ext, vendor и product. Эмпирическим методом я скачивал, редактировал и пушил обратно каждый из этих файлов. В конце концов ключевым оказался файл в папке product. Отредактировав его я наконец-то смог изменить название модели эмулятора устройства!

Подводим итоги

Наконец-то я смогу запустить приложение и воспроизвести баг. Подумал я…

О том, как я обходил проверку на рутованность устройства я расскажу в следующей своей статье. Немного реверс инжиниринга и даже такая популярная библиотека как RootBeer не проблема.

Данной статьей я стремился собрать как можно больше проблем по этому вопросу и изложить все в форме step-by-step. Спасибо за ваше внимание и очень надеюсь, что статья оказалась полезной!

Источник