Код ошибки 409 dr web

Ошибки, связанные с лицензией

Коды и описание ошибок для продуктов Dr.Web под Windows

Коды и описание ошибок для продуктов Dr.Web под Linux

Коды и описание ошибок для Dr.Web для почтовых серверов UNIX

Ошибка HTTP 409 Conflicting Request – это конфликт между запросом пользователя и сервером, к которому он обращается. Например, есть сайт, с которого пользователь хочет скачать файл с названием «файл1», но этот файл раньше был на сервере и его упоминание сохранилось в кеше. Однако, теперь файл называется “файл01» и сервер не понимает, что пользователь хочет от него. Это очень образный пример для того, чтобы максимально понятно определить значение ошибки.

Ситуации при которых возникает ошибка 409 HTTP сильно разнятся, но сводятся к конфликту между запросами. Иногда, задавая запрос, браузер сам уходит в цикличную обработку, и он либо закрывается, либо виснет так, что пользователю ничего не остается, как просто перезагрузить компьютер. Это явление часто замечают пользователи браузера Mozilla и Opera.

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

Основные причины возникновения ошибки 409:

• Пользователь обращается к данным, имеющим отличное значение или более новую версию. В итоге, сервер выдает ошибку 409, т.к. существует обновленная версия файла, страницы или скрипта.
• Ошибка 409 появилась в результате конфликтующих запросов внутри файлов на сервере. Решить проблему может программист.
• Использование прокси, которое конфликтует с определенными адресами или форматами запрашиваемых данных. Не путайте эту ошибку с ошибкой 407.
• Более распространенная причина – троян или вирус, который блокирует запросы к определенным сайтам или подгружает файл, который имеет конфликт с конфигурацией браузера.

Ошибка 409 Conflicting Request в большинстве случае решается системным администратором или программистом, если это не касается заражения компьютера вирусом или трояном. Как проверить и какой программой расскажем ниже.

Как исправить ошибку 409 (Conflicting Request – Конфликт запросов)?

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

1. Чистим от вируса или трояна, чтобы убрать ошибку 409

Определить вирус/троян у вас или нет просто – установите программу Cureit от Dr.Web и просканируйте систему этой программой. Она бесплатная и не требует установки. Скачиваем только с официального сайта. В программе отмечаем все пункты для проверки и шагаем спать/на работу, т.к. сама проверка займет длительное время. На скриншоте ниже вы можете рассмотреть, как и что отмечать в программе. Свой антивирус лучше отключить перед проверкой.

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

1. Исправляем ошибку 409 в конкретном браузере

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

Заранее нужно сохранить закладки, т.к. можно потерять все нажитое непосильным трудом. Делается это просто. На скриншоте выше вы видите пример сохранения настроек в браузере Mozilla. Аналогично делается и в остальных браузерах.

1. Ошибка 409 в результате правок на сайте

Если вы являетесь администратором сайта или программистом… Вы знаете, что такое бэкап и как им пользоваться. Если не знаете – спросите в комментариях. Что с ним делать? Думаю, ответ знаете сами.

Последнее слово про ошибку

Ошибка 409 HTTP Conflicting Request редко относится к пользователю, если только это не вирус или троян. Почти 80% случаев с этой ошибкой касается разработчиков, поэтому разбираться в этом нужно точно не обычному пользователю. Все советы про чистку реестра и прочее – не актуальны. Это не относится к этой ошибке.

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

Ошибка HTTP 409 Conflicting Request – это конфликт между запросом пользователя и сервером, к которому он обращается. Например, есть сайт, с которого пользователь хочет скачать файл с названием «файл1», но этот файл раньше был на сервере и его упоминание сохранилось в кеше. Однако, теперь файл называется “файл01» и сервер не понимает, что пользователь хочет от него. Это очень образный пример для того, чтобы максимально понятно определить значение ошибки.

Ситуации при которых возникает ошибка 409 HTTP сильно разнятся, но сводятся к конфликту между запросами. Иногда, задавая запрос, браузер сам уходит в цикличную обработку, и он либо закрывается, либо виснет так, что пользователю ничего не остается, как просто перезагрузить компьютер. Это явление часто замечают пользователи браузера Mozilla и Opera.

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

Основные причины возникновения ошибки 409:

