Related
Hello,
When I run adb shell, it reports back with a "$,"even though I do have root. I'm running JoeyKrim Stock With Root ROM. Odexed...
I do have superuser installed with the latest binary, and latest official busybox. Terminal emulator even detects that I have root.
Basically everything works as it should, except adb. Anybody know what's going on?
Rydah805 said:
Hello,
When I run adb shell, it reports back with a "$,"even though I do have root. I'm running JoeyKrim Stock With Root ROM. Odexed...
I do have superuser installed with the latest binary, and latest official busybox. Terminal emulator even detects that I have root.
Basically everything works as it should, except adb. Anybody know what's going on?
Click to expand...
Click to collapse
When you type adb shell, does it immediately report back with a $, or does it pause for a few and then report back with a $? If it pauses for a few seconds, look down at your phone during that time. You may be being prompted with the super user request prompt, where you need to hit allow. I'm not sure why you need to do this sometimes, but I've had it happen before. If you don't look at the phone and hit 'allow', then it times out and doesn't give you root access. So type 'adb shell', check out your phone and see if your prompted, if so allow it, and you should be good. If that is not the case, then I'm unsure what could be causing it.
k2buckley said:
When you type adb shell, does it immediately report back with a $, or does it pause for a few and then report back with a $? If it pauses for a few seconds, look down at your phone during that time. You may be being prompted with the super user request prompt, where you need to hit allow. I'm not sure why you need to do this sometimes, but I've had it happen before. If you don't look at the phone and hit 'allow', then it times out and doesn't give you root access. So type 'adb shell', check out your phone and see if your prompted, if so allow it, and you should be good. If that is not the case, then I'm unsure what could be causing it.
Click to expand...
Click to collapse
Thanks, I'll test that out. I have a pin set on superuser. Maybe that's the issue.
Just checked, and it does it right away, and does not prompt... Sigh...
Rydah805 said:
Just checked, and it does it right away, and does not prompt... Sigh...
Click to expand...
Click to collapse
Very strange. I'm not sure. Has it happened on all roms, or just the one you're currently on?
Sent from my PG86100 using Tapatalk
Rydah805 said:
Just checked, and it does it right away, and does not prompt... Sigh...
Click to expand...
Click to collapse
The first time you type su from adb shell, Superuser will display a prompt on the screen to accept or deny the request. If you don't accept the request, in adb shell it will display, "Permission denied".
On the Superuser prompt, if you select deny, when typing su in adb shell the result will always be "Permission denied" until going into the Superuser app and changing "Unknown" to Allow. Not sure why the Superuser app labels adb shell as "Unknown".
Another option, inside the Superuser app, on the Settings tab, at the very bottom there is an option, update su binary. Sometimes using this update feature will resolve permission/installation issues with the su binary.
If you wanted to verify the installation of both Superuser and root as having been done properly, my free app Root Check from the market works well. Advanced Mode should provide all the details we'd need to troubleshoot further.
Hope that helps and appreciate your support!
joeykrim said:
The first time you type su from adb shell, Superuser will display a prompt on the screen to accept or deny the request. If you don't accept the request, in adb shell it will display, "Permission denied".
On the Superuser prompt, if you select deny, when typing su in adb shell the result will always be "Permission denied" until going into the Superuser app and changing "Unknown" to Allow. Not sure why the Superuser app labels adb shell as "Unknown".
Another option, inside the Superuser app, on the Settings tab, at the very bottom there is an option, update su binary. Sometimes using this update feature will resolve permission/installation issues with the su binary.
If you wanted to verify the installation of both Superuser and root as having been done properly, my free app Root Check from the market works well. Advanced Mode should provide all the details we'd need to troubleshoot further.
Hope that helps and appreciate your support!
Click to expand...
Click to collapse
Yep that does work on his rom the "type su" thing and thanks for your root check app Joey it's been super useful in trying to figure out stuff lately on the photon.... really appreciate all your contributions
joeykrim said:
The first time you type su from adb shell, Superuser will display a prompt on the screen to accept or deny the request. If you don't accept the request, in adb shell it will display, "Permission denied".
On the Superuser prompt, if you select deny, when typing su in adb shell the result will always be "Permission denied" until going into the Superuser app and changing "Unknown" to Allow. Not sure why the Superuser app labels adb shell as "Unknown".
Hope that helps and appreciate your support!
Click to expand...
Click to collapse
Got it! Thanks! Any idea why I had to do that with your rom though? On others, I didn't need to type Su and grant it. (Doesn't bother me though.)
Rydah805 said:
Got it! Thanks! Any idea why I had to do that with your rom though? On others, I didn't need to type Su and grant it. (Doesn't bother me though.)
Click to expand...
Click to collapse
Short answer: Since Superuser.apk is another developer's software, I didn't include it in my ROM as I didn't have his permission. I provide the superuser apk market link in my ROM OP for users. Instead of packaging Superuser apk, I used the su binary provided in AOSP as its source code is public and publically available for android usage.
Long answer: There is a free version of Superuser available thru the market and figured that would be the best way to load the Superuser apk. From personal experience as an android developer, when an app is provided with a ROM, it doesn't appear in the developer's market statistics and essentially is "off the radar". Which makes it more difficult to track which devices have loaded the software, which versions of android, etc and makes it more difficult to prioritize software upgrades to the application.
Hope I was able to explain and it helps!
joeykrim said:
Short answer: Since Superuser.apk is another developer's software, I didn't include it in my ROM as I didn't have his permission. I provide the superuser apk market link in my ROM OP for users. Instead of packaging Superuser apk, I used the su binary provided in AOSP as its source code is public and publically available for android usage.
Long answer: There is a free version of Superuser available thru the market and figured that would be the best way to load the Superuser apk. From personal experience as an android developer, when an app is provided with a ROM, it doesn't appear in the developer's market statistics and essentially is "off the radar". Which makes it more difficult to track which devices have loaded the software, which versions of android, etc and makes it more difficult to prioritize software upgrades to the application.
Hope I was able to explain and it helps!
Click to expand...
Click to collapse
Gotcha, I'm not complaining, just wondering why. I've always loved your roms over any others. Any way I can easily set it to use the superuser app binary over aosp binary?
ADB starting with root depends on the ro.secure property; if you type "getprop ro.secure" it should show either 0 meaning ADB keeps root or 1 meaning you have to use su for root. Just about all custom kernels/ROMs use unsecured boot.imgs but you can always change it yourself by modifying the default.prop file packed in the boot.img.
This is also what people are referring to when they say the kernel/boot.img/rom is secured or unsecured.
Rydah805 said:
Got it! Thanks! Any idea why I had to do that with your rom though? On others, I didn't need to type Su and grant it. (Doesn't bother me though.)
Click to expand...
Click to collapse
xHausx said:
ADB starting with root depends on the ro.secure property; if you type "getprop ro.secure" it should show either 0 meaning ADB keeps root or 1 meaning you have to use su for root. Just about all custom kernels/ROMs use unsecured boot.imgs but you can always change it yourself by modifying the default.prop file packed in the boot.img.
This is also what people are referring to when they say the kernel/boot.img/rom is secured or unsecured.
Click to expand...
Click to collapse
Rydah805 said:
Gotcha, I'm not complaining, just wondering why. I've always loved your roms over any others. Any way I can easily set it to use the superuser app binary over aosp binary?
Click to expand...
Click to collapse
Ah! Your question in the first quote above could be intrepreted two different ways. I provided one answer for one intrepretation and Haus provided the other answer for a different intrepretation!
I'll try and bring both together. There are two primary ways to access the shell interface on an android device.
1) Via adb shell. When typing adb shell and it opens the connection to the device, by android standard, it drops you to a shell with non root access reflected with the $ prompt. As Haus articulated above, this can be modified in the /default.prop file inside the ramdisk of the boot.img file. There are two options, have adb shell drop to root access or have adb shell drop to non root access. Many custom kernels modify this option so the user drops to root access.
In my kernel I'm using a non-modified stock kernel so it drops to non root access. I prefer to have to type su, once in the shell, to elevate to root access. Mainly because most functions I perform in adb shell I don't want root access for.
2) Via terminal emulator/connectbot. When accessing the shell directly on the device thru one of the common android applications, these generally open up a standard "sh" or non root shell. Then by typing "su" the user can elevate to root access (if the device has the su binary, etc.).
There are two main options for how to handle the "su" command inside a shell on the android device.
1) Superuser.apk - this application provides its own su binary, which hooks into the android application. Whenever su is called, the Superuser application is therefore called and allows the user to accept/deny root access requests.
2) su binary - from aosp or busybox. this is a version of the su binary more common to android developers in aosp, or the busybox version is more common to a generic linux version. the aosp version of su will grant any user/application root access. the busybox version will grant any user/application root access but does rely on an /etc/passwd and /etc/group file for permissions.
To answer your previous question, why you haven't had to type su on other custom ROMs, as Haus explained, they probably modified adb shell access in the /defult.prop file to automatically elevate adb shell to root priviledges.
To answer your last question regarding Superuser.apk and aosp su. Once you install the Superuser.apk file and it properly installs its own version of the su binary, it has now overwrite the previous aosp su binary. Superuser will now control all root access requests. Once you grant an application, adb shell, titantium backup, root explorer, or whatever application root access with Superuser, it will not prompt again and will handle every future request with the default action (grant/deny) provided.
Hope the extra details help!
Thanks, wasn't trying to be a pest. Just curious. The info in this thread is a nice thing to know.
Hi all!
This question may seem a little dumb.. But I'm trying to understand what configuration file (if it's that kind of thing used) gives the "shell" uid on my phone but a root uid on the emulator when I type "adb shell" command.
If someone could point out the process used, that would be great.
Thanks!
Nobody can give me a hint on my question?
Nerver mind, found the answer with the ps command..
All depends on the uid running adbd. On the emulator the uid is root and ion my phone it's shell.
I also believe in build.prop or default.prop or something. That ro.secure controls whether adb is root.
Thanks, I'll try to dig that.
in the ramdisk of your boot image you have a file called default.prop
if the setting in that file have:
persist.service.adb.enable=1
you get a root shell, if it has
persist.service.adb.enable=0
You do not get a root shell, basicly that is what you change when you root a phone or tablet, and then normally also add su and busybox to /system/xbin, and add the Superuser apk.
Per
If you type su on the prompt, you get root, nothing tricky.
yareally said:
If you type su on the prompt, you get root, nothing tricky.
Click to expand...
Click to collapse
Nothing tricky indeed, but you need a rooted phone to do this..
foxl3y said:
Nothing tricky indeed, but you need a rooted phone to do this..
Click to expand...
Click to collapse
True. I was just under the notion they had root.
I have your ICS root ready, how about we call it TPSparkyRoot. I based my research on code written by Dan Rosenberg (similar to what jchase did with NachoRoot in the fact that chown/chmod follows symlinks even when set during startup), here is a link to that research http://vulnfactory.org/blog/2011/08/25/rooting-the-droid-3/
**UPDATE**
Android's source has been patched so that future OEMs can not leave this hole open by accident.
https://android-review.googlesource.com/#/c/36035/
**UPDATE**
This method has been shown to work on the HTC One X see forum
http://forum.xda-developers.com/showthread.php?t=1644167
Theoretically this should work on Honeycomb versions of the Prime as well, since the Honeycomb update is where I found the flaw that is being exploited. I have confirmed this works on my Prime.
**UPDATE**
This exploit does not currently work for the latest ICS update released (v9.4.2.11 on 1/18/2012). You can use OTA Rootkeeper to backup your root prior to updating using OTA, which I have confirmed to work on my device, (this may not work if you push the update manually).
https://market.android.com/details?id=org.projectvoodoo.otarootkeeper
For the devs out there, it does not to honor the ro.kernel.qemu=1 setting within the local.prop because it is already set to blank by that point by the build.prop
You must have your Prime set up to use adb and your adb location contained in your path variable (windows) or unzip the files from my zip into that directory before running.
**UPDATED**
If you are have issues getting adb working, make sure asus sync is not running, if it is then kill it.
adb shell mv /data/local/tmp /data/local/tmp.bak
adb shell ln -s /data /data/local/tmp
adb reboot
adb shell rm /data/local.prop > nul
adb shell "echo \"ro.kernel.qemu=1\" > /data/local.prop"
adb reboot
adb shell id
//IF ID IS 0/root THEN CONTINUE, ELSE START OVER>
adb remount
adb push su /system/xbin/su
adb shell chown 0.0 /system/xbin/su
adb shell chmod 06755 /system/xbin/su
//UNDO EVERYTHING EXCEPT su
adb shell rm /data/local.prop
adb shell rm /data/local/tmp
adb shell mv /data/local/tmp.bak /data/local/tmp
adb reboot
**UPDATE** As jchase stated "If your device "bootloops" don't stress, just follow through with the commands as it "loops" ro.kernel.qemu can do funky stuff." I did notice this in my rooting but just assumed it was normal as this is my first use of adb.
**UPDATE2**
If you get a permissions error on the call
adb shell "echo \"ro.kernel.qemu=1\" > /data/local.prop"
then you may try
adb shell rm /data/local.prop
And then try the echo command again. This may be due to having rooted prior without cleaning up properly. Thanks to Franky_402 for this piece of info.
I have updated the batch file to include this step, it should still be fine for those who are not having the issue as well.
I have attached a zip file containing the su and a bat file for a more automated process (just pauses when during reboots, don’t hit go until it’s done rebooting). Or, you can run the commands manually and get the su file from the origin http://downloads.androidsu.com/superuser/su-bin-3.0.3.2-efghi-signed.zip
Finally, install Superuser to make it all work https://market.android.com/details?id=com.noshufou.android.su
**UPDATE** UNROOT
There are multiple was to unroot now that you have root access already (all you need to do is remove the su file; so you could potential skip all the steps before the remount and just add the local.prop manually using a file manager and then reboot).
The one most similar way to how you rooted would be to follow all of the steps above, but replace these 3 lines
adb push su /system/xbin/su
adb shell chown 0.0 /system/xbin/su
adb shell chmod 06755 /system/xbin/su
with this line
adb shell rm /system/xbin/su
This will remove the actual root, but it would leave behind any apps that you have given root access to or any files that those apps changed themselves (i.e. RootKeeper backs up the su file and the backup would need to be removed). If you had anything like this you would need to clean up that first before unrooting because it is a dead giveaway that it was rooted.
Viperboy should be releasing his tool shortly that utilizes this method, if you would like a one click process that installs apps along with it (superuser, busybox). I’m guessing it installed them to the root apps directory so these also would need to be removed when unrooting as well (i.e. if you root using his new tool you should unroot using it as well).
**UPDATED** Remove PayPal link in favor of link over there <-
Yes, as it says, I went from the same base exploit that was shown by Dan and was the base for jchase as well.
The commands more than likely are but the exploit must be different or Jcases rot would still be working... Thanks OP!!!
EDIT: He didn't "ask" for donations just gave a link since he doesn't have the donate button <<over there
Not mine at all, props to this guy! Send him some bones.
Yes, thanks, I did not realize that there was a donate button as I am still learning this forum.
This root is confirmed!
If your device "bootloops" don't stress, just follow through with the commands as it "loops" ro.kernel.qemu can do funky stuff.
Good ****.
sparkym3 said:
Yes, thanks, I did not realize that there was a donate button as I am still learning this forum.
Click to expand...
Click to collapse
Yeah it's in the User Control Panel on the top of the forum
"Reported" your thread to a mod, so he can move it to the dev section
And welcome to XDA Don't let the trolls take your love for android
jcase said:
This root is confirmed!
If your device "bootloops" don't stress, just follow through with the commands as it "loops" ro.kernel.qemu can do funky stuff.
Good ****.
Click to expand...
Click to collapse
OP, maybe put that in the OP, so users don't panic
Moved to development.
Holly smoke, it works....
jcase said:
Not mine at all, props to this guy! Send him some bones.
Click to expand...
Click to collapse
As the main man says. Give credit when due. It's not his. and give the guy props and if you wish to donate donate.
This is why this android community is crap. because everyone trolls. If it was jcases he'd release it. not someone else. and im sure as hell he wouldnt be saying these things 'like give the guy some bones'
rhcp0112345 said:
As the main man says. Give credit when due. It's not his. and give the guy props and if you wish to donate donate.
This is why this android community is crap. because everyone trolls. If it was jcases he'd release it. not someone else. and im sure as hell he wouldnt be saying these things 'like give the guy some bones'
Click to expand...
Click to collapse
Biggem isnt really a troll, he's obv just got out of the wrong side of the bed ... i'm sure he'll take that back.
Danny-B- said:
Biggem isnt really a troll, he's obv just got out of the wrong side of the bed ... i'm sure he'll take that back.
Click to expand...
Click to collapse
Also nothing wrong with asking for donations.
YOU ROCK. donations to you and jcase after payday
You would all post this WHILE I'm at work, have my prime with me, but not my charger! lol. I'll DEFINITELY check it out when I get home.
disturb3d1 said:
You would all post this WHILE I'm at work, have my prime with me, but not my charger! lol. I'll DEFINITELY check it out when I get home.
Click to expand...
Click to collapse
Dude mine should be here in 9 hrs
I might do an unboxing vid using my photon
Wait a minute, chainfire is paying attention to the thread, that only means good things. Please tell me your gonna dev some for this device
Sent from my SGH-T959 using XDA App
not going good for me I'm on ubuntu with working adb. copied su to home directory and running all commands from there. when i get to, adb shell "echo \"ro.kernel.qemu=1\" > /data/local.prop", i get, /system/bin/sh: cannot create /data/local.prop: Permission denied. So i never get the right id to continue. Anyways please help. thankx
Any chance in the future this can be converted to an apk to install on Prime or a One-click method, per se?
Hey all,
I'm hoping I'm in the right area to post this question. If I am not, if you could direct me to where I should post it I would appreciate it.
Anyway, here is my question: How does one go about changing the shell that su uses? I am using Android Terminal Emulator and while I have changed the default shell command line to ash, I am unable to figure out how to change the shell used when going into superuser mode. The default terminal is missing my most used feature (command recall) and I'd like to get it back.
If you could help me out, I would greatly appreciate it.
No one? Really?
gumbyx84 said:
No one? Really?
Click to expand...
Click to collapse
Well, if you were to use "/system/xbin/su -c /system/xbin/bash" in Cyanogenmod then it would give you bash shell as root. So, if you change the path to bash to ash on your ROM then you can have ash shell as root.
You can use ADB on unrooted devices to remove the "What's New" option from the NavRing and to remove the Small Apps Widget launcher from Recent Apps.
I will assume you know how to install and use ADB.
To remove the "What's New" option from the NavRing:
Code:
adb shell
pm block com.sonymobile.advancedwidget.entrance
exit
adb reboot
Make sure to reboot before proceeding if you're removing both items.
To remove the Small Apps Widget Launcher from the Recents screen:
Code:
adb shell
pm block com.sony.smallapp.launcher
pm block com.sony.smallapp.app.widget
exit
adb reboot
To revert changes substitute "unblock" for "block" in the command.
Good to note that these work just have to be run seperatley, i tried to block all 3 at the same time and it did not work you have to remove the whats new then reboot then remove the small apps then reboot again
Thanks for this OP i hate that whats new thing
aford89 said:
Good to note that these work just have to be run seperatley, i tried to block all 3 at the same time and it did not work you have to remove the whats new then reboot then remove the small apps then reboot again
Thanks for this OP i hate that whats new thing
Click to expand...
Click to collapse
Thanks, added to OP.
Thank you!
The what's new was really bugging me :-/
do you know if the block command does the same as "deactivate" would do from the Settings->Apps menu? (if it were enabled)
punshkin said:
Thank you!
The what's new was really bugging me :-/
do you know if the block command does the same as "deactivate" would do from the Settings->Apps menu? (if it were enabled)
Click to expand...
Click to collapse
I assume so, the "pm" is for the package manager commands.
I can not thank you enough! I still don't know what Sony was thinking with "What's New".
Favorite'd, I just know I'll be needing this soon enough xD
Working like a charm. Glad to have my recents cleaned up. Any other bloatware we can disable this way? Love to get rid of the walkman, sony app updates, movie, movie creator, etc
Im just trying to do this but when I type adb shell reboot it says device not found. It does say im in [email protected] though. Anyone know whats wrong?
Mr Sliff said:
Im just trying to do this but when I type adb shell reboot it says device not found. It does say im in [email protected] though. Anyone know whats wrong?
Click to expand...
Click to collapse
do adb devices, should be able to see your device listed. if it reads not autorized: unlock your lockscreen and confirm the dialog to give computer access.
cyphomatic said:
do adb devices, should be able to see your device listed. if it reads not autorized: unlock your lockscreen and confirm the dialog to give computer access.
Click to expand...
Click to collapse
Thats the weird thing, my device is listed when I do that.
ADB, SDK, JDK, JRE, USB debug, USB drivers: all set up correctly?
Thanks! worked perfectly for me, at least it did when I installed the Android SDK on my Windows partition instead of my Mac ... Really didn't want to work on the Mac side, nor is there a native way to transfer wirelessly from my Mac but everything works well on the Windows end.
Thanks again OP :good:
Can this method be used to disable the other system apps?
Mr Sliff said:
Im just trying to do this but when I type adb shell reboot it says device not found. It does say im in [email protected] though. Anyone know whats wrong?
Click to expand...
Click to collapse
Got the same thing before I found out you need to exit remote shell before you run reboot command (I'm new to using adb for anything other than push/pull)
So after:
pm block com.sonymobile.advancedwidget.entrance
exit
adb reboot
phroenix said:
Got the same thing before I found out you need to exit remote shell before you run reboot command (I'm new to using adb for anything other than push/pull)
So after:
pm block com.sonymobile.advancedwidget.entrance
exit
adb reboot
Click to expand...
Click to collapse
Yea, you need to exit shell before running any adb command, I'll add that to the OP.
Alright for some reason it doesent remove whats new for me. Ive rebooted a few times and it doesnt work. Removing the small apps did work though.
Mr Sliff said:
Alright for some reason it doesent remove whats new for me. Ive rebooted a few times and it doesnt work. Removing the small apps did work though.
Click to expand...
Click to collapse
im getting the same thing. says the blocked state is true, then i reboot, still there
ikon8 said:
You can use ADB on unrooted devices to remove the "What's New" option from the NavRing and to remove the Small Apps Widget launcher from Recent Apps.
I will assume you know how to install and use ADB.
To remove the "What's New" option from the NavRing:
Code:
adb shell
pm block com.sonymobile.advancedwidget.entrance
exit
adb reboot
Make sure to reboot before proceeding if you're removing both items.
To remove the Small Apps Widget Launcher from the Recents screen:
Code:
adb shell
pm block com.sony.smallapp.launcher
pm block com.sony.smallapp.app.widget
exit
adb reboot
To revert changes substitute "unblock" for "block" in the command.
Click to expand...
Click to collapse
This whole thread is actually a repetition of what has already been discussed and suggested over here:
http://forum.xda-developers.com/z3-compact/help/deactivated-apps-getting-activated-t2889082
Can you use adb to get rid of the nav bar too?
oh Thankgod ! whats new and the quick launch widget are gone !!!!
Thankyou Thankyou Thankyou
ps; is there a list of commands to get rid of certain other apps, widgets, bloat etc ?