-1

I am unable to create a full phone backup file of my Realme 2 Pro (model RMX1801) through the ADB. The phone runs stock ColorOS 7 (Android 10). The device is not rooted and I do not want to root it. Doing that would delete my data. Also, my device hasn't had any screen-lock protection days before I ran the very first command (which is several hours amounting to few days before the original-revision of this post) and remaining wholly unchanged to the best of my knowledge till the timestamp of latest-revision.

Here's what I've tried. I launched Command prompt (cmd.exe) and ran:

C:\Users\Dell> OneDrive\Desktop\adb.exe
C:\Users\Dell> adb devices
List of devices attached
86b3470 device

At this point I started to take backup. I have tried a couple of things and I'm categorizing them now.

Attempts when I entered no backup-encryption key whatsoever
C:\Users\Dell>adb backup -all -f -nosystem C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab 
C:\Users\Dell>adb backup -all -f -nosystem -shared C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab

Both of the commands showed on the UI that backup was taking place. But none of them created the backup file in my PC.

Attempts when I entered a backup-encryption key
C:\Users\Dell>adb backup -all -f -nosystem C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab
C:\Users\Dell>adb backup -all -f -nosystem -shared C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab

No change, whatsoever.

I also changed the destination path from OneDrive/Documents to OneDrive/Desktop and repeated all the above commands. That did not work either.

Attempts with double-quotes
C:\Users\Dell>adb backup "-f -all -nosystem C:\Users\Dell\OneDrive\Desktop\RMX1801backup.ab"    
C:\Users\Dell>adb backup "-f -all -nosystem -shared C:\Users\Dell\OneDrive\Desktop\RMX1801backup.ab"

Did not work.

Changed double quotes position
C:\Users\Dell>adb backup "-f -all -nosystem" C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab
C:\Users\Dell>adb backup "-f -all -shared -nosystem" C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab
C:\Users\Dell>adb backup -f "-all -nosystem -shared" C:\Users\Dell\OneDrive\Desktop\RMX1801backup.ab
C:\Users\Dell>adb backup -f "-all -nosystem -shared" C:\Users\Dell\OneDrive\Desktop\RMX1801backup.ab

Here's what happened in the case of double-quoted commands: All of the ones ending the double-quotes before the backup file's path appeared to have started the backup process but it did not create the backup file either. The duration of the backup process in the UI was also incredibly shorter, aka literally instantaneous, in these attempts.


As asked in the comments, the versions of adb are produced below:

C:\Users\Dell>adb version
Android Debug Bridge version 1.0.41
Version 33.0.3-8952118
Installed as C:\Users\Dell\OneDrive\Desktop\platform-tools\adb.exe

C:\Users\Dell>adb shell adbd --version

  • daemon not running; starting now at tcp:5037
  • daemon started successfully

/system/bin/sh: adbd: inaccessible or not found

C:\Users\Dell>adb devices List of devices attached 86b3470 device

C:\Users\Dell>adb shell RMX1801:/ $ adbd --version /system/bin/sh: adbd: inaccessible or not found 127|RMX1801:/ $

here are the [hitherto] unsolicited screencaps/screengrabs/screenshots: adb backup log exec.PNG

adb backup log exec #2.PNG

adb backup log exec #3.PNG

Sudden redundance of direct Desktop acces to ADB in favour of platform-tools sub-folder access.PNG

Sudden redundance of direct Desktop acces to ADB in favour of platform-tools sub-folder access pt 2.PNG

adb -f sans backup log exec.PNG

adb Chrome for Android backup exec.PNG

adb Chrome for Android backup exec #2.PNG

maazkalim
  • 39
  • 5
  • Just to make sure: When executing the adb backup command your phone display has to be on and the phone has to be unlocked, otherwise you won't recognize the screen that is shown where you have to enter the backup password. Anyway for checking if backup works correctly use adb shell and then execute the backup commands locally on the phone using the bu command instead of adb backup. This way you will get all [error] messages bu outputs. See also https://android.stackexchange.com/q/231235/2241 – Robert Jan 22 '23 at 17:18
  • Done as you asked, Mr alecxs! Alas.. My concerns have borne out, once a-gain. As referred to in this post which had direct involvement of "@Firelord". **You may also wish to pay attention on the newly-expanded part of my so-called “WOT”( precisely: the one above/preceding the adb shell part) in the original-post/"question". It has been added belatedly since I felt it was too concise enough, that it may end-up prolly giving wrong idea of my experience; especially for the target-audiences. – maazkalim Jan 22 '23 at 17:50
  • @Robert So I did part of what you asked me originally, the one-&-only part of your visible comment hitherto valid. Surprisingly, when I tried to try out the connection of device without switching from the preset-default of “Charging only”. So it didn't connect. There followed the multiple sessions of restarts and shutdowns before I realised that while I didn't turn-off "Developer Options", I had turned-off (voilà!) "USB Debugging".Unfortunately trying out this adb shell sub didn't return with an error — in fact, it didn't even execute the "Full Backup" [G]UI on my phone, no matter variables. – maazkalim Jan 24 '23 at 08:24
  • I would recommend to run adb logcat in a second cmd window. I once had a device where the manufacturer pushed a ROM with a defect bu version thus adb backup wasn't functional at all. I could see it on adb logcat where the stack trace of the error always appeared after executing an adb backup command. – Robert Jan 24 '23 at 08:40
  • Hold on.. I still have to try your belatedly original-post upon the sufficiently “readable” edits by our mutually-respected 'intermediary[?]' Mx "Firelord", Mr alexcs. So address-them-not-chronologically-but-not-entirely-either, your 2nd-/yesterday-latest 1stly: I had covered the matter of backing-up packagewise since my original-edit since get-go. It might not be sufficiently "readable", so to hold-your-fingers, read bullet-point 3 in this first-ever "cleanup", by mod Mr @Andrew T. — germinating tension there. Not exactly C for , but.. – maazkalim Jan 25 '23 at 06:05
  • Before we proceed any further, Mr @alecxs: About your “ADB version”, it appears you also missed my indication that I've two adb.exe files within the same root-folder. But I dunno whether it's an enigma for computing-based machines supposedly more compliant with binaries than the rest of universe or myself inadvertently causing it by opening the folder from platform-tools out of sheer frustration. But the directly-accessible file has gone corrupt, gives Access is denied. in cmd with the same warning from MSW10 when I try opening it manually. That is why I had to rely on that 32-bit ver. – maazkalim Jan 25 '23 at 12:37
  • Ughhhh.. That several-dozens lines of codes within hundreds-of-milliseconds i.e. too quick to follow for an average member of Human Civilisation, Mr @Robert Just to be clear (if it must), I've tried that method and generated at least ~5 screencaps/screengrabs/screenshots of with the consciously deliberate --dividers 2nd optional-argument, so as to make them more readable than any of my "worst" revision — to be rather considerate. From both of horizontal-sized to even vertical-sized windows. Sorry Not Sorry that I didn't opt to create a copy-pasted .txt out of concern for your health. – maazkalim Jan 26 '23 at 01:48
  • Done-dunna-done, Mr @alecxs! Other than Mr "Robert" here, I gave up on creating .txt copy-pasted files of my prior sessions on "whatever" version-&-bits of adb.exe for both of adb backup and adb shell-reliant bu cds, & 3-4 more — given "his" demand to redo what I've had already tried but only-&-only with adb backup. So.. Are those mercifully shorter-lines of text for my phone's each-&-every single gonna do the work for u? Or u would rather insist on creating a .txt which is, frankly, not readable for average Humankind; given there's 0 indication at all that u know whatcha for. – maazkalim Jan 26 '23 at 07:58
  • stackexchange.com is Q&A site (like a wiki) and not the right place for troubleshooting and discussion. you're better off in a forum – alecxs Jan 27 '23 at 11:54
  • Thanks for your clarity, Mr @alecxs — and I see that you've replied to me over there. But alas.. I already have done so since weeks Google's D2D transfer tool( originally named otherwise) in CloudBackup through the Activity Launcher app to open this one-time only app which was successful, just not in transferring much of app-data. Since as noted in the comment below, the device-switch apps are no longer OEM-agnostic — so I already do have a variant of that app on my app which simply treats every phone as "old" be it remaining pre-installed, or you install it on some non-BBK® brands' gizmo. – maazkalim Jan 28 '23 at 00:39

1 Answers1

0

adb help specifies usage of backup

  adb backup [-f <file>] [-apk|-noapk] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>]
                               - write an archive of the device's data to <file>.
                                 If no -f option is supplied then the data is written
                                 to "backup.ab" in the current directory.
                                 (-apk|-noapk enable/disable backup of the .apks themselves
                                    in the archive; the default is noapk.)
                                 (-shared|-noshared enable/disable backup of the device's
                                    shared storage / SD card contents; the default is noshared.)
                                 (-all means to back up all installed applications)
                                 (-system|-nosystem toggles whether -all automatically includes
                                    system applications; the default is to include system apps)
                                 (<packages...> is the list of applications to be backed up.  If
                                    the -all or -shared flags are passed, then the package
                                    list is optional.  Applications explicitly given on the
                                    command line will be included even if -nosystem would
                                    ordinarily cause them to be omitted.)

according to usage the [-f <file>] parameter requires second argument <file> which is missing on your command:

adb backup -all -f -nosystem C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab

correct usage with 2nd argument:

adb backup -f C:\Users\Dell\OneDrive\Documents\RMX1801backup.ab -all -nosystem

Note: full backup is not possible with adb. only apps with android:allowBackup=true in AndroidManifest.xml can be backed up with adb.

one can make test if adb backup is working at all with single package that allows backup, such as Chrome Browser which comes preinstalled on most devices.

example:

adb backup com.android.chrome

this will create backup.ab containing Chrome Browser app data. the location of the file is the current directory.

alecxs
  • 4,034
  • 3
  • 16
  • 34
  • https://gist.github.com/airtonix/6332922#file-adb-output-L67 – alecxs Jan 26 '23 at 10:23
  • Ha! Regardless of the fact that I dunno whether you could figure-out why the ADB version “on your phone” is not showing, in spite of following that hyperlinked thread of "@Firelord" confirming that they could since they are on a rooted device. It turns out, that you were right! As you can skim through the revisions, **the only thing wrong in my command-lines for backup commands( the 2nd-guessing by adding double-quotes not considered) was the position of file-path. When the .ab actually did get created, my light-bulb moment of finding that dir folder-path and turns out, backup-files.. – maazkalim Jan 27 '23 at 11:14
  • ...dating back to as earliest as 10[th of] this month, this year( January 2023) were created. Few were junks like veritable 0B sized to less than 5 KBs or so — and all of them without the .ab extension so they remained altogether null value of files, irrespective of their sizes. But while one was exactly the size that got created in Documents( 6.36 MBs), the largest one was at least 165+ MBs. Thereby, I've marked your reply as the correct-one, Mr "@alecxs". But since my purpose was to use ADB for device-switch purposes given the lack of pro bono OEM-agnostic solutions( in non-rooted – maazkalim Jan 27 '23 at 11:21
  • so-called AOSP ecosystems, at the very least) by now — I ran some adb restore commands but since all of those returned with "Restore ended" messages instead of ‘Restore finished’, analogous to “Backup finished” on my very different devices and yes, different forks with even 2-generations gap of public Android builds — should I ask for that as a seperate follow-up question for assistance in that regard, or following-up here is not egregiously contravening of the laws of this fora net, Mr @alecxs? – maazkalim Jan 27 '23 at 11:27