22

Is there any way to backup/restore SMS and MMS messages using ADB, when the device is not rooted?

  • adb pull won't work here, as the corresponding database (/data/data/com.android.providers.telephony/databases/mmssms.db) cannot be read by ADB if it's not running in insecure (root) mode
  • adb shell "cat /data/data/com.android.providers.telephony/databases/mmssms.db > /sdcard/mmssms.db doesn't work either without root access
  • adb backup for some reason doesn't cover this database on the device I've checked with (empty backup – just the 41 bytes of the backup header in the resulting file)

I especially wonder why adb backup doesn't cover this. If it's for "privacy reasons", then the same should apply to the contacts database – which clearly is backed up.

References:

So: Any solution on a non-rooted device? Note that I'm NOT asking for an app-based solution. I'm fully aware there are several apps available for this. I specifically want a "shell based solution", to be used via ADB.

Improve this question
3
  • 1
    Preferably yes (for other readers: preferred solutions don't require anything modified on the device). Consider the device-in-question already reports "insufficient memory", so it's not possible to install something. As the device is also behaving weird in other context, a factory-reset must be performed – so it would be nice to "save" as much data as possible. I was able to backup most things via adb backup: few exceptions, most of them ignorable, but user very much likes to keep SMS which also were not covered.
    – Izzy ♦
    Commented Jul 6, 2015 at 10:30
  • Hey there! Sorry to bother have you ever a solution to this without root? BTW excelent app list, thank you for that link!
    – Gruber
    Commented May 31, 2019 at 5:44
  • 1
    @Gruber No, still didn't find anything. // Glad you like my app listings!
    – Izzy ♦
    Commented May 31, 2019 at 6:04

2 Answers 2

Reset to default
11

I especially wonder why adb backup doesn't cover this.

It is not that adb backup doesn't want to cover the app com.android.providers.telephony. This app is not much different from any other system app based on its AndroidManifest.xml. The problem is with the flag its developer has declared in the manifest which as a default mechanism for some reason adb backup is bound to respect.

This flag is none other than android:allowBackup="false". It opts out the app from both ADB backup and restore. Google here has to say:

android:allowBackup

Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.

(Emphasis mine)

Checkout the AndroidManifest.xml of this app for Lollipop version here, or see this evidence for my Android 4.2.1:

IMG: no backup flag

There's more to this app. You can't even Clear Data from Settings → Apps → All apps →<THIS_APP> since android:allowClearUserData="false" is declared too, not something we encounter every now and then.

If it's for "privacy reasons", then the same should apply to the contacts database – which clearly is backed up.

It's bizarre, not that you're able to do it but how is your system even allowing you to do that just with adb backup!

Contacts storage is handled by "ContactsProvider" app which goes by the pkg_name=com.android.providers.contacts. The flag android:allowBackup="false" is clearly mentioned in its AndroidManifest.xml for Jelly Bean (click here to see for the other versions).

Are you using ICS or any predecessor of JB?

I found that this app doesn't have any declaration of that flag for ICS here. You can actually clear this mystery, since I can't take backup of this app in my JB 4.2.1 as per the definition of the flag, and always gets that 41 bytes backup file.

As for any other method to take SMS/MMS backup/restore using ADB without root access -- all hands up here.

Improve this answer
8
  • I'm aware that it's that flag. But both, that app and ADB are part of the system – we're not talking about a 3rd-party-vendor here. For clarification: the device I refer to here runs JellyBean (4.1.2). Thanks to your hint, I'll try again with my other devices (4.2 and 4.3). Concerning privacy: there could also be a hint to have the user providing a password. Plus, SharedStorage might also contain "private data" – plus Google assumes I want to sync my contacts/calendars by default when enabling a Google account, instead of asking me (so no way to opt-out if you add it with them already there).
    – Izzy ♦
    Commented Jul 11, 2015 at 16:01
  • In danger of it becoming a rant: if it's too private to be backed up – why then is it protected against "clear data" as well? "Never attribute to malice what can be explained by pure stupidity" … // So, it it's not possible without root: that only leaves the appropriate Xposed module ("Backup all Apps"). Which again needs to be installed on-device – which I wanted to avoid … Just pulling the database (with root) would be a work-around – but that doesn't allow for cross-device restore (tried that once, was not a good idea as it rendered SMS unusable so I had to reset)
    – Izzy ♦
    Commented Jul 11, 2015 at 16:07
  • 1
    I know @Izzy that you're aware of such simple flag, (you didn't become Pro out of thin air, but by research and experience :) but others looking answers for such simple question probably do not know about it, and all of this info wasn't suitable for the comment. I actually had in mind to write this comment, but forgot that in the end when writing this answer, sorry!
    – Firelord ♦
    Commented Jul 11, 2015 at 16:24
  • 1
    // As for password, while ADB does provide a pass-protected backup, may be Google (IMO) thought that preventing access to sensitive content is a better thing than to allow access which in case of device lost may result in data dump by unauthorized person if USB debugging was enabled by any chance, followed by brute force attack.
    – Firelord ♦
    Commented Jul 11, 2015 at 16:24
  • 1
    -- oh, well, they had it figured since beginning to how to restrict freedom in the name of business, may be something else. I'll report something good (non-rant of course) if I encounter somehow.
    – Firelord ♦
    Commented Jul 11, 2015 at 16:27
4

Partial answer at least, covering the backup part: you can obtain your SMS with e.g.

adb ${ADBOPTS} shell "content query --uri content://sms/ --projection ${projection}" > sms.lst

where $projection lists the fields/columns you want to extract, separated by colons. A list that seems to work on multiple devices/vendors/Android-versions which I have tested would be

--projection thread_id:address:person:date:date_sent:protocol:read:status:type:reply_path_present:subject:body:service_center:locked:sub_id:error_code:creator:seen

Similarly you can also obtain your call logs btw:

projection="type:number:formatted_number:numbertype:via_number:numberlabel:normalized_number:matched_number:countryiso:geocoded_location:date:last_modified:name:phone_account_address:lookup_uri:voicemail_uri:is_read:photo_id:photo_uri:post_dial_digits:call_screening_app_name:call_screening_component_name:transcription:transcription_state:block_reason:subscription_id:subscription_component_name:add_for_all_users:features:new:presentation:data_usage"
adb ${ADBOPTS} shell su -c "content query --uri content://call_log/calls --projection ${projection}" > calllog.lst

Want your user dictionary?

projection="word:frequency:locale:appid:shortcut"
adb ${ADBOPTS} shell su -c "content query --uri content://user_dictionary/words --projection ${projection}" > userdict.lst

Format of the output files will be something like

Row: 0 _id=4, field1=value 1, field2=value 2 …

I haven't attempted a restore yet, though (not yet needed, luckily).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .