lately me and BC have both noticed settings to backup and restore "google proprietary system data". i tried to back up,but got the "run via adb" error so im not sure if these options are functional or not.(battey isnt low and a regular nandroid performed fine)
i am not sure how long its been there. ive messed with recovery images alot with my recent adb,fastboot and hboot shenanigans,so i have no idea where it may have come from.
BC said his has always been on the test phone.
both are "trackball optional recovery"
any thots?
__________________
The Delivery Guy
If someone has helped you,please click the THANKS button on that post.
Please post questions so others can benefit from the answers.
follow me on twitter @scotty1223
lately me and BC have both noticed settings to backup and restore "google proprietary system data". i tried to back up,but got the "run via adb" error so im not sure if these options are functional or not.(battey isnt low and a regular nandroid performed fine)
i am not sure how long its been there. ive messed with recovery images alot with my recent adb,fastboot and hboot shenanigans,so i have no idea where it may have come from.
BC said his has always been on the test phone.
both are "trackball optional recovery"
any thots?
Scotty,
Sorry, just saw your thread. Had a soccer game tonight when you posted this (just squeezed it in between the thunderstorms, lol ), and then got busy with my apps.
I've seen those options before, but never played with it. Here's the source of the backuptool.sh script that you are having problems with:
I'm guessing that its kind of an "old school" option that is no longer needed (maybe a precursor to Titantium Backup functionality perhaps?). This kind of seems like the "Google apps" package (gapps*.zip) that you sometimes have to download / flash on certain ROMs. Maybe the list of files that are listing in the shell script are no longer exactly correct?
It might be interesting to view the /cache/recovery/log file after this error happens to see what it actually is doing / reporting (since the "run adb" error is useless). You can just adb into your phone while recovery is running and pull the file ("adb pull /cache/recovery/log my-recovery-log.txt") and see if its a missing file or an MD5 checksum issue.
thank you mister scary,sir.glad you actually got some time for a soccer game... here in the wonderful miami river valley it seems we have to have 3 weeks of rain for every 2 days of sunshine,lol.
our main questions were where did they come from? seems alot of folks dont have em,and we were just wondering how/when/why it changed. i run Amon's recovery on my incredible as well,and i just upgraded to his latest,and BAM! there they are on that one,too. dont have these options in clockwork on my TB,and BC doesnt have em on clockwork on his inc. is it something that Amon started adding to his recovery images,so after a certain point,everyone that rooted/installed an Amon_Ra recovery has them?
on the inc,it did let me back them up. but i have no idea what exactly i backed up,or if i should ever try and restore them
so for sh*ts and giggles, i tried to view the cache/recovery long. i put in the command,and all i got was:
101 kb/s (3010 bytes in 0.029s)
wich i assume is all i will see...
so in recovery,i chose the option to move the log to the SD. looking at it,what is says is this:
Yeah, its gonna rain on us here in Indy the rest of the week...I'm not too far away from you, I guess .
Ah, sorry, I slightly misunderstood what you were asking.
Simple(-ish) answer:
Most people, especially the ones that don't have the tweaked trackball recoveries I re-compiled, have the 1.6.2 version of recovery.c (i.e., the desirec branch in the github).
This version does not include the special Google backups.
The first version of my alternate recovery, the "trackball-not-required", was built using the 1.6.2 (desirec branch) and therefore also did not include these options.
When I discovered (thanks to mhotovec and TheLedge93) that the "trackball-not-required" (1.6.2 recovery.c) did not include the SD card partitioning options, I searched the github again for a version of recovery.c that did have the partition options. I ended-up using the 1.7.1 (mahimahi branch) version of recovery.c to build the "trackball-optional" version that you are using now:
but as usual i like learning about this stuff... so the other question remains,why wouldnt it let me back them up? does my log tell you anything?
also,yes! you are pretty close,im in dayton,ohio,so i could be at your house in a couple hours if you ever need help with anything
and once again,may thanks for entertaining my whims and curiosities
No, the log doesn't show anything that I can discern (usually the important stuff and error/warning-related stuff is at the end; the bulk of this is just the output of the getprop command (you might want to redact your serial number in there, but it probably doesn't matter anymore since "the man" has other ways of knowing you are rooted, lol)).
The /dev/tty0 warning seems familiar and probably isn't anything, but I'm a little surprised nothing additional was logged (although I really didn't look at the backuptool.sh script that closely, to see if it even tries to report anything additional (I'll take a second look here in a sec...it was late last night and I was trying to hit the hay)).
Yeah, Dayton isn't too far from me... Lemme know if bobcat shows up at your house and he can come over and fix my plumbing while you and I root my new Xoom [sorry, bobcat, I couldn't resist ].
Yeah, Dayton isn't too far from me... Lemme know if bobcat shows up at your house and he can come over and fix my plumbing while you and I root my new Xoom [sorry, bobcat, I couldn't resist ].
Okay, the script is actually pretty simple. Here's what it does:
1. mount the /cache and /system filesystems
2. if you are doing a backup, then for every file in the get_files list, invoke the backup_file function for each referenced file in /system
3. the backup_file routine will copy each given file to the /cache/google directory; this function will only return a non-zero exit code when its asked to check the MD5 sum (which doesn't look likes it used/relevant here)
4. the restore_file function will copy the file from /cache/google directory back to its location as specified in the get_files list; this function does not return a non-zero exit code
I don't really see how the script would have failed for you unless it was asked to do something other than "backup" or "restore" and it clearly did not report anything relevant in the /cache/recovery/log file...
By the way, was the error on the recovery screen this?:
unable to execute backuptool.sh! [this part may not have shown]
Error : Run 'backuptools.sh' in adb!
Not really sure what is going on... You could actually boot into recovery, connect via "adb shell" and execute the "/sbin/backuptool.sh backup" command manually and see what it reports. Right after it returns, do an "echo $?" to see if the exit code is non-zero.
yup! thats the error message it gave. i just tried it again... then i tried to do it via adb and got a "sbin/sh: /sbin/backuptool.sh: not found" error
Ah, this might be because I used the "original" Amon_RA recovery.img (that was labeled as "1.6.2") as the base for the new versions and it probably did not have that tool (script) included in that somewhat early version.
Like I said in the big trackball thread, it was/is very confusing re. what actual version of things that RA used when building and packaging-up the recovery. His "1.6.2" label is a little inconsistent with what I've seen in the code and options and what was packaged in the original image.
You could grab the script from the links above and push it to the phone and run it (or if you really want me to, I can re-pack a version for you with those scripts in it).
The HTC Droid Eris launched for Verizon Wireless on November 6th in part as the carrier's first Android Phone. However it was overshadowed by the other member of the inaugural Verizon Droid duo - the Motorola Droid. The Droid Eris might look fa... Read More
attn scary! new funky options in recovery
), and then got busy with my apps.
.
