Вопросу уже больше года, но никто так и не ответил, а такая ситуация может повторяться, хоть и не часто.
Странно, что не ответила поддержка продукта. По-моему тут можно было сделать анализ прямо по логам, коих топик стартер дал аж 3 штуки. В последнем логе - бакап данных модема - хорошо заметны строки:
USB Debugging MUST BE Enabled in Developer Options
Из чего явно следует, что утила желает работать через ADB.
Reading MODEM_FSG Partition...
Reading MODEM_FSC Partition...
Reading MODEM_ST1 Partition...
Reading MODEM_ST2 Partition...
Reading PERSIST Partition...
Куда-то читает образы разделов
А что потом?
Moving Files...
Moving MODEM_FSG File...
ERROR: Communication Failed!
Тут следует вспомнить как делается бакап разделов под Linux/Android-ом вручную.
В консоли Линукса пишем команду типа: dd if=/dev/block/.../mmcblk0p1 of=/sdcard/mmcblk0p1.img
которой "копируем" блочное устройство в файл на SD карте.
Потом уже в консоли ББ пишем команду типа: ADB pull /sdcard/mmcblk0p1.img
чтобы вытащить образ устройства (раздела) в ББ и "что-то там с ним делать".
Почему так - все банально - ADB не умеет работать напрямую с блочными устройствами как это делает сам Линукс с файлами общей корневой ФС. Поэтому сначала копируем "устройство" в файл-имидж, потом тянем файл наружу. И все прекрасно работает, но вот непременным условием такой работы является работоспособность SD карты, вернее не обязательно "внешней SD", а некой виртуальной "внутренней или внешней памяти", обозначаемой как sdcard в Андроиде, просто потому, что нужен буфер для чтения образа раздела внутри аппарата и иногда буфер должен быть очень большим, например для чтения userdata. SD карта идеально на эту роль подходит, ибо имеет большой объем и не содержит ограничения прав.
Я, конечно, не провидец, и не могу достоверно знать что там реализовал разработчик, но полагаю, что все "стандартно", посему "Reading" в логе следует толковать как копирование раздела на /sdcard, а "Moving" как перенос слитого образа на комп. В этом свете лог выглядит так, что разделы сначала нормально копируются на карту, после чего утила начинает вытягивать образы и на первом же файле происходит затык. Карта, видимо сбойная, при попытке чтения (возможно каких-то секторов) зависает (тормозит) и "Communication Failed" говорит лишь о том, что утила вывалилась по таймауту связи. Если в качестве "/sdcard" используется "внутренняя память", это означает, что проблема аналогичная, но на eMMC.
В логе "Repir IMEI" утила затыкается на "ERROR: ROOT Access Failed!", однако топик стартер утверждает, что IMEI восстановить удалось. Данный аппарат не слишком далеко ушел от референсного дизайна Qualcomm, IMEI восстанавливается путем переинициализации NVRAM (IMEI можно прописать напрямую в ITEM(ы) лишь один раз, пока он(и) не прописан(ы)) с предварительным сливом бакапа (например в QCN) и заливкой его обратно. Данная процедура выполняется через интерфейс QMI и Diag COM порт и обращения через ADB не требует (как, соотв, и рут прав). "Этапы большого пути" работы через QMI в логе почему-то не отражены, наверное "власти скрывают". Однако, после этого следует, видимо, поправить некую кастомизацию в /perpsist (касается именно этой линейки аппаратов, еще не разбирался), что, скорее всего, необходимо делать правкой файлов, на этом Ext4 разделе, через ADB. Почему завивает процедура рутинга я не знаю. Можно предполагать, что рутование производится также с использованием /sdcard как промежуточного хранилища нужных компонентов, либо аппарат просто вовремя не выходит на связь с утилой, которая вываливается по таймауту, однако, если поправить NVRAM, но НЕ поправить кастомизацию в /persist (и/или еще где-то), то аппараты этой серии именно так себя и ведут - IMEI восстанавливаются, но связи нет, о чем много "стонов" на 4пда.
В эту теорию укладывается и прошивка в первом логе. Прошивка производится "заводским" способом, через внешний загрузчик по протоколу Firehose и проходит на ура. Оно и понятно, если сбои на SD карте, которая при этом никак не затрагивается, либо на разделе userdata на eMMC, но за пределами области прописи заводского образа раздела.
В такой ситуации следует проверить работоспособность SD карты в компе или непосредственно в аппарате, а также запись на "внутреннюю память" и последующее чтение с нее значительных объемов данных.
Разработчикам, конечно, следует диагностировать подобные "примитивные" ошибки и выдавать более подробную диагностику в логах, позволяющую мастеру более активно участвовать в диагностике и принятии решений. Все равно все не "скроешь", а адекватная диагностика позволит пользователям решать больше проблем самостоятельно, в т.ч. не нагружая службу поддержки. Ну и восприятие такого продукта в глазах потребителя более благоприятное. Сегодня большинство манипуляций можно выполнить без каких либо "боксов". Инструкций как и что делать полно на профессиональных и потребительских форумах. Люди готовы платить деньги не столько за "секретные методы", сколько за быстроту и надежность решения широкого круга проблем с самыми разными устройствами. В условиях, когда за сложный ремонт платят не более неск тыс руб, а большая часть ремонтов (в части оплаты труда) измеряется в сотнях руб, на которые "ничего не купишь", на первый план выходит скорость ремонта и отсутствие подобных затыков, отнимающих время и силы. Мастер и разработчик делают общее дело и от эффективности их взаимодействия во многом зависит общий результат работы.
Всем успехов!
