Как исправить баги в прошивке

Я думаю, все уже знали, что мне перепошили планшет… Я нашёл баги в этой прошивке… Так вот: GPS и карта памяти…

У меня в верху в шторке есть уведомление, о том, что вставлена карта памяти, и я ее, блин, немогу извлечь (там в уведомлении) кнопочкой!

GPS, может включится, выключится, но после его использования(попытки использовать) он может и будет работать, но при выключения он глючит, кнопка, как-бы заедает…

Возможно ли это как-то излечить? Хоть как-то(без риска)?..

Андроид 4.2.2, ASUS MeMO Pad HD7

Может есть програмка для исправления багов?

P.S.: рут есть…

Время на прочтение
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

В настоящее время компания Xiaomi постепенно выпускает новейшую версию фирменной оболочки MIUI 12, но довольно много пользователей жалуется на различные ошибки проверки прошивок, которые возникают при попытке установить MIUI 12.

Мы разобрали причины ошибок, с которыми сталкиваются владельцы устройств Xiaomi, Redmi и Poco при установке MIUI 12 / 11. В этом руководстве хотим объяснить, что они означают и как их решить.

ROM is in beta testing …

Как и все предыдущие выпуски оболочки, MIUI 12 также проходит через этап бета-тестирования, который предшествует релизу стабильных версий.

При попытке установить бета-версию вы можете получить следующую ошибку:

Can’t verify update. ROM is in beta testing, make sure you have signed in with a beta authorized xiaomi account.

Перевод: Не могу проверить обновление. Версия находится в стадии бета-тестирования, убедитесь, что вы вошли в систему с авторизованной учётной записью бета-тестера Xiaomi.

На экране смартфона ошибка выглядит так:

Данная версия прошивки предназначена только для участников команды тестировщиков по программе Mi Pilot и предназначена для оценки производительности обновления и выявления возможных ошибок.

Необходимо подождать, когда для вашего устройства выйдет стабильная прошивка MIUI 12. Либо станьте бета-тестером.

Looks like current ROM’s network carrier type …

После завершения фазы бета-тестирования MIUI 12 выпускается в разных версиях: Китай, Глобальная, Европа, Индия, Россия, Индонезия, Турция и Латинская Америка. При попытке установить прошивку из региона, отличного от региона смартфона, возникает следующая ошибка:

Can’t verify update. Couldn’t verify. Looks like current ROM’s network carrier type is different from that in the Recovery package. Please download the correct ROM from MIUI forum.

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

На телефоне Xiaomi сообщение отображается так:

Необходимо установить прошивку, соответствующую установленной в смартфоне. Иными словами, невозможно установить прошивку одного региона на другой — на глобальную ставится глобальная, на RU только RU и т. д.

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

It’s not allowed to upgrade to unofficial ROM …

Может случиться так, что вы столкнётесь с поддельной прошивкой MIUI 12. При попытке установить её, отображается следующая ошибка:

Can’t verify update. It’s not allowed to upgrade to unofficial ROM package.

Перевод: Не могу проверить обновление. Не допускается обновление до неофициальной прошивки.

Вы пытаетесь установить неофициальное обновление, о чём сообщает устройство:

Помимо официальных прошивок для смартфонов Xiaomi выпускаются и неофициальные, которые изменены сторонними разработчиками, неподконтрольными XIaomi, что не гарантирует ни стабильности, ни безопасности.

Скачайте стоковую версию с официального сайта Сяоми. Для удобства, мы собрали официальные ссылки на Recovery Rom, Fastboot и OTA для MIUI 12: Россия, Европа, Глобальные. Либо смотрите прошивки для конкретной модели Xiaomi.

Couldn’t verify the source of this update …

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

Can’t verify update. Couldn’t verify the source of this update. Try downloading it again.

Перевод: Не могу проверить обновление. Не удалось проверить источник этого обновления. Попробуйте скачать его ещё раз.

Эта довольно частая ошибка возникает при отсутствии стабильной мобильной связи или неустойчивом интернет-соединении. Для повторной попытки обновления необходимо подключиться к стабильному интернет-каналу.

Здесь нужно отметить, что при обновлении через мобильную сеть прервать установку может даже входящий звонок.

Not enough space in cache partition …

Может случиться так, что при попытке установить обновление MIUI 12 вы получите следующую ошибку кэша, когда в нём недостаточно свободного места для обновления:

Not enough space in cache partition. There isn’t enough free space for an update in the cache partition of your device’s storage. Tap “Reboot” to clear the cache partition and reboot your device. Your data won’t be affected by this action.

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

Необходимо очистить кеш устройства, для чего следует произвести следующие действия:

1. Выключите устройство;
2. Одновременно нажмите и удерживайте кнопку питания и увеличения громкости пока аппарат не войдёт в режим восстановления (Recovery);
3. С помощью кнопок громкости перейдите к пункту Wipe Data, затем нажмите кнопку питания для подтверждения;
4. После очистки перейдите в раздел Перезагрузка и перезагрузите смартфон;
5. Приступайте к обновлению системы.

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

You don’t have permissions to access …

You don’t have permissions to access the update log. Make sure the account you signed in with has the required permissions.

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

При этом на экране появляется сообщение об ошибке доступа:

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

1. Обновление было отозвано производителем из-за выявленных ошибок и необходимо подождать перевыпуска прошивки.
2. Временная проблема с доступностью серверов Xiaomi.
3. У вас уже установлена тестовая версия обновления.

Первый вариант наиболее распространён — вы пытаетесь вручную установить прошивку MIUI 12, которая была отозвана из-за ошибок. Эта же проблема встречается в ином виде — сначала пользователь видит доступное обновление в настройках смартфона, а позже оно неожиданно пропадает.

Если вы скачали последнюю версию MIUI 12, то при попытке установки можете получать следующее сообщение об ошибке:

Can’t verify update. Sorry, flash to this stable version is not allowed.

Перевод: Не могу проверить обновление. Извините, прошивка до этой стабильной версии не разрешена.

В этом случае от отображается сообщение:

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

Can’t download. Something went wrong …

Can’t download. Something went wrong. Wait a minute or two and try again.

Перевод: Невозможно скачать. Что-то пошло не так. Подождите минуту или две и попробуйте ещё раз.

В этом случае вы видите на экране сообщение:

Причин возникновения ошибки загрузки обновления может быть несколько:

1. Вы пытаетесь установить бета-версию MIUI 12, изначально предназначенную для определённого круга пользователей, которая была удалена.
2. Загруженный пакет обновления был модифицирован.
3. Сервера Xiaomi сильно перегружены.

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

В третьем случае происходит сбой проверки обновления MIUI из-за недоступности сервера Саяоми. Необходимо повторить попытку нажав Try again либо запустить установку чуть позже.

Если у есть вопросы по другим ошибкам при установке MIUI 12 или вы знаете иные решения вышеописанных проблем, пишите в комментариях.

У меня уже есть осциллоргаф Hantek DSO5102P. Визуально, и в работе нравится.
Купил с рук, дешевле, продавец обещал что там всё работает, на почте проверял сам.
Уже дома позже обнаружил, что один из щупов на крокодиле где земля немного коротил, там небольшая отметина типа сварки.
Потом кнопка включения не всегда цепляла, опытным путём узнал что её нужно включать пока кнопки на осциллографе загорятся, и дальше до еле слышного щелчка, тогда она цепляет, а если быстро нажать, то не всегда цепляет и кнопки зажглись и потухли.
Прежняя прошивка не совсем понравилась, это уже позже узнал когда прошил новую, в ней удобней реализованы некоторые функции.
Прибор с виду новый.
Весит ровно 2 кг.
Убрал заземляющий провод, путём добавления к его родной вилке переходника с евро вилки на обычную, но ещё можно заземление убрать внутри корпуса осциллографа.
Прошивку залил из оффсайта http://www.hantek.com/download?key=zxgj&sid=0&pid=0&word=
DSO5102P Firmware
Не стал жадничать и заливать на него прошивку DSO5202P Firmware, чтобы расширить пропускную способность, даже где то читал что это бесполезно, но не важно, мне это пока не нужно.

Пробовал работать им, но не все функции пока понимаю, но простенькое на одном, и двух каналах удалось совершить.
Мануал пока не читал https://www.hantek.ru/products/mans/DSO5000B_manual_rus.pdf
Пока пытаюсь что пойму сам, да + по ютубным видео.
Максимальную частоту подавал 2 мегагерца от транзистор тестера gm328a.

Разбирал его, есть место для трансформатора, и если захотеть можно переделать на аккумулятор.
Но там четыре питания, возможно понадобиться 4-5 штукт дс дс преобразователей.
Ещё там вроде линейник на 5 вольт греется сильно, рекомендуют на радиатор.
Маркировки микросхемы радиатора не видел.

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

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

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

Может у кого есть другие идеи как увидеть электроэнцефалограмму (ЭЭГ)?

В 2020 году Xiaomi выпустила на тот момент последнюю версию собственной прошивки MIUI 12. Она стала настоящей катастрофой, поскольку содержала небывалое число ошибок. В какой-то момент китайские программисты устали исправлять многочисленное количество проблем, ведь после решения одной, всплывало сразу две, и так до бесконечности. Единственным здравым решением был выпуск более новой прошивки в сжатые сроки. Возможно, именно с этой целью вместо MIUI 13 появилась MIUI 12.5 с минимальным количеством функций. Нам обещали стабильную прошивку, которая позволяла начать всё с чистого листа, оставив дыры и баги за бортом. Как недавно стало известно, залатать новые дыры снова нет никакой возможности, а значит вся надежда на MIUI 13, на у пока это лишь отдалённая перспектива, владельцам флагманских смартфонов предложат MIUI 12.5 Enhanced Edition. Якобы, она не только повысит стабильность, но и увеличит автономность, а также другие показатели. Поскольку точных данных на этот счёт нет, самое время изучить наиболее неприятные баги в MIUI 12.5.

Пожалуй, самой распространённой и неприятной ошибкой считается наличие исчезающих уведомлений. Ну а в некоторых случаях они просто не приходят, что не позволяет пользователю быть в курсе последних новостей и своевременно отвечать на те или иные сообщения. Ошибка может появиться в любой момент и замечена на всех смартфонах под управлением MIUI 12.5. На мощных аппаратах с дисплеем на 120 Гц недавно пришёл неприятный баг, когда во время прокрутки браузера Chrome экран подвисает. Хотели как лучше, а получилось не очень. На телефонах серии Redmi Note 10 зафиксированы провалы звука, а также отказ приложений синхронизироваться с уведомлениями. В результате вообще нет никаких уведомлений, но об этом было немного выше. На Mi 10T уведомления приходят с большим запозданием, а при попытке обрезать изображение в галерее вообще ничего не происходит.

Redmi Note 8 Pro по какой-то непонятной причине перестаёт быстро заряжаться, а иногда у него вообще глючит сенсор. Многие смартфоны отказываются делать снимки экрана, а при попытке перейти в настройку обоев, появляются глюки, не позволяющие воспользоваться данной функцией. Poco F3 кроме уведомлений ещё и скрывает пропущенные звонки, а большинство аппаратов не умеют корректно отображать тёмный режим в Facebook и других популярных приложениях. 

Если вы думали, что это всё – то крупно ошиблись. В данном материале можно изучить все эти и другие баги. Всё настолько плохо, что часто пользователи не могут воспользоваться базовыми функциями, из-за которых они покупали дорогущий флагман. К примеру, Mi 10 теряет режим 5G. Решение есть, но оно сложное и не подойдёт большинству владельцев данного аппарата.