hi
I have the p6800.
does anybody knows how to Data Wipe/Reset/dalvik through ADB?
For the dalvik part of your question, the commands are the same as here: http://forum.xda-developers.com/showthread.php?t=1500618
You may not need the su command if your adb already has root privileges.
Instead of the exit command, you could use reboot (if that is the next thing you planned to do).
For ICS
Also to add if your upgraded to ICS, dalvik-cache is splitt /data/dalvik-cache is for installed apps and system apps in
cd /cache/dalvik-calche
rm*
Related
So I've rooted and installed the new recovery on my incredible. I want to remove CityID now, forgot to after root. When I launch recovery and run adb devices it shows my device. I then run adb shell, immediately getting the # for su (instead of the $ prompt for non su access). I execute /system/bin/rm /system/app/CityID.apk as instructed by the wiki and get /sbin/sh: /system/bin/rm: not found. I browse to /system/bin and do a listing and see nothing. So am I doing something wrong?
**EDIT**
Forgive my ignorance, but I forgot to mount system in the partitions menu of recovery. Doubtful this would be of any help to anyone, but there ya go.
Also in the How To:
StirCwazy said:
So I've rooted and installed the new recovery on my incredible. I want to remove CityID now, forgot to after root. When I launch recovery and run adb devices it shows my device. I then run adb shell, immediately getting the # for su (instead of the $ prompt for non su access). I execute /system/bin/rm /system/app/CityID.apk as instructed by the wiki and get /sbin/sh: /system/bin/rm: not found. I browse to /system/bin and do a listing and see nothing. So am I doing something wrong?
**EDIT**
Forgive my ignorance, but I forgot to mount system in the partitions menu of recovery. Doubtful this would be of any help to anyone, but there ya go.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=709220 - It's a few posts down, but will update first post later today.
Hi all,
Ive spent to weekend reading about rooting and ROMS/Kernels and decided to try it. I used a root kit found here from Mskip (great kit). Ive sucessfully rooted, and then sucessfully installed Smooth Rom 4.3 with the Motley kernel.
Ive downloaded Titanium Backup and Rom Manager. TB worked and I did a backup (which I now cant find) (i have ES File Explorer). I upgraded to Titanium Pro, and now when I open the app is states root was denied. I remember when I first opened TB SuperSu asked me to grant it access. After a reboot I opened SuperSu and stated a Binary update was necessary and performed it.
Now TB pro states root was denied, when I open SuperSu there is nothing there in the apps list, and I dont know how to manually grant TB root access.
Sorry if this is noobish, not sure what to do and I dont want to keep going without a backup.
Edit: When I try to backup in ROM Manager I hit backup, it brings up the notification to name the backup, I hit ok and nothing happens.
cam75 said:
After a reboot I opened SuperSu and stated a Binary update was necessary and performed it.
Now TB pro states root was denied, when I open SuperSu there is nothing there in the apps list, and I dont know how to manually grant TB root access.
Click to expand...
Click to collapse
That sort of sounds like the SuperSU "su" update might have failed. Can you get root with other apps? (e.g. go in to a terminal emulator and type "su")
Note there is a chicken-and-egg problem if (either) SuperSU/su or Superuser/su fail: they need root themselves to remount /system so that the "su" binary can be updated.
If no apps can get root, then you sort of have "lost root", and the fix is to manually insert the .apk and su binary into /system/app and /system/bin/su (or /system/xbin/su depending on flavor!) either with a flash package in recovery, or manually via the adb shell command line (with custom recovery running).
HTH
PS you should be able to just manually start the recovery and do a backup in the meantime, no? The fact that ROM manager isn't doing anything could either be a lack-of-root problem or something else (a busybox dependency?)
bftb0 said:
That sort of sounds like the SuperSU "su" update might have failed. Can you get root with other apps? (e.g. go in to a terminal emulator and type "su")
Note there is a chicken-and-egg problem if (either) SuperSU/su or Superuser/su fail: they need root themselves to remount /system so that the "su" binary can be updated.
If no apps can get root, then you sort of have "lost root", and the fix is to manually insert the .apk and su binary into /system/app and /system/bin/su (or /system/xbin/su depending on flavor!) either with a flash package in recovery, or manually via the adb shell command line (with custom recovery running).
HTH
PS you should be able to just manually start the recovery and do a backup in the meantime, no? The fact that ROM manager isn't doing anything could either be a lack-of-root problem or something else (a busybox dependency?)
Click to expand...
Click to collapse
thx for the quick response, however much of that is WAY over my head. I opened terminal emulator and typed su and this is what popped up. 1 [email protected]:/ $
When TB is opened it states error "sorry I could not acquire root privilegdes. this applidation will not work. please verify that your rom is rooted and try again. this attempt was made using the "/system/xbin/su" command.
I dont see busybox in my app drawer
cam75 said:
thx for the quick response, however much of that is WAY over my head. I opened terminal emulator and typed su and this is what popped up. 1 [email protected]droid:/ $
Click to expand...
Click to collapse
If the SuperSU app (and companion binary) were working correctly, you should have seen one of those "Accept / Deny" pop-up messages coming from the SuperSU app... assuming that you didn't previously grant root access to that terminal emulator app. You didn't mention that happening.... ?
Also, usually the command prompt usually changes from $ to # when you have root, but not always; the explicit way to check would be to (after you have tried the "su" command) to type in "id" and hit return at the prompt - that will tell you explicitly if you are root or not. (That's the letter "i" followed by the letter "d" followed by the return key).
From the way you describe this, it is sounding like you lost root.
I gotta go watch part of the game. In the meantime, perhaps you should at least create a backup manually.
As I said, the simplest fix-up would be to get Superuser.apk/su or SuperSU/su re-installed into /system/app and /system/{x}bin/su (it seems that chainsDD and chainfire use different locations).
There might be floating around someplace a flashable zip file with this stuff in it - to be used for "lightly rooting" a stock ROM after a custom recovery is in place. But things have been in flux recently with both the SuperSU (chainfire) and Superuser (chainsDD) kits because of the JellyBean multi-user support, so the version you might need is important. So you would have to do the research to figure out where.
gotta go - good luck.
bftb0 said:
If the SuperSU app (and companion binary) were working correctly, you should have seen one of those "Accept / Deny" pop-up messages coming from the SuperSU app... assuming that you didn't previously grant root access to that terminal emulator app. You didn't mention that happening.... ?
Also, usually the command prompt usually changes from $ to # when you have root, but not always; the explicit way to check would be to (after you have tried the "su" command) to type in "id" and hit return at the prompt - that will tell you explicitly if you are root or not. (That's the letter "i" followed by the letter "d" followed by the return key).
From the way you describe this, it is sounding like you lost root.
I gotta go watch part of the game. In the meantime, perhaps you should at least create a backup manually.
As I said, the simplest fix-up would be to get Superuser.apk/su or SuperSU/su re-installed into /system/app and /system/{x}bin/su (it seems that chainsDD and chainfire use different locations).
There might be floating around someplace a flashable zip file with this stuff in it - to be used for "lightly rooting" a stock ROM after a custom recovery is in place. But things have been in flux recently with both the SuperSU (chainfire) and Superuser (chainsDD) kits because of the JellyBean multi-user support, so the version you might need is important. So you would have to do the research to figure out where.
gotta go - good luck.
Click to expand...
Click to collapse
Thanks again.
Im watching Superbowl as well. I didnt grant Terminal access. I rebooted into recovery and restored to right after I rooted. SuperSu auto updated through the play store, and stated the binary need updated. I canceled that. TB and ROM manager are showing up in SuperSu. So now Im rebooting into recovery again to after I installed the Smooth Rom/Motley Kernal. I did make a backup of where SuperSu lost root. I now have three backups.
Question on installing the SuperSu apk file. I want to be sure I do it right, if needed. Download the file on my 7. it will go to my download folder. Move it to the system folder and open/run it? what do i do with the current SuperSu folder?
thanks again
I went to my restore point after root and reinstalled 4.3 Smooth ROM Mkernel. I did not take the SuperSu update, (ill wait for the next update) and everything is fine TB an ROM manager working fine, did a backup in both.
Thanks for your help on this.
cam75 said:
Question on installing the SuperSu apk file. I want to be sure I do it right, if needed. Download the file on my 7. it will go to my download folder. Move it to the system folder and open/run it? what do i do with the current SuperSu folder?
Click to expand...
Click to collapse
Dealing with .apk's is not that difficult - drop them into the correct place and reboot.
In Android, apps (.apk files) are stored in one of two places: /system/app or /data/app. It is even possible for two versions of an app to be on the phone - one in /system/app and one in /data/app; that is how upgrades of factory-installed apps happen: the pre-installed app is in /system/app... and never gets deleted (read-only filesystem), whereas update versions get dropped into /data/app. Generally you can just drop an .apk file into either of these locations, wipe the dalvik cache and reboot. During the android boot, these files are compiled into .dex objects in the dalvik-cache, and various version, consistency, rights and permissions are cross-checked.
Think of it this way: when you boot a new ROM for the first time, /data starts out completely empty. Everything needed to support each pre-installed app in /system/app gets created automatically during the android layer start-up.
The "su" native binary is a bit more complicated - it needs to be:
- owned by the user.group root.root
- be executable
- be setuid/setgid
Imagine that you had a copy of these two files on your "/sdcard". If you booted into the custom recovery, you could affect these changes like this:
C:\foo> adb shell
# mount # show what is already mounted
# mount /sdcard # if needed
# mount /system # if needed
# mv /system/app/SuperSU.apk /system/app/SuperSU.apk.old
# cp /sdcard/SuperSU.apk /system/app/SuperSU.apk
# mv /system/xbin/su /system/xbin/su.old
# cp /sdcard/su /system/xbin/su
# chown root.root /system/xbin/su
# chmod 6755 /system/xbin/su
# cd /
# umount /system
# exit
C:\foo>
*
As a practical matter, it is probably easier to just make sure to make a fresh backup if you are about to update the su binary - in case anything goes wrong. It might also be useful to use a root-aware file manager to remount the /system partition in rw mode prior to doing the "update su binary" procedure in the SuperSU app.
Good luck
* note that SuperSU and Superuser apps choose different locations for the su executable file - one uses /system/bin/su and the other /system/xbin/su. There might also be a symlink between these locations. Best policy is probably to examine a known-working installation to determine how to proceed.
Hi, i need a fix for this and fast !!! I've tried all that is listed on xda about this issue, but to no avail. Anyway, i forgot my pattern and went to the forgot pattern menu. My wifi was off, so i figured it would give a prompt of some kind to turn on the wifi and then log on to my google account. But nooooo, google supposes that everyone's wifi is on all the time. Please help, what do i do ? I rebooted to recovery, i made a nandroid and currently i am adb pulling the twrp folder from my N7. I would have just factory reseted it, no probs, but i remembered i have some EXTREMELY important works in colornote that i can't afford to lose. Please help, what do i do ?????
Looks like you answered your own question. Unless your Android isn't encrypted, just boot into TWRP and backup your data using adb:
adb pull /data/data C:\backup
Click to expand...
Click to collapse
The main thing you will have to concern about is restoring those data and make it readable by the app. There are several ways, but you can either:
adb push C:\backup\colornotes /data/data/colornotes
Click to expand...
Click to collapse
Don't forget some devices you need to give it write permission first: adb remount rw, though should not be needed with TWRP. Or just copy the folder back using a rooted file manager.
Then go into adb shell and fix permission of the files so the app can get access to them:
adb shell
su - (again shouldn't be needed wile in TWRP)
chmod -R 644 /data/data/colornotes (or 777 for full access)
Click to expand...
Click to collapse
Tips while in adb shell:
Check permissions of files by typing: ls -la
Check what partition is mounted and whether you have write privilege to it by typing: cat /etc/fstab
Also, if you use a custom rom like CyanogenMod or AOKP, there is an option to enable all widgets on the lockscreen. Just put the Power Control widget on the lockscreen, then you can toggle WiFi on and off. (Can't remember if this is also possible with stock.)
Have fun.
OR have a look here.
Looks like either of the two methods suggested would be feasible with only a recovery running, but the 2nd one is easiest (as a custom recovery wouldn't necessarily provide a statically-linked sqlite3 utility).
if it works it doesn't require any wiping.
BTW guess how I found this.... wait for it .... wait for it.... wait for it.... I used google search.
Hi, i forgot to mention that i made the twrp backup while i was locked out and whenever i try to restore from the backup after a factory reset, it goes back to square one... And when i did a full wipe and hoped to use titanium backup to extract stuff from the nandroid, it just gives me and empty list, but the backup is there, all 5gb of it
iAndroidOS said:
Hi, i forgot to mention that i made the twrp backup while i was locked out and whenever i try to restore from the backup after a factory reset, it goes back to square one...
Click to expand...
Click to collapse
Well, that is to be expected, is it not? You are restoring exactly what is already there - effectively a no-op.
OK, I just booted into TWRP (2.4.1.0) and confirmed that the (equivalent of the) following disabled my pattern lock on the next boot:
cd /data/system
mkdir foo
mv locksettings.* foo
mv gesture.key foo
I did all of the above (the 'cd' command is implicit) using TWRPs touch interface - didn't even need adb.
ymmv as I am using jdq39/4.2.2 and my tablet was not in a "locked-out" state, but its an easy thing to try.
I'm trying to recover some lost pictures from cache. I can't root because my bootloader is still locked, and unlocking it will wipe the very data I'm trying to recover... Is there any way for me to get read-only access to my cache, without first wiping the phone?
What exactly will adb backup/restore keep? Will it save my cache? I've heard people say it stores literally *everything* and others say it won't back up the cache and some other system files?
The djrbliss motochopper toolkit http://forum.xda-developers.com/showthread.php?t=2233852 would be absolutely perfect, except that I'm running 4.3, and I don't know of any way to downgrade without wiping the phone... One Click Root also would be perfect, except they don't support the Nexus 4...
Is there any way I can root access, or at least read/pull these files, without wiping the device?
I've been searching frantically for days now, I'd pay good money to have those pictures back If I can get these pictures off, you can bet I'm rooting immediately!
Nexus 4, running 4.3 build JWR66Y all stock
If all you want to do is be able to access files on your cache partition, you could try using "adb pull /cache/".
I dont think that needs root, but i could be wrong. Nonetheless, its worth a shot. Setup adb , open command prompt, and run:
Code:
cd Desktop
mkdir cache
cd cache
adb pull /cache/
Chromium_ said:
If all you want to do is be able to access files on your cache partition, you could try using "adb pull /cache/".
I dont think that needs root, but i could be wrong. Nonetheless, its worth a shot. Setup adb, open command prompt, and run:
Code:
cd Desktop
mkdir cache
cd cache
adb pull /cache/
Click to expand...
Click to collapse
It does appear to need root - it just leaves the destination file empty? Likewise I can't access /cache/ it through FTPDroid or Total Commander, says I don't have permission
bken said:
It does appear to need root - it just leaves the destination file empty? Likewise I can't access /cache/ it through FTPDroid or Total Commander, says I don't have permission
Click to expand...
Click to collapse
I guess you need root as I just tried adb pull too and it's not working, opening the folder in adb shell is not working either so I guess you have no luck
What you could try is copying the partition using dd but I'm not sure what's the name of the partition (which block) etc ... But that *could* work. EDIT: Not working either, you still get permission denied, sorry
Sent from my Nexus 4 running Android 4.3
mihahn said:
I guess you need root as I just tried adb pull too and it's not working, opening the folder in adb shell is not working either so I guess you have no luck
What you could try is copying the partition using dd but I'm not sure what's the name of the partition (which block) etc ... But that *could* work. EDIT: Not working either, you still get permission denied, sorry
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
Thank you for trying. adb backup gave me access to all my app files, but didn't grab cache.
Here's a thought: through the backup I have an extracted .ab file with all the data for the app that wrote this data into cache. Is there a way I could replace the .apk with something that could copy this program's cache data to /sdcard, and then "restore" with this modified .apk? Would the new .apk retain the permissions of the old, and let me copy this data? Or, alternately, could I modify the .apk to allow debug mode so I can open the cache as that app in console, and adb pull then?
My next best option I can think of, is to go ahead and unlock the bootloader, let the phone reset, and then immediately root and perform data recovery, and hope I don't overwrite everything in the meantime. I'm not sure yet which USB Mass Storage methods (if any) will let me use a standard file recovery program to scan the drive. This is also my last resort, as if it screws up I'm toast.
Forensics lab got back to me, said they could "probably" do it but it'd cost me $1200 I would happily pay 120 but 1200 is absurd. Wonder what their method is to extract data...
OK I think I'm almost there!! I retrieved the .apk through my Holo Backup full system backup and decompressed it using Droid Explorer. Decompiled with apktools, changed my manifest file, and then recompiled into apk. Now I'm trying to get my new AndroidManifest.xml and resources.arsc into my .apk without mucking up the certificate... It sounds like people have had success taking the changed files out of the newly compiled apk and stuffing them into the old apk real quick without it changing the certificates, but I don't seem to be having the same luck? I'm getting this error which isn't a "no certificates error" but isn't success either. Only thing I changed was debug = "false" to "true"
Code:
c:\>adb install -r -d d:\com.xxxxx.xxxxx.apk
2490 KB/s (15989341 bytes in 6.269s)
pkg: /data/local/tmp/com.xxxxx.xxxxx.apk
Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION]
The apk I'm starting from installed fine, and I know because it reverted me to a previous version because the marketplace had just updated me over the weekend. This zip trick has also apparently worked for a few people, any suggestions other than keep trying other computers and programs?
http://www.galaxynexusforum.com/for...562-how-decompile-compile-using-apktools.html
http://forum.xda-developers.com/showthread.php?t=1658121
I'm not trying to reverse engineer this app for any evil, I only want my lost data that I only don't have because I failed to root when I should have and as soon as I have that, I'm reverting the app back to the official version. :angel:
Hi there, I'm trying to pull root directories like /system and /data without any luck. My purpose it to have them on my PC as a backup, and be able to browse them to pull out apps and pieces of data as necessary if it ever becomes necessary.
Device: Nexus 6P (North American version)
ROM: Stock 6.0.1 Rooted, using Wugfresh Nexus Root Toolkit and SuperSU
PC OS: Windows 7 PC (64 bit)
Adb is working properly and I can easily pull non-root directories like "/sdcard" and so on. I'd like to be able to backup the entire root directory ("/") or at least the child directories (like "/system" and "/data", etc.) Unfortunately, when I try
Code:
adb pull -p "/system" "C:\somewhere"
it skips a bunch of files, so I need to come up with a better method.
I've tried
Code:
adb root
and it tells me it's already running in root mode.
I try
Code:
adb remount
and it does this properly, but doesn't change the effects of all the commands I've tried.
When I run
Code:
adb shell
it enters shell and gives me # by default, so seemingly it is giving me su permission by default?
*** Oddly, when I enter "su" while in shell, it tells me "/sbin/sh: su: not found" which seems odd to me. I think it's possibly that SuperSU is installed as systemless root, or there's something else screwy here, so I guess I'm not sure how to proceed. Still, if that were case, why would adb already be running as root, and why would shell automatically give me the #?
Any help is appreciated!!
Thanks!
@Heisenberg I figured I'd tag you because of your extensive experience with the Nexus 6P in particular (and rooting.) Not sure if you may be able to shed some light on the issue here?