• Пользователь обращается к данным, имеющим отличное значение или более новую версию. В итоге, сервер выдает ошибку 409, т.к. существует обновленная версия файла, страницы или скрипта.
• Ошибка 409 появилась в результате конфликтующих запросов внутри файлов на сервере. Решить проблему может программист.
• Использование прокси, которое конфликтует с определенными адресами или форматами запрашиваемых данных. Не путайте эту ошибку с ошибкой 407.
• Более распространенная причина – троян или вирус, который блокирует запросы к определенным сайтам или подгружает файл, который имеет конфликт с конфигурацией браузера.

Ошибка 409 Conflicting Request в большинстве случае решается системным администратором или программистом, если это не касается заражения компьютера вирусом или трояном. Как проверить и какой программой расскажем ниже.

Как исправить ошибку 409 (Conflicting Request – Конфликт запросов)?

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

1. Чистим от вируса или трояна, чтобы убрать ошибку 409

Определить вирус/троян у вас или нет просто – установите программу Cureit от Dr.Web и просканируйте систему этой программой. Она бесплатная и не требует установки. Скачиваем только с официального сайта. В программе отмечаем все пункты для проверки и шагаем спать/на работу, т.к. сама проверка займет длительное время. На скриншоте ниже вы можете рассмотреть, как и что отмечать в программе. Свой антивирус лучше отключить перед проверкой.

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

1. Исправляем ошибку 409 в конкретном браузере

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

Заранее нужно сохранить закладки, т.к. можно потерять все нажитое непосильным трудом. Делается это просто. На скриншоте выше вы видите пример сохранения настроек в браузере Mozilla. Аналогично делается и в остальных браузерах.

1. Ошибка 409 в результате правок на сайте

Если вы являетесь администратором сайта или программистом… Вы знаете, что такое бэкап и как им пользоваться. Если не знаете – спросите в комментариях. Что с ним делать? Думаю, ответ знаете сами.

Последнее слово про ошибку

Ошибка 409 HTTP Conflicting Request редко относится к пользователю, если только это не вирус или троян. Почти 80% случаев с этой ошибкой касается разработчиков, поэтому разбираться в этом нужно точно не обычному пользователю. Все советы про чистку реестра и прочее – не актуальны. Это не относится к этой ошибке.

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

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

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

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

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

Действия по исправлению ошибки HTTP 409

Мы собираемся упомянуть, какие шаги мы должны предпринять, чтобы попытаться решить ошибку HTTP 409, когда она появляется на нашем компьютере. Мы дадим ряд рекомендаций, которые мы можем применить на практике, если в какой-то момент столкнемся с этим осложнением.

Очистить кеш в Windows

Первое, что мы сделаем, это очистить Кеш Windows. Мы объяснили, что это ошибка, которая может быть связана с кешем и, следовательно, является одной из причин ее появления. Это простой и быстрый процесс, который мы можем сделать.

Первое, что нам нужно сделать, чтобы очистить кеш Windows, — это перейти в «Пуск» и выполнить поиск «Очистка диска». Мы должны открыть его, и оно автоматически покажет нам новое окно, в котором нам нужно будет выбрать, какие файлы мы хотим удалить. Таким образом мы можем стереть кеш, который он сохранил.

Центр обновления Windows

Другая причина, по которой может появиться ошибка HTTP 409, заключается в том, что операционная система Windows устарела. Может быть, даже при установке обновления его поймают и выдадут ошибку.

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

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

Восстановить оборудование

Следует также упомянуть возможность восстановление оборудования к предыдущему пункту. Иногда при установке программы или настройке чего-либо мы можем столкнуться с определенными проблемами. Это приводит к ошибкам, таким как HTTP 409 или любым другим, которые препятствуют правильной работе любого приложения или службы.

Чтобы восстановить компьютер, мы должны снова зайти в Пуск и найти Создать точку восстановления и откройте его. Там мы нажмем на Восстановление системы. Нам нужно будет выбрать одну из дат, которые отображаются как рекомендованные, или выбрать другую.

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

Проверить на вредоносное ПО

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

Что мы можем сделать, чтобы проверить наличие вредоносного ПО и удалить его? Самое главное — иметь хороший антивирус , В случае Microsoft систем мы можем использовать Защитник Windows, который интегрирован. Есть также много других, таких как Avast или Bitdefender, чтобы назвать некоторые из самых популярных.

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

Убедитесь, что нет поврежденных файлов

Могли бы мы поврежденный файл в системе? Несомненно, это еще одна причина, по которой могут появляться такие ошибки, как HTTP 409. Мы должны проверить это в Windows с помощью проприетарного инструмента, который интегрирован в систему.

Нам нужно перейти в Пуск, найти командную строку и открыть ее. Затем вам нужно запустить команду sfc / scanno. Этот процесс займет несколько минут, и он должен убедиться, что в системе нет поврежденных файлов. Если он обнаружит, что что-то не так, он автоматически попытается это исправить.

В конечном счете, это некоторые важные проблемы, связанные с ошибкой HTTP 409, которая может появиться. Мы видели, что есть разные причины, такие как ошибка кеша, плохое обновление или поврежденный файл. Мы также объяснили, что нам нужно сделать, чтобы исправить это и заставить работать нормально.

Всем привет !
У меня такая проблема! Не могу восстановить Асус 6. Поначалу скачал обнову с офф сайта она не легла в систему.
Потом я искал много способов и тут нашёл утилиту (сказано было типо она поможет перейти на андро5,0 буттобы у меня чтото забрлочино в системе телефона. Я скачал утилиту Unlock Device App: Unlock boot loader!
Потом произошло пипец для меня.
++++++++++++++++++++++++++++++++++++++++
Телефон отключен: нажимаю на кнопку POwer и вместо черного экрана с надписями, просто скромное белое окно с надписью АСУС и все . Дальше запуска нет !
Начал искать разные варианты прошить! Прошил блин вылазили ошибки (
E: Can’t open /tmp/update-script.log

Finding update package.
Opening update package.
Verifying update package.
Installing update.
Device image SKU:
WW
OTA image SKU: WW
E:Error in /tmp/update.zip
(Status 0)
E: fota_return_code 409
Installation aborted.
E:Can’t open /tmp/update-script.log
E:Can’t open /tmp/update-script.log
)

потом на про кликал команды ( fastboot flash fastboot fastboot.img
fastboot flash boot boot.img
fastboot flash recovery recovery.img — выдавала ошибку сволочь .
fastboot reboot

далььше производил прошивку и выдавала разные мне ошибки fota_return_code 409 и вроде 403.
Щас телефон как бревно лежит и не работает! Что подскажите ?
Прошу вас говорит по теме тупые и не в темные комментарии попусту ненужно.

Ошибка HTTP 409 Conflicting Request – это конфликт между запросом пользователя и сервером, к которому он обращается. Например, есть сайт, с которого пользователь хочет скачать файл с названием «файл1», но этот файл раньше был на сервере и его упоминание сохранилось в кеше. Однако, теперь файл называется “файл01» и сервер не понимает, что пользователь хочет от него. Это очень образный пример для того, чтобы максимально понятно определить значение ошибки.

Ситуации при которых возникает ошибка 409 HTTP сильно разнятся, но сводятся к конфликту между запросами. Иногда, задавая запрос, браузер сам уходит в цикличную обработку, и он либо закрывается, либо виснет так, что пользователю ничего не остается, как просто перезагрузить компьютер. Это явление часто замечают пользователи браузера Mozilla и Opera.

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

Основные причины возникновения ошибки 409:

• Пользователь обращается к данным, имеющим отличное значение или более новую версию. В итоге, сервер выдает ошибку 409, т.к. существует обновленная версия файла, страницы или скрипта.
• Ошибка 409 появилась в результате конфликтующих запросов внутри файлов на сервере. Решить проблему может программист.
• Использование прокси, которое конфликтует с определенными адресами или форматами запрашиваемых данных. Не путайте эту ошибку с ошибкой 407.
• Более распространенная причина – троян или вирус, который блокирует запросы к определенным сайтам или подгружает файл, который имеет конфликт с конфигурацией браузера.

Ошибка 409 Conflicting Request в большинстве случае решается системным администратором или программистом, если это не касается заражения компьютера вирусом или трояном. Как проверить и какой программой расскажем ниже.

Как исправить ошибку 409 (Conflicting Request – Конфликт запросов)?

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

1. Чистим от вируса или трояна, чтобы убрать ошибку 409

Определить вирус/троян у вас или нет просто – установите программу Cureit от Dr.Web и просканируйте систему этой программой. Она бесплатная и не требует установки. Скачиваем только с официального сайта. В программе отмечаем все пункты для проверки и шагаем спать/на работу, т.к. сама проверка займет длительное время. На скриншоте ниже вы можете рассмотреть, как и что отмечать в программе. Свой антивирус лучше отключить перед проверкой.

Чистим от вируса или трояна, чтобы убрать ошибку 409

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

1. Исправляем ошибку 409 в конкретном браузере

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

Перед удалением браузера сохраните закладки!

Заранее нужно сохранить закладки, т.к. можно потерять все нажитое непосильным трудом. Делается это просто. На скриншоте выше вы видите пример сохранения настроек в браузере Mozilla. Аналогично делается и в остальных браузерах.

1. Ошибка 409 в результате правок на сайте

Если вы являетесь администратором сайта или программистом… Вы знаете, что такое бэкап и как им пользоваться. Если не знаете – спросите в комментариях. Что с ним делать? Думаю, ответ знаете сами.

Последнее слово про ошибку

Ошибка 409 HTTP Conflicting Request редко относится к пользователю, если только это не вирус или троян. Почти 80% случаев с этой ошибкой касается разработчиков, поэтому разбираться в этом нужно точно не обычному пользователю. Все советы про чистку реестра и прочее – не актуальны. Это не относится к этой ошибке.

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

Довольно часто юзеры, привыкшие рутовать прошивки, устанавливать разного рода системный софт, менять ядра и по-другому издеваться над прошивкой, обнаруживают, что установить 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). Для этого на выключенном устройстве зажимаем одновременно кнопки

и попадаем в загрузчик, кнопкой громкости выбираем Recovery mode, входим в него кнопкой Power. Появится лежачий Android с восклицательным знаком. Это не ошибка, пугаться не стоит. Необходимо на этом экране коротко нажать

, после чего и загрузится стоковый рекавери. В нем необходимо выбрать кнопками громкости пункт apply update from ADB и подтвердить кнопкой включения. Далее необходимо подключить телефон/планшет к компу. Запускаем консоль, переходим в папку с ADB и архивом обновления и вводим следующую команду (для файла, приведенного выше):

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

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

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

Под стоковой (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):

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

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

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

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

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

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

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

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

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

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

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

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

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

Кастомный recovery

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

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

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

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

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

Именно эти значения и возвращает при проверке скрипт, прерывая обновление в самом начале и выдавая ошибку о несоответствии версии 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» — это длинные списки адресов блоков:

Это позволило инженерам 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» Подкопаев

Всем привет !
У меня такая проблема! Не могу восстановить Асус 6. Поначалу скачал обнову с офф сайта она не легла в систему.
Потом я искал много способов и тут нашёл утилиту (сказано было типо она поможет перейти на андро5,0 буттобы у меня чтото забрлочино в системе телефона. Я скачал утилиту Unlock Device App: Unlock boot loader!
Потом произошло пипец для меня.
++++++++++++++++++++++++++++++++++++++++
Телефон отключен: нажимаю на кнопку POwer и вместо черного экрана с надписями, просто скромное белое окно с надписью АСУС и все . Дальше запуска нет !
Начал искать разные варианты прошить! Прошил блин вылазили ошибки (
E: Can’t open /tmp/update-script.log

Finding update package.
Opening update package.
Verifying update package.
Installing update.
Device image SKU:
WW
OTA image SKU: WW
E:Error in /tmp/update.zip
(Status 0)
E: fota_return_code 409
Installation aborted.
E:Can’t open /tmp/update-script.log
E:Can’t open /tmp/update-script.log
)

потом на про кликал команды ( fastboot flash fastboot fastboot.img
fastboot flash boot boot.img
fastboot flash recovery recovery.img — выдавала ошибку сволочь .
fastboot reboot

далььше производил прошивку и выдавала разные мне ошибки fota_return_code 409 и вроде 403.
Щас телефон как бревно лежит и не работает! Что подскажите ?
Прошу вас говорит по теме тупые и не в темные комментарии попусту ненужно.

Ошибка HTTP 409 Conflicting Request – это конфликт между запросом пользователя и сервером, к которому он обращается. Например, есть сайт, с которого пользователь хочет скачать файл с названием «файл1», но этот файл раньше был на сервере и его упоминание сохранилось в кеше. Однако, теперь файл называется “файл01» и сервер не понимает, что пользователь хочет от него. Это очень образный пример для того, чтобы максимально понятно определить значение ошибки.

Ситуации при которых возникает ошибка 409 HTTP сильно разнятся, но сводятся к конфликту между запросами. Иногда, задавая запрос, браузер сам уходит в цикличную обработку, и он либо закрывается, либо виснет так, что пользователю ничего не остается, как просто перезагрузить компьютер. Это явление часто замечают пользователи браузера Mozilla и Opera.

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

Основные причины возникновения ошибки 409:

• Пользователь обращается к данным, имеющим отличное значение или более новую версию. В итоге, сервер выдает ошибку 409, т.к. существует обновленная версия файла, страницы или скрипта.
• Ошибка 409 появилась в результате конфликтующих запросов внутри файлов на сервере. Решить проблему может программист.
• Использование прокси, которое конфликтует с определенными адресами или форматами запрашиваемых данных. Не путайте эту ошибку с ошибкой 407.
• Более распространенная причина – троян или вирус, который блокирует запросы к определенным сайтам или подгружает файл, который имеет конфликт с конфигурацией браузера.

Ошибка 409 Conflicting Request в большинстве случае решается системным администратором или программистом, если это не касается заражения компьютера вирусом или трояном. Как проверить и какой программой расскажем ниже.

Как исправить ошибку 409 (Conflicting Request – Конфликт запросов)?

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

1. Чистим от вируса или трояна, чтобы убрать ошибку 409

Определить вирус/троян у вас или нет просто – установите программу Cureit от Dr.Web и просканируйте систему этой программой. Она бесплатная и не требует установки. Скачиваем только с официального сайта. В программе отмечаем все пункты для проверки и шагаем спать/на работу, т.к. сама проверка займет длительное время. На скриншоте ниже вы можете рассмотреть, как и что отмечать в программе. Свой антивирус лучше отключить перед проверкой.

Чистим от вируса или трояна, чтобы убрать ошибку 409

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

1. Исправляем ошибку 409 в конкретном браузере

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

Перед удалением браузера сохраните закладки!

Заранее нужно сохранить закладки, т.к. можно потерять все нажитое непосильным трудом. Делается это просто. На скриншоте выше вы видите пример сохранения настроек в браузере Mozilla. Аналогично делается и в остальных браузерах.

1. Ошибка 409 в результате правок на сайте

Если вы являетесь администратором сайта или программистом… Вы знаете, что такое бэкап и как им пользоваться. Если не знаете – спросите в комментариях. Что с ним делать? Думаю, ответ знаете сами.

Последнее слово про ошибку

Ошибка 409 HTTP Conflicting Request редко относится к пользователю, если только это не вирус или троян. Почти 80% случаев с этой ошибкой касается разработчиков, поэтому разбираться в этом нужно точно не обычному пользователю. Все советы про чистку реестра и прочее – не актуальны. Это не относится к этой ошибке.

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

Довольно часто юзеры, привыкшие рутовать прошивки, устанавливать разного рода системный софт, менять ядра и по-другому издеваться над прошивкой, обнаруживают, что установить 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). Для этого на выключенном устройстве зажимаем одновременно кнопки

и попадаем в загрузчик, кнопкой громкости выбираем Recovery mode, входим в него кнопкой Power. Появится лежачий Android с восклицательным знаком. Это не ошибка, пугаться не стоит. Необходимо на этом экране коротко нажать

, после чего и загрузится стоковый рекавери. В нем необходимо выбрать кнопками громкости пункт apply update from ADB и подтвердить кнопкой включения. Далее необходимо подключить телефон/планшет к компу. Запускаем консоль, переходим в папку с ADB и архивом обновления и вводим следующую команду (для файла, приведенного выше):

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

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

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

Под стоковой (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):

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

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

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

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

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

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

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

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

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

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

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

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

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

Кастомный recovery

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

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

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

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

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

Именно эти значения и возвращает при проверке скрипт, прерывая обновление в самом начале и выдавая ошибку о несоответствии версии 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» — это длинные списки адресов блоков:

Это позволило инженерам 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» Подкопаев