Error in cache recovery block map status 7 lenovo

Ошибка 7 при прошивке через рекавери (TWRP, CWM Recovery)

вкл. 04 Март 2017 . Опубликовано в Android — Общее

Ошибка 7 при прошивке через рекавери (TWRP, CWM Recovery). Решили установить кастомную прошивку на свой Android смартфон или планшет, вошли в кастомное TWRP Recovery, но во время установки получили ошибку 7? Не отчаивайтесь исправить данную проблему довольно просто.

Многих новичков может обескуражить какие либо действия в установке кастомной прошивки, особенно если это процедура выполняется первый раз. Одним из серьезных препятствий во время установки прошивки может стать ошибка 7 в TWRP Recovery. Серьезность этой ошибки в том, что она не позволяет вообще установить кастомную прошивку на устройство и вся ваша подготовка пойдет насмарку. Но оказывается что данную ошибку 7 в recovery довольно легко исправить не прибегая к длительным действиям! О том как избавится от данной проблемы и посвящена сегодняшняя статья!

Откуда взялась ошибка 7?

Данная ошибка может возникнуть в двух случаях:

Как исправить Ошибку 7 при прошивке в Recovery?

Вариант 1 (действие 1)

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

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

Вариант 2 (действие 2)

1. Установите Notepad ++
2. Открываем прошивку и переходим по пути META-INFcomgoogleandroid
3. Извлекаем файл updater-script

4. Удалить вначале устанавливающего скрипта строки начинающиеся на assert

5. Сохранить документ и забросить обратно в прошивку заменив старый файл
6. Удалить в прошивке файлы по пути META-INF — CERT.RSA, CERT.SF, MANIFEST.MF

7. Забросить готовую прошивку на устройство, перевести в режим Recovery и попробовать снова прошить Android

Источник

Error in cache recovery block map status 7 lenovo

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

Сообщение отредактировал snekt — 12.05.22, 20:47

Перепакованный архив от 1050L в котором прибит кривой цикличный симлинк на самого себя бывший в /external/alsa-lib/include/alsa
выложил на гугл драйв, тыц.

Сообщение отредактировал rustik2005 — 06.01.15, 14:55

Сообщение отредактировал pro100gamer — 27.01.15, 11:29

Сообщение отредактировал pro100gamer — 13.06.15, 08:16

Сообщение отредактировал pro100gamer — 26.01.15, 08:49

Чтобы в приложении ютуб появилось качество 1080P, достаточно изменить в build.prop строку ro.build.version.release= 4.4.2 на 5.0 и перегрузить планшет
Кстати иногда, чтобы смотреть 1080p нужно ставить на паузу, выбрать качество 1080, закрыть видео и открыть (видео) по новой.

Ну и чтобы убрать рекламу нужно установить xposed + модуль youtubeAdAway:
de.robv.android.xposed.installer_v32_de4f0d.apk ( 711.77 КБ )

Установить эти 2 апкашки, открыть Xposed Installer, тапнуть на «Фреймворк», установить и перегруз.
После загрузки открыть снова xposed installer, тапнуть на «модули» и поставить галку напротив «YouTube AdAway»

Сообщение отредактировал pro100gamer — 17.01.15, 10:16

Инструкция только для root’ованных аппаратов:

1. Качаем Fotakill.apk и копируем в устройство/карту памяти;
2. При помощи root explorer (или ES Explorer) перемещаем в /system/app;
3. Если обновка уже выкачалась, то при помощи root explorer удалить ее из /cache
4. Перезагрузить.

Оригинал статьи в тут. Может затолкать в полезное как рецепт отключения обновок по воздуху? 🙂

Сообщение отредактировал rustik2005 — 25.12.14, 09:57

Инструкция только для root’ованных аппаратов:

1. Качаем Fotakill.apk и копируем в устройство/карту памяти;

Сообщение отредактировал pro100gamer — 25.12.14, 10:49

Пошёл я по ссылкам от ув.banner мародёрить по веткам Acer-а в поисках решения по биос, а вернулся с CWM 😀
Инструкция на английском
Инструкция на русском
Если все драйвера установлены правильно но ПК не видит планшет — вводите его в режим fastboot вручную и должно помочь

Чтобы получить рут, первым делом скопировать этот архив с рутом на внутреннюю или наружную флешку. Дальше установить CWM и оттуда прошить данный архив:
UPDATE-SuperSU-v2.40.zip ( 3.82 МБ )

Внимание: Это временный рекавери — после ребута будет снова стоковый (тоесть, если вам снова понадобиться CWM, чтобы флешануть какой-нибудь архив с рутом, кастомную прошивку или вернуть бекап, нужно проделать всю процедуру снова).
Выбираем опцию T3. Папку с инструментом лучше ложить в корень диска С.
В меню перемещаемся с помощью качелек громкости. Выбор подтверждаем кнопкой ВКЛ
Архив с рутом шьёт! (тоесть рутованые прошивки больше не нужны — обновляемся по воздуху и получаем рут этим способом)
Нандроид-бекап на наружную флешку делает и восстанавливает тоже!
Бекап делать только на наружную флешку — 7-ая опция сверху вниз «backup to external sdcard». Если сделали на внутреннюю, папка clockworkmod будет пустой и удалить её, чтобы освободить 3 гига на флешке можно только из меню CWM, опция delete
Плюс этого рекавери в том, что его можно запустить на аппаратах с залоченым бутлоадером

Скачать (новая версия, теперь бекапит и ядро с рекавери):
IntelAndroid-FBRL-01-17-2015.7z ( 4.05 МБ )

Для получения рут доступа на андроид 5 используем эту версию временного рекавери (опция T4):
IntelAndroid-FBRL-05-16-2015-PTR.7z ( 5.13 МБ )

Сообщение отредактировал pro100gamer — 20.06.15, 09:07

Загрузочный файл заставки Lenovo без звука.

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

При наличии root под любым системным менеджером (например ® Root Explorer (File Manager) (Пост #37237863)
поставить с заменой в system/media.Задать разрешение (rw-r—r—) и перезагрузиться.Звука при загрузке на включении не будет вообще.
Родной файл,если нужно,сохранить.Должно подходить для всех типов планшета(исходный файл в 8-ке и 10-ке одинаковые).

Сообщение отредактировал baikal0912 — 02.05.15, 09:03

Источник

Error in cache recovery block map status 7 lenovo

Lenovo A1000 — Прошивки
Lenovo A1000
Описание | Обсуждение » | Обсуждение A1000 m » | Брак и ремонт | Игры и приложения » | Модификации и украшательства » | Прошивки »

Опытным путём проб, ошибок и кирпичей было установлено, что начиная примерно с осени 2016 года, и уж 100% с зимы и дальше 20162017 года , продаваемые аппараты стали выходить с новой ревизией экрана иили тачскрина. Выяснено это было потому, что у одного из пользователей, а затем лавинообразно у многих сразу, при прошивке любых » старых » TWRP, выложенных до 22 апреля 2017 года (а новые выложены в этом посте ), а также любых кастомных и стоковых прошивок, кроме 30666, наблюдался артефакт в виде экрана с цветными полосами и рябью. Ничего или почти ничего на таких экранах рассмотреть было нельзя. Спасала только прошивка стока 30666 в виде пак-файла с lenovo-forums.ru. Почитать этот увлекательный триллер можно (и даже нужно тем, у кого аппарат совсем новый) здесь: Lenovo A1000 — Прошивки (Пост RZcT #57917459) Путём логических умозаключений и экспериментов было установлено, что эта прошивка — 30666, и только она — универсальна для всех ревизий. А прошивки ниже неё подходят только на старые аппараты, произведенные до указанного выше времени. Суть в том, что начиная с 30666 производителем было слегка подправлено новое ядро таким образом, чтобы на любой ревизии и любых прошивках полос на экране не было.

Короче говоря, проблема с ТВРП решена, новые ТВРП, подходящие на ВСЕ ревизии, висят в шапке, в ТВРП полос уже не будет ни у кого. Что же касается возможности прошивки старых прошивок на аппараты новых ревизий, то здесь не всё так просто, хотя и совсем не сложно. Читаем спойлер «Прошивки«—>Lenovo A1000 — Прошивки (Пост nemo-nemo #60718911).

Это обращение — к новичкам темы. Если вы недавно зашли в тему, иили ещё не сделали полный TWRP-бэкап, то вы должны принять на веру, что немедленное создание полного TWRP-бэкапа — действие, абсолютно для вас необходимое, если вы собираетесь делать ЛЮБЫЕ более-менее серьёзные манипуляции с аппаратом. Опыт многочисленных участников темы, не сделавших этого, а также их последующих мучений с восстановлением IMEI подсказывает, что TWRP-бэкап позволяет решить подавляющее большинство любых проблем, включая окирпичивание аппарата и повреждениe IMEI. Восстановить IMEI часто не может даже радикальный метод перепрошивки — с помощью программы Research Download — а собственный TWRP-бэкап может это сделать ВСЕГДА. Не подвергайте себя риску, походам в сервис-центр, тратам и нервам — не поленитесь, и сразу после прочтения этих строк немедленно сделайте полный TWRP-бэкап ! Как это сделать — смотрим вот в этом подробном посте: Lenovo A1000 — Прошивки (Пост nemo-nemo #57420760)

Основные, то есть существенные, отличия аппаратов состоят в двух вещах:

У А1000: оперативная память 1 Гб, внутренняя — 8 Гб
У А1000 m : оперативная память 512 Мб , внутренняя — 4 Гб

У А1000 загрузчик НЕ заблокирован
У А1000 m загрузчик заблокирован

Остальные характеристики А1000 m можно посмотреть в интернете.

USB-Драйвер — устанавливать в любом случае. Ещё ссылка, если с предыдущими проблема: — Alcatel OneTouch Pixi First — Прошивки (Пост nemo-nemo #50204588)
ADB-Драйвер — устанавливается только на рабочий, включённый аппарат с выставленной отладкой по USB.

У кого будyт проблемы с вышеуказанными драйверами (это иногда бывает), можно взять вот эти — Alcatel OneTouch Pixi First — Прошивки (Пост nemo-nemo #50204588)

К настоящему моменту для восстановления аппарата в наличии имеются три прошивки: одна чисто стоковая 30666, и две созданные мной (куратором) из официальной 30666:

3) Модифицированная прошивка 30666 в виде .рас -файла для программы Research Download, со встроенным ТВРП и другими незначительными изменениями: Lenovo A1000 — Прошивки (Пост nemo-nemo #56898589)

4) Официальная стоковая прошивка 30268, которую можно скачать из этого поста — Lenovo A1000 — Прошивки (Пост redlys #101798893) — а заодно и узнать из него некоторую полезную информацию по восстановлению аппарата.

Если у вас сохранились какие-либо стоковые прошивки в виде .рас -файла и вы готовы ими поделиться, сообщайте в личку куратору.

Читать обязательно владельцам аппаратов, произведенных не ранее осени-зимы 2016 года и позже: Lenovo A1000 — Прошивки (Пост nemo-nemo #60718911)

Если прошить на «новый» аппарат «старую» прошивку (до 30666), или любое из «старых» ТВРП — будут цветные полосы на экране. Поэтому читаем и делаем.

Источник

Error in cache recovery block map status 7 lenovo

Интересно, QC он умеет ?

P.S. WiFi у него исключительно 2.4GHz

Документация на планшет.

Lenovo TAB3 7 Plus Safety, Warranty & Quick Start Guide (Lenovo TB-7703F Lenovo TB-7703X)
lenovo_tab3_7_plus_swsg_en_ru_kk_v1.0_201611.pdf ( 4.77 МБ )

Lenovo TAB3 7 Plus Учебник (Lenovo TB-7703F Lenovo TB-7703X)
lenovo_tab3_7_plus_ug_ru_v1.0_201608.pdf ( 1007.62 КБ )

Lenovo TAB3 7 Plus Hardware Maintenance Manual (Lenovo TB-7703F Lenovo TB-7703X)
lenovo_tab3_7_plus_hmm_en_v1.0_201608.pdf ( 13.27 МБ )

Сообщение отредактировал MGAlex — 28.11.16, 22:49

Открытые исходные коды

Open Source Code — Lenovo TAB3 7 Plus (Lenovo TB-7703N/X)
Яндекс.Диск

Сообщение отредактировал MGAlex — 28.11.16, 22:49

Overview for Lenovo TAB3 7 Plus (Lenovo TB-7703F/X)

Model
Lenovo TB-7703F
Lenovo TB-7703X

Design
Dimensions 97.7*188*8.9 (mm)
Weight 258 g (0.57 lbs)
Operating System Android™ 6.0
Display-Resolution 1280 x 720
Display-Size 7″ HD IPS, 350 nits
Display-Touch 5-point Multitouch
Color Slate Black, Polar White
SIM Type : Micro SIM, Slots : Dual
Camera Rear: 5 MP Auto-Focus, Front: 2 MP Fixed-Focus, Focus Type: Digital Zoom
Sensors G Sensor, P+L Sensor2, Vibrator

Performance
Processor Qualcomm®Snapdragon™410, 1.2 GHz
Memory RAM : 2 GB, Internal Storage : Up to 32 GB + microSD™, Card Slot : microSD™; Expandable Up to 64 GB
Battery Type : Li-ion, Capacity : 3500 mAh, Standby Time : 14 Days, General Usage : 9 Hours
Audio Dolby Atmos®

Connectivity
Connectivity PRC, GSM : B2/3/5/8, UMTS : B1/2/5/8, TD-SCDMA : B34/39, FDD LTE : B1/3/7, TDD LTE : B38/39/40/412, CDMA/EVDO : BC0, ROW, GSM : B2/3/5/8, UMTS : B1/2/5/8, FDD LTE : B1/2/3/4/7/8/20, TDD LTE : B38/40
GPS Support Yes
WLAN WiFi 802.11 b/g/n
Bluetooth Yes
WiFi Direct/Display Yes
3.5 mm Audio Jack Yes
FM Radio Yes

**The configurations above are for reference only.

Источник

 Ошибка 7 при прошивке через рекавери (TWRP, CWM Recovery). Решили установить кастомную прошивку на свой Android смартфон или планшет, вошли в кастомное TWRP Recovery, но во время установки получили ошибку 7? Не отчаивайтесь исправить данную проблему довольно просто.

Многих новичков может обескуражить какие либо действия в установке кастомной прошивки, особенно если это процедура выполняется первый раз. Одним из серьезных препятствий во время установки прошивки может стать ошибка 7 в TWRP Recovery. Серьезность этой ошибки в том, что она не позволяет вообще установить кастомную прошивку на устройство и вся ваша подготовка пойдет насмарку. Но оказывается что данную ошибку 7 в recovery довольно легко исправить не прибегая к длительным действиям! О том как избавится от данной проблемы и посвящена сегодняшняя статья!

Откуда взялась ошибка 7?

Данная ошибка может возникнуть в двух случаях:

1. Если вы попытаетесь установить прошивку не от своего устройства, такое часто возникает, когда под одним наименованием смартфона или планшета может быть множество моделей с небольшими отличиями под определенные рынки (например смартфон LG G2 имеет модели VS980, LS980, D800, D802, F320K). Убедитесь что прошивка предназначена именно для вашего устройства!

2. В скрипте установке прошивки не внесено название модели вашего Android смартфона или планшета.

Как исправить Ошибку 7 при прошивке в Recovery?

Вариант 1 (действие 1)

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

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

Вариант 2 (действие 2)

1. Установите Notepad ++
2. Открываем прошивку и переходим по пути META-INFcomgoogleandroid
3. Извлекаем файл updater-script

4. Удалить вначале устанавливающего скрипта строки начинающиеся на assert

5. Сохранить документ и забросить обратно в прошивку заменив старый файл
6. Удалить в прошивке файлы по пути META-INF — CERT.RSA, CERT.SF, MANIFEST.MF

7. Забросить готовую прошивку на устройство, перевести в режим Recovery и попробовать снова прошить Android

{rutube}ace43b472b1b7b2fb55e2b53ba067bf8{/rutube}

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

Если Вы зашли на эту страницу, то Вам уже должны быть знакомы такие понятия как рекавери, twrp, прошивка смартфона и т.д. TWRP (Team Win Recovery Project) — это программное обеспечение для восстановления (и не только восстановления) системы для устройств на базе Android, которое в настоящее время доступно для огромного числа моделей смартфонов. Основными операциями TWRP являются создание резервных копий и восстановление из созданных бэкапов тех или иных разделов смартфона, но не менее важной является возможность прошивки различных архивов через эту утилиту.
Если Вы уже умеете пользоваться TWRP и в процессе прошивки какого-либо архива встретили злосчастную ошибку 7 (error 7), не сдавайтесь сразу, ведь ее можно исправить.

Причины возникновения ошибки 7 в рекавери

Ошибка 7 в TWRP может возникнуть в трех случаях (известных мне, возможны и другие):

1. Если вы пробуете установить прошивку, предназначенную для другой модели телефона, а не вашего, поэтому убедитесь, что скачанная вами прошивка создана конкретно для вашего смартфона.
2. В архиве прошивки, а точнее скрипте установке (файл, который есть в архиве прошивки) не определено название модели вашего Android смартфона или планшета.
3. Неподходящая версия TWRP рекавери.

Как исправить Ошибку 7 при прошивке в TWRP?

Варианты исправления ошибки соответствуют причинам возникновения этой ошибки, указанным ранее.

Вариант 1
В первую очередь Вам нужно убедиться, что Вы действительно скачали прошивку для своего смартфона. Существует немало сайтов-форумов, где выкладываются различные версии прошивок на множество моделей андроидфонов. Лично я рекомендую 4pda.ru (не в качестве рекламы). Разобраться на этом сайте сразу не получиться, но там есть действительно множество полезных файлов и инструкций для восстановления и перепрошивки смартфона.
Если Вы ошиблись при выборе прошивки, скачайте подходящую, и попробуйте установить ее. Возможно это станет решением проблемы и прошивка пройдет, как полагается.

Вариант 2
Прошивка смартфона производится согласно инструкции, которую закладывает разработчик, в виде скрипта обновления, в свою прошивку. Бывают случаи, когда в таком скрипте прописывается проверка на соответствие прошивки модели вашего устройства, и если модель устройства не совпадает, или по каким-либо причинам не определяется, скрипт обновления вернет ошибку 7 и процесс остановиться. В таком случае есть вариант изменить сам скрипт восстановления. Что для этого нужно?

1. Установите программу Notepad++ с официального сайта. Эта программа — расширенная версия стандартного блокнота в Windows. Функциональный, в нашем примере, он лучше всего поможет при редактировании скрипта.
2. Открываем прошивку (любым возможным архиватором, например 7-Zip или WinRar) и переходим по пути META-INFcomgoogleandroid
3. Находим и извлекаем (можно перетащить прямо из архива) файл updater-script, например, на рабочий стол. Открываем его с помощью программы Notepad++ (например, через правую кнопку мыши выбрать «Редактировать с Notepad++»)
4. Открывается текстовый файл, в котором нам нужно удалить строки, начинающиеся на assert. Тем, кто разбирается в английском или программировании, можно изучить скрипт, где видно что строки, которые нам нужно удалить — не что иное, как условие проверки названия модели по типу «if…else».
5. После удаления нужных строк сохраните документ и перенесите его обратно в прошивку, заменив при этом старый файл (также можно сделать перетаскиванием).
6. Перекиньте отредактированный архив с прошивкой обратно на устройство и попробуйте прошить его снова. Если вы все сделали правильно, прошивка должна пойти, как и должна.
7. В некоторых случаях вы можете также попробовать удалить в прошивке файлы по пути META-INF – CERT.RSA, CERT.SF, MANIFEST.MF. Не проверено лично. Обычно хватает редактирования скрипта обновления.

Вариант 3
Как следует из третьей причины, нередко ошибка 7 возникает на неправильной или неподходящей версии самого рекавери TWRP. В таком случае решение очевидно — вам нужно установить другую версию twrp. Как правило, просто нужно установить самую последнюю версию, которые чаще всего обновляются время от времени. В некоторых случаях под конкретную прошивку нужно устанавливать конкретную версию TWRP. Как установить TWRP, где его найти и какое именно устанавливать — все это можно узнать на форумах, например, на том же 4pda.ru
Надеюсь, вам помогут эти советы по исправлению ошибки 7 в рекавери. Если у вас возникнут вопросы, вы можете оставить их в комментариях. Благодарю за внимание!

Время прочтения
13 мин

Просмотры 58K

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

Как это работает

Первыми новые версии Android традиционно получают последние из устройств Nexus. Когда новая версия прошивки готова для широкой публики, полный образ размещается по адресу developers.google.com/android/nexus/images. Вскоре после этого начинается распространение прошивки по воздуху. Как рассказывает один из разработчиков Google Дэн Моррилл (Dan Morrill), сначала ОТА рассылается на 1% устройств. Это происходит рандомно, независимо от региона или места покупки телефона/планшета. В это время отлавливаются баги, что позволяет приостановить обновление при наличии критических ошибок у большого числа пользователей.

Далее в течение пары недель обновление распространяется для 25, 50, 100% пользователей. То есть на первом этапе шанс на получение обновления имеет одно устройство из ста. Если обновление не получено, то устройство выпадает из списка и повторное неоднократное нажатие на кнопку «Проверить наличие обновлений» автоматически переносит устройство в конец списка. Когда запускается новый этап рассылки, нажатие на кнопку дает следующий шанс получить обновление уже 25%. Так как устройство само проверяет наличие обновления раз в сутки (или при перезагрузке), то нажатие на кнопку может «выстрелить» раньше, чем это случилось бы само по себе. Но опять-таки проверка будет только один раз. Дальнейшие нажатия не помогут. Это не та ситуация, когда «кто первый нажал, тот первый получил». В любом случае обновление по воздуху придет всем в течение пары недель. Самые нетерпеливые могут прошить обновление руками (об этом ниже).

Уведомление о наличии обновления

Форсируем обновление

Ускорить получение обновления можно двумя способами. Первый — очистка данных Google Services Framework с последующей перезагрузкой устройства. Крайне не рекомендуемый способ, который осуждают даже инженеры Гугла. Этот способ вызывает множество негативных эффектов, главный из которых — смена идентификатора для GCM (Google Cloud Messenger). Этот идентификатор нужен во всех программах Гугла и множестве других приложений, использующих функции push-уведомлений. И если в некоторых программах побороть эффекты относительно легко, то для многих других последствия могут быть более печальны. Все приложения просто перестанут принимать push-уведомления, основанные на GCM, пока не получат новый идентификатор. Некоторые приложения делают проверку часто, некоторые редко. Для части поможет очистка данных приложения. А те приложения, которые используют GCM ID в качестве идентификатора на своих серверах, могут иметь более глубокие проблемы.

Стоковый recovery

Второй — установка обновления руками через консоль восстановления. Вскоре после запуска ОТА в профильных темах устройств на ресурсах 4PDA и XDA появляются файлы вида хеш.signed-hammerhead-LRX21O-from-KTU84P.c1a33561.zip, в названии которых содержится хеш файла, марка устройства, а также версии прошивок для обновления (на какую, с какой). На компе необходимо иметь папку с утилитами ADB и fastboot. Я использую последние версии из Android SDK. В ту же папку нужно положить скачанный архив с ОТА-обновлением. Также необходимо иметь правильно установленные драйверы для устройства, которые могут конфликтовать с ранее установленными драйверами для других устройств.

Само устройство следует перевести в режим восстановления (recovery). Для этого на выключенном устройстве зажимаем одновременно кнопки <Power + VolDown> и попадаем в загрузчик, кнопкой громкости выбираем Recovery mode, входим в него кнопкой Power. Появится лежачий Android с восклицательным знаком. Это не ошибка, пугаться не стоит. Необходимо на этом экране коротко нажать <Power + VolUp>, после чего и загрузится стоковый рекавери. В нем необходимо выбрать кнопками громкости пункт apply update from ADB и подтвердить кнопкой включения. Далее необходимо подключить телефон/планшет к компу. Запускаем консоль, переходим в папку с ADB и архивом обновления и вводим следующую команду (для файла, приведенного выше):

$ adb sideload хеш.signed-hammerhead-LRX21O-from-KTU84P.c1a33561.zip

После этого на телефон установится ОТА и он перезагрузится.

Блок-врезка: Как скачать обновление через сотовую сеть

Уведомление о доступности ОТА может прийти, когда устройство не подключено к Wi-Fi. При этом появится пометка, что файл доступен для скачивания по Wi-Fi до определенной даты (около недели), а сама кнопка «Скачать» будет неактивна. Это сделано для экономии денег юзера. Если подключение к Wi-Fi в ближайшее время не предвидится, то можно обмануть телефон и скачать обновление через 3G/4G, просто переведя дату в телефоне вперед, позже даты, указанной в уведомлении, и перегрузив устройство.

INFO

Под стоковой (stock — из магазина) прошивкой понимается наличие заводского ядра, recovery, отсутствие модификаций, полученных в том числе с помощью root.

Модифицированная прошивка

Если у тебя разблокирован загрузчик, стоит кастомный recovery, получен root, который активно используют различные программы, и применены различные модификации, то с вероятностью 99% обновление не установится. Даже при возврате стокового recovery при прошивке через ADB будет выдавать ошибку Status 7. Кастомный recovery также будет писать ошибку, ругаясь на измененные файлы. Побороть эту проблему можно, вернув смартфон к заводской прошивке, но это не наш метод. Мы разберемся с ней, расковыряв файл обновления, выясним, на каком месте спотыкается установка, и устраним проблему. И все это на примере самого крупного обновления Nexus 5 — с версии 4.4.4 (KTU84P) на 5.0 (LRX21O).

Механика работы ОТА

Итак, обновление с 4.4.4 на 5.0 стало самым крупным за последнее время с весом архива в 491 Мб. В связи со сменой Dalvik на ART практически весь код был модифицирован. Так что же содержит архив? Как видно на скриншоте «Файлы из архива с обновлением до 5.0», внутри архива находятся образы бутлоадера (различные разделы), каталоги META-INF, patch и system.

Файлы из архива с обновлением до 5.0

Для минимизации количества трафика и уменьшения нагрузки на серверы, а также для снижения затрат конечного пользователя структура обновления построена так, что файлы с большим количеством изменений или написанные с нуля находятся в каталоге system и меняются целиком. А файлы с небольшими по меркам Гугла изменениями не заменяются, а патчатся, то есть изменяются куски кода внутри файла. Эти файлы находятся внутри каталога patch и имеют расширение.р. Это хорошо видно, если сравнить файлы в /system/bin и /patch/system/bin. При этом для создания патча используется хорошо знакомый юниксоидам bsdiff, позволяющий из двух бинарников получить дельту (файл с разницей между файлами).

Само же волшебство происходит по воле updater-script, который находится в /META-INF/com/google/android. Именно его мы и рассмотрим подробнее. Сам файл весит 463 Кб и содержит строки кода, отвечающие за процесс применения ОТА-обновления (на самом деле это скриптовый язык Edify, интерпретатор которого находится в том же каталоге и носит имя update-binary. — Прим. ред.). Вот что он содержит в нашем случае. Сначала монтируется раздел /system (достаточно стандартная для Linux строка монтирования, схожая с теми, что находятся в /etc/fstab):

mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "max_batch_time=0,commit=1,data=ordered,barrier=1,errors=panic,nodelalloc");

Далее скрипт проверяет модель устройства и версию прошивки с помощью чтения системной переменной ro.build.fingerprint (обрати внимание, что он не берет ее из файла /system/build.prop, а запрашивает у самого recovery, поэтому обновления нельзя поставить с помощью кастомной консоли восстановления, хотя до 5.0 это было возможно). Здесь и далее троеточие это сокращенные строки:

getprop("ro.build.fingerprint") == "google/hammerhead/hammerhead:4.4.4/KTU84P/1227136:user/release-keys" ||
getprop("ro.build.fingerprint") ==  "google/hammerhead/hammerhead:5.0/LRX21O/1570415:user/release-keys" ||
abort("Package expects build fingerprint of google/hammerhead/hammerhead:4.4.4 ...");
getprop("ro.product.device") == "hammerhead" || abort("This package is for "hammerhead" devices ...");

Как видно выше, на «неродное» устройство обновление не встанет, зато его можно повторно накатить на версию 5.0. Также скрипт проверяет, подписана ли прошивка официальными ключами Google (release-keys). Из-за этого у многих пользователей возникают проблемы. Далее начинается проверка наличия и целостности отдельных файлов с помощью сверки хешей SHA-1. Для этого используются две функции: sha1_check(), принимающая в качестве аргументов имя файла и хеш, и apply_patch_check(), принимающая три аргумента: имя файла, и два хеша. Первая используется просто для проверки целостности файла, вторая проверяет, не был ли файл уже пропатчен. Для простоты длинные хеши в коде ниже заменены на многоточие:

sha1_check(read_file ("system/app/Drive/Drive.apk"), ...) || 
apply_patch_check("/system/app/Drive.apk", ...) || abort(""/system/app/Drive.apk" has unexpected contents.");
sha1_check(read_file("system/app/Drive/lib/arm/libdocsimageutils.so"), ...) || 
apply_patch_check("/system/lib/libdocsimageutils.so", ...) || abort (""/system/lib/libdocsimageutils.so" has unexpected contents.");

Для примера показаны только две проверки. По факту проверяются все файлы, которые подлежат замене или изменению патчем. В коде видно, что обновление выдаст ошибку, если, например, был изменен или удален файл /system/app/Drive.apk. В конце блока проверки скрипт проверяет ядро, доступное место в /system и радио:

apply_patch_check("EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8908800:...") || abort("...");
apply_patch_space(23999236) || abort("Not enough free space on /system to apply patches.");
apply_patch_check("EMMC:/dev/block/platform/msm_sdcc.1/by-name/modem:46499328:...") || abort("..."); 

То есть данное обновление не встанет, если стоит кастомное ядро или модификация радио. Следующим шагом идет удаление старых файлов с устройства перед их заменой на новые и удаление файлов, которые не нужны на новой прошивке:

delete("/system/app/BasicDreams/", "/system/app/BasicDreams/arm/", ...);

Далее патчатся все необходимые файлы с предварительной проверкой хеша SHA-1. Патчинг выполняется с помощью функции apply_patch(), которая принимает имена файлов для патчинга и несколько хешей: хеш оригинала, хеш патча и хеш результата. Последним аргументом идет имя файла с патчем. Как и раньше, все хеши в коде ниже сокращены до многоточия:

sha1_check(read_file("system/app/Drive/Drive.apk"), ...) || 
apply_patch("/system/app/Drive.apk", "-", ..., package_extract_file("patch/system/app/Drive.apk.p"));

Последним патчится ядро и RAM-диск:

apply_patch("EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:..., package_extract_file("patch/boot.img.p"));

Следующий блок переносит на устройство файлы, которые не попадают под патч и должны быть заменены целиком. Часть из них затем перемещается:

package_extract_dir("system", "/system");
rename("system/app/KoreanIME.apk", "system/app/KoreanIME/KoreanIME.apk");
rename("system/framework/wm.odex", "system/framework/arm/wm.odex");
...

Удаляются ненужные файлы, расставляются симлинки, права доступа и флаги (здесь на многоточие заменены именно права доступа и флаги):

delete("/system/etc/firmware/wcd9320/wcd9320_mbhc.bin", ...);
symlink("/data/misc/audio/mbhc.bin", "/system/etc/firmware/wcd9320/wcd9320_mbhc.bin");
symlink("/data/misc/audio/wcd9320_anc.bin", "/system/etc/firmware/wcd9320/wcd9320_anc.bin");
...
set_metadata_recursive("/system/bin", ...);
set_metadata("/system/bin/app_process32", ...);

Прошиваются бутлоадер и сопутствующие разделы:

package_extract_file("bootloader-flag.txt", "/dev/block/platform/msm_sdcc.1/by-name/misc");
package_extract_file("bootloader.aboot.img", "/dev/block/platform/msm_sdcc.1/by-name/aboot");
package_extract_file("bootloader.rpm.img", "/dev/block/platform/msm_sdcc.1/by-name/rpm");
...

Патчится радио/модем:

apply_patch("EMMC:/dev/block/platform/msm_sdcc.1/by-name/modem:..., package_extract_file("radio.img.p")); 

Последним меняется build.prop, в который записывается в том числе новая версия прошивки. Сделано это для того, чтобы при возникновении ошибки на самом последнем этапе, когда почти все файлы уже перенесены, прервать обновление и сохранить номер текущей версии прошивки в файле на устройстве. Тогда при нажатии кнопки «Проверить обновление» можно запустить его снова.

apply_patch("/system/build.prop", "-", ..., package_extract_file("patch/system/build.prop.p"));
set_metadata("/system/build.prop", ...); 

В конце скрипта раздел /system перемонтируется, и начинается проверка правильности применения обновления, сверяется SHA-1 хеш новых файлов и /system размонтируется:

unmount("/system");
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "");
assert(sha1_check(read_file("/system/app/CalendarGooglePrebuilt/CalendarGooglePrebuilt.apk"), ...));
assert(sha1_check(read_file("/system/app/CaptivePortalLogin/CaptivePortalLogin.apk"), ...));
...
unmount("/system");

После чего устройство перегружается в новую систему.

Updater-script как он есть

Кастомный recovery

До недавнего времени прошить архив ОТА-обновления в большинстве случаев (если не было проверки recovery для его замены) можно было из кастомного recovery, просто закинув файл на устройство и выбрав install zip. Но начиная со скрипта для обновления 5.0 скрипт поменялся. Предыдущие версии проверяли файл /system/build.prop:

file_getprop("/system/build.prop", "ro.build.fingerprint")

Текущие скрипты проверяют не файл, а значение системной переменной напрямую, запрашивая его у recovery:

getprop("ro.build.fingerprint")

А если разобрать кастомный recovery (для примера TWRP версии 2.8.0.0), то можно увидеть следующие строки:

ro.build.description=omni_hammerhead-eng 4.4.4 KTU84P eng.dees_troy.20140910.125240 test-keys
ro.build.fingerprint=Android/omni_hammerhead/hammerhead:4.4.4/KTU84P/eng.dees_troy.20140910.125240:eng/test-keys

Версия TWRP 2.8.6.1 имеет в коде следующие строки (обрати внимание на слово omni во второй строке, разработчик TWRP с ником Dees Troy — еще и один из активных разработчиков OmniROM):

ro.build.id=LRX22G
ro.build.display.id=omni_hammerhead-eng 5.0.2 LRX22G eng.dees_troy.20150403.145211 test-keys
ro.build.version.incremental=eng.dees_troy.20150403.145211

А последние версии CWM Touch и Philz подписаны так:

ro.build.description=hammerhead-user 4.4 KRT16M 893803 release-keys
ro.build.fingerprint=google/hammerhead/hammerhead:4.4/KRT16M/893803:user/release-keys

Именно эти значения и возвращает при проверке скрипт, прерывая обновление в самом начале и выдавая ошибку о несоответствии версии Android на устройстве.

Вот какой ответ ты получишь при попытке установить обновление 5.0.2 на Nexus 7 из кастомного recovery

Обновление 4.4.3–4.4.4

Для сравнения можно привести предыдущее обновление с версии KTU84M на KTU84P. Обновление мелкое и весит всего 2,5 Мб. В основном касается улучшений безопасности. Если открыть архив, то можно увидеть, что патчится только небольшое количество системных файлов и радио, соответственно, скрипт и проверяет только их. Это обновление нормально устанавливалось с рутом, кастомным ядром и работающим Xposed Framework, так как на наличие изменений все это не проверяется.

Обновление для Nexus 6 и Nexus 9

У последних устройств от Google структура скрипта в корне другая. Для этих и (судя по всему) последующих устройств Nexus Google добавила в сборочный скрипт, формирующий ОТА-обновление, функцию генерации поблочного обновления. Такое обновление сверяет и обновляет не отдельные файлы, а блоки в файловой системе /system. Далее в примере «66,…,524256» — это длинные списки адресов блоков:

if range_sha1("/dev/block/platform/msm_sdcc.1/by-name/system", "66,...,524256") == "..." then
block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");

Это позволило инженерам Google существенно упростить и ускорить применение ОТА-обновления для конечных устройств, а сам updater-script теперь занимает всего 5 Кб. Но это обернулось головной болью для продвинутых пользователей. Ведь теперь любые изменения в системном разделе вызовут сбой. Включая наличие лишних файлов. Даже факт монтирования системы как R/W приведет к изменению хеша суперблока ФС.

Заключение

Подводя итоги статьи, можно сделать следующие выводы:

1. Права суперпользователя сами по себе не влияют на успешное применение обновления. Влияют те изменения, которые пользователь и программы вносят в систему, имея эти права. Часто эти изменения невозможно отследить и вернуть.
2. Повлияют ли root и внесенные в систему изменения на успешное обновление, зависит каждый раз от того, что именно меняется в системе при обновлении и какие файлы проверяет скрипт. Если система менялась, замораживались/отключались ненужные системные приложения через Titanium Backup, менялись ядра, ставился кастомный recovery, Xposed Framework, Lucky Patcher, freedom, franco.Kernel updater, моды на звонилку и всяческие улучшалки для звука, другая бутанимация, системные шрифты и так далее. Все это может повлиять на обновление.
3. При модификации системы всегда оставляй оригинальные файлы для бэкапа, если хочешь обновляться через ОТА. Копируй в облако, переименовывай как угодно. Можно сделать Nandroid-бэкап раздела /system (о Nandroid читай в предыдущем номере).
4. Если помнишь, что менял в системе, можно откатиться назад почти всегда. Recovery всегда пишет ошибку, на что ругается обновление. Погуглив название файла в ошибке, иногда можно найти, какая прога его меняет. Например, /system/bin/thermal-engine-hh и /system/lib/power.msm8974.so заменяет franco.Kernel updater и не возвращает его даже при прошивке стокового ядра и сносе самого приложения.
5. Для успешного применения ОТА необходимо вернуть в систему оригинальные файлы. Самый верный способ — это прошить system.img, стоковое ядро и recovery перед тем, как устанавливать обновление (данные и приложения не потеряются).
6. Ну и главный вывод. Если есть рут и много модификаций — не мучайся, а сразу шей полный образ новой прошивки, удалив ключ -w в flash-all.bat для сохранения данных. Начиная с обновления до версии 5.0, остается очень маленькая вероятность обмануть скрипт. Да и следующее обновление может иметь «блочную» структуру, которая подразумевает наличие только полного стока для применения.

Пара слов от редактора

До недавнего времени OTA-обновления в каcтомных прошивках (CyanogenMod, Paranoid) всегда приходили в виде zip’а с полной версией прошивки и было абсолютно неважно, какие изменения вносились в систему до этого. Прошивка всегда устанавливалась заново (с сохранением данных юзера и gapps, естественно), однако в CyanogenMod 11 появилась функция инкрементальных обновлений, но гораздо более простая в сравнении с той, что используется Google. Обновление просто проверяет целостность прошивки и заменяет те файлы, которые изменились с прошлой версии (обычно ночной сборки), без всяких патчей. Причем, если ты пропустишь одно из обновлений, следующее по старинке придет в виде полного обновления. Просто и удобно.

Более интересный метод используется в OmniROM. Для обновления она использует бинарные патчи, но совсем не так, как это делает Google. Первое OTA-обновление всегда скачивается полностью, после чего сохраняется на карте памяти, прошивается, но не удаляется с карты. Следующее OTA-обновление уже приходит в виде единого бинарного патча, после чего патч накладывается на сохраненное в прошлый раз на карте памяти обновление и уже оно прошивается. Изюминка этого метода в том, что патч накладывается не на систему, а на файл с прошлым обновлением и смартфон каждый раз прошивается как бы с нуля (но с сохранением данных и настроек). Почти идеальный метод — трафик экономится, а беспокоиться о конфликтах с измененной системой не надо.

Экран установки обновлений в CyanogenMod 12

Впервые опубликовано в журнале Хакер #196.
Автор: Дмитрий «BRADA» Подкопаев

Подпишись на «Хакер»

• Материалы сайта
• Бумажный вариант
• «Хакер» на iOS/iPad
• «Хакер» на Android

За правильностью выбора прошивки отвечает механизм защиты «Asserts«. Скрипт проверяет модель устройства и версию прошивки по системной переменной ro.build.fingerprint, запрашиваемой у самого recovery. В случае совпадения кодов он выдает подтверждение легитимности установки, а при несовпадении (отсутствии) не подтверждает возможность этого действия. В результате вы видите ошибку 7, но зато ваш аппарат не превращается в кирпич. Бывают и такие случаи, когда даже при правильном выборе прошивки для своего устройства вы все равно получаете сообщение об ошибке 7. Они крайне редки и связаны с ошибкой разработчика прошивки.

Чтобы исправить ошибку 7 необходимо, прежде всего, убедиться в том, что вариант прошивки выбран правильно, и она предназначена именно для вашей модели и модификации Android-смартфона или планшета. Если ошибка все равно появляется, придется править файл updater-script, отвечающий за соответствие версий прошивки и устройства.

1. Скопируйте ZIP-файл ROM на свой компьютер и извлеките его, используя привычный для вас архиватор (например, 7-zip).
2. После распаковки найдите папку META-INF и пройдите по цепочке META-INF / com / google / android. В последней папке вы найдете два файла под названием «update-binary» и «updater-script». Нас интересует последний.
3. Переименуйте «updater-script» в «updater-script.txt» и откройте свой любимый редактор текстовых файлов (как вариант, Notepad++).
4. Избавьтесь от строк, начинающихся с «assert» до точки с запятой. Обычно это первая или несколько первых строк в верхней части текстового файла. Просто удалите их.
5. Сохраните файл.
6. Переименуйте «updater-script.txt» обратно в «updater-script».
7. Обновите все файлы, которые вы распаковали.
8. Скопируйте новый, отредактированный zip-файл на свой телефон.
9. Переведите Android-устройство в режим recovery и попробуйте его перепрошить — ошибка 7 не должна больше вас беспокоить.

Поделитесь своим опытом исправления ошибки 7 в комментариях.