Резервное копирование/восстановление SMS/MMS через ADB на некорневом устройстве?

Есть ли способ резервного копирования/восстановления SMS и MMS-сообщений с помощью ADB, когда устройство не рутировано?

  • adb pullздесь не сработает, поскольку соответствующая база данных ( /data/data/com.android.providers.telephony/databases/mmssms.db) не может быть прочитана ADB, если она не работает в небезопасном (корневом) режиме.
  • adb shell "cat /data/data/com.android.providers.telephony/databases/mmssms.db > /sdcard/mmssms.dbбез рут прав тоже не работает
  • adb backupпо какой-то причине не распространяется на эту базу на том устройстве, с которым я проверял (пустая резервная копия — только 41 байт заголовка резервной копии в результирующем файле)

Я особенно удивляюсь, почему adb backupне покрывает это. Если это из соображений конфиденциальности, то то же самое должно относиться и к базе данных контактов, которая явно имеет резервную копию.

Использованная литература:

Итак: любое решение на нерутированном устройстве? Обратите внимание, что я НЕ прошу решения на основе приложений. Я прекрасно знаю, что для этого есть несколько приложений . Я специально хочу, чтобы «решение на основе оболочки» использовалось через ADB.

« Я НЕ прошу решения на основе приложений » — Опять криминалистика?
Предпочтительно да (для других читателей: предпочтительные решения не требуют каких-либо изменений на устройстве). Учтите, что рассматриваемое устройство уже сообщает «недостаточно памяти», поэтому установить что-либо не представляется возможным. Поскольку устройство ведет себя странно и в другом контексте, необходимо выполнить сброс до заводских настроек, поэтому было бы неплохо «сохранить» как можно больше данных. Я смог сделать резервную копию большинства вещей через adb backup: несколько исключений, большинство из них можно игнорировать, но пользователь очень любит хранить SMS, которые также не были защищены.
Привет! Извините за беспокойство, у вас когда-нибудь было решение этой проблемы без рута? Кстати, отличный список приложений, спасибо за ссылку!
@Gruber Нет, до сих пор ничего не нашел. // Рад, что вам нравятся мои списки приложений!

Ответы (1)

Мне особенно интересно, почему резервная копия adb не распространяется на это.

Дело не в том, что adb backupон не хочет покрывать приложение com.android.providers.telephony. Это приложение мало чем отличается от любого другого системного приложения, основанного на его AndroidManifest.xml. Проблема заключается в флаге, объявленном его разработчиком в манифесте, который по какой-то причине adb backupдолжен соблюдаться как механизм по умолчанию.

Этот флаг есть не что иное, как android:allowBackup="false". Он отключает приложение как от резервного копирования, так и от восстановления ADB. Google здесь должен сказать:

android:allowBackup

Разрешить ли приложению участвовать в инфраструктуре резервного копирования и восстановления. Если для этого атрибута установлено значение false, никакое резервное копирование или восстановление приложения никогда не будет выполняться, даже путем резервного копирования всей системы, которое в противном случае привело бы к сохранению всех данных приложения через adb. Значение по умолчанию этого атрибута — true.

(выделено мной)

Проверьте AndroidManifest.xmlэто приложение для версии Lollipop здесь или посмотрите это свидетельство для моего Android 4.2.1:

IMG: нет флага резервного копирования

В этом приложении есть еще кое-что. Вы даже не можете очистить данные из «Настройки» → «Приложения» → «Все приложения» →<THIS_APP> , так как android:allowClearUserData="false"это тоже объявлено, а не то, с чем мы сталкиваемся время от времени.

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

Странно не то, что вы можете это сделать, а то, как ваша система позволяет вам делать это только с помощью adb backup!

Хранение контактов обрабатывается приложением «ContactsProvider», которое называется pkg_name= com.android.providers.contacts. Этот флаг android:allowBackup="false"четко упоминается AndroidManifest.xmlдля Jelly Bean (нажмите здесь, чтобы увидеть другие версии).

Вы используете ICS или какой-либо предшественник JB?

Я обнаружил, что в этом приложении нет объявления этого флага для ICS здесь . На самом деле вы можете разгадать эту загадку, поскольку я не могу сделать резервную копию этого приложения в своем JB 4.2.1 в соответствии с определением флага и всегда получаю этот 41-байтовый файл резервной копии.


Что касается любого другого метода резервного копирования/восстановления SMS/MMS с помощью ADB без root-доступа – все руки вверх.

Я знаю, что это тот самый флаг. Но и это приложение, и ADB являются частью системы — здесь мы не говорим о стороннем поставщике. Для пояснения: устройство, на которое я ссылаюсь, работает на JellyBean (4.1.2). Благодаря вашей подсказке попробую еще раз с другими своими устройствами (4.2 и 4.3). Касательно конфиденциальности: также может быть подсказка о том, что пользователь должен ввести пароль. Кроме того, SharedStorage может также содержать «личные данные» — плюс Google предполагает, что я хочу синхронизировать свои контакты / календари по умолчанию при включении учетной записи Google, вместо того, чтобы спрашивать меня (поэтому нет возможности отказаться, если вы добавите его с ними уже там ).
Опасность того, что это станет разглагольствованием: если это слишком личное для резервного копирования, почему тогда оно также защищено от «чистых данных»? «Никогда не приписывайте злому умыслу то, что можно объяснить чистой глупостью»… // Итак, без рута это невозможно: остается только соответствующий модуль Xposed («Резервное копирование всех приложений»). Что снова необходимо установить на устройство — чего я хотел избежать… Простое извлечение базы данных (с корнем) было бы обходным путем — но это не позволяет восстановить кросс-устройство (пробовал это один раз, не было хорошая идея, так как это сделало SMS непригодным для использования, поэтому мне пришлось сбросить настройки)
Я знаю @Izzy, что вы знаете о таком простом флаге (вы не стали профессионалом из воздуха, а благодаря исследованиям и опыту :), но другие, ищущие ответы на такой простой вопрос, вероятно, не знают об этом, и все этой информации не подходит для комментария. На самом деле я имел в виду написать этот комментарий, но забыл об этом в конце, когда писал этот ответ, извините!
// Что касается пароля, хотя ADB обеспечивает защищенную резервную копию, возможно, Google (IMO) считает, что предотвращение доступа к конфиденциальному контенту лучше, чем разрешение доступа, который в случае потери устройства может привести к сбросу данных несанкционированным человек, если случайно была включена отладка по USB с последующей атакой методом грубой силы.
// Что касается синхронизации, то компания обычно ничего не делает бесплатно, если только бизнес не вовлечен, а наличие данных каждого отдельного пользователя — это довольно много данных для исследования и для клиентов, которым они могут понадобиться, // я не знаю, как «чистые данные», только засвидетельствовал это в XML, поэтому написал об этом, // Шансы очень малы без рута, и это означает полную зависимость от резервного копирования Google Cloud на устройстве без рута, о котором многие OEM-производители заботятся об этом, поскольку гарантия на устройство аннулируется. политики, чтобы многие пользователи вообще не рутировались
-- да ну, они с самого начала придумали, как ограничивать свободу во имя бизнеса, может быть, еще что-то. Я сообщу что-нибудь хорошее (конечно, не разглагольствование), если как-то столкнусь.
LOL к последнему предложению вашего последнего комментария - особенно к if-условию :) И, может быть, нам следует посмотреть, что из этих комментариев следует интегрировать в ваш ответ (за вычетом ~ 70% тирад, включенных нами обоими), а затем очистить? Тем временем я проголосовал за него (для фона, который вы так подробно описали). Не решая проблему на самом деле, я не осмеливаюсь «принять» ее — хотя «невозможно, поскольку…» — вполне правильный ответ. Это будет не первый раз, когда неожиданно здесь, в ASE, появляется решение «кажущейся невозможной» (и на один из моих вопросов).