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.
I'm freshly unlocked and perm rooted; I've already used Titanium Backup, Root Explorer, etc.... my Su is working.
I looked at the CleanTool thread in the Dev forum to see how to remove bloat, and executed the same commands from adb shell .... here's a small pasted section :
$ pm disable com.gameloft.android.Verizon.GloftLGolf2.lgolf2
pm disable com.gameloft.android.Verizon.GloftLGolf2.lgolf2
[1] Killed pm disable com.gameloft.android.Verizon.Glof
2.lgolf2
$ pm disable com.blockbuster.app.htc
pm disable com.blockbuster.app.htc
[1] Killed pm disable com.blockbuster.app.htc
Following a reboot, these bloat apps are still here and functioning. Anyone know what I'm doing wrong, or a more effective way to selectively remove what I consider bloat?
$ means you are not in SU
you need to type SU in ADB
The $ will change to #
Then try again (making sure if your phone asks you to allow ADB SU privs, you check allow; if that happens)
jdmba said:
$ means you are not in SU
you need to type SU in ADB
The $ will change to #
Then try again (making sure if your phone asks you to allow ADB SU privs, you check allow; if that happens)
Click to expand...
Click to collapse
This works, of course. This seems like such a duhhhhhh question, now that I know the answer.
Thanks so much
DIncLover said:
This works, of course. This seems like such a duhhhhhh question, now that I know the answer.
Thanks so much
Click to expand...
Click to collapse
Glad you were able to be helped.
Sorry for resurrecting this thread, but I was really surprised why "pm disable-user" does not work as user but also seems to require root-permissions? Makes no sense to me...
Finally i found a method to record call on realme gt 2 pro global gdpr version, who is persistent at boot. No root, no bootloader unlock.
Step one : install setedit from play store and add op_voice_recording_supported_by_mcc with 1 value to global settings. You have to give Setedit write secure rights with adb
Step two : install phone apk below.
That's it. Start Google dialer and make a call. Still works after reboot.
Not working : automatic call recorder, you have to press record button when you're in call.
Notice: if you don't see record button in Google dialer , is normal, just press back button to see realme dialer.
This should work on all color os 3 device.
Recorded call are in internal memory / music/ recordings/ call recordings folder.
ENJOY !!
No working... No see
Which apk needs to be installed for step two?
NVM I figured it out
Not working, it has changed the dialer but instead of recording button I have a "contacts" button and when I press it nothing happens.
Please uninstall phone from installed apps and install again.
criszz said:
Please uninstall phone from installed apps and install again.
Click to expand...
Click to collapse
Same, tried also to reboot but nothing
No permission to add a new line in Global Table
RazvanelTM said:
No permission to add a new line in Global Table
Click to expand...
Click to collapse
Same here, I've added the option in the system table maybe that's why it is not working
Yes, you must provide write secure rights for setedit with adb to edit in global.
Updated first post with that.
criszz said:
Yes, you must provide write secure rights for setedit with adb to edit in global.
Updated first post with that.
Click to expand...
Click to collapse
How can do? Have any tutorials?
manu81cba said:
How can do? Have any tutorials?
Click to expand...
Click to collapse
By default, for your protection, Android prevents you from modifying the SECURE and GLOBAL tables. If you have Android Jellybean or later, you can remove this protection from an ADB shell using the command "pm grant by4a.setedit22 android.permission.WRITE_SECURE_SETTINGS". On earlier versions, you can only remove this protection on a rooted device by installing SetEdit to the system partition.
All working flawless now I can confirm that
Not working when giving the permission in adb
RazvanelTM said:
Not working when giving the permission in adb
Click to expand...
Click to collapse
Try to activate first in the developers options this one: "Disable permission monitoring"
shootemdown371 said:
Try to activate first in the developers options this one: "Disable permission monitoring"
Click to expand...
Click to collapse
It worked, thanks!
Now it's confirmed to work and we must think how to enable automatically record for all calls. People who said not working without knowing, please edit your post.
In setedit ...you know what need change for active the volte ?
Thank you very much it's working for me!
PS for those unfamiliar with SetEdit can also use this in adb after disabling permission monitoring:
adb shell settings put global op_voice_recording_supported_by_mcc 1
Just must be applied after every restart ( that is what i read )
Nice post, thanks for sharing. Any solution for Xiaomi Redmi Note 10S, Global ROM MI?
Also working on the regular gt2