Superuser fails and doesn't prompt (with solution)

[kmdm]

Installed Superuser 3.0.7 with su 3.0.3.2 on an ICS device and got the following error in logcat:-

""" W/ActivityManager( 422): Permission Denial: broadcastIntent() requesting a sticky broadcast from pid=9080, uid=10171 requires android.permission.BROADCAST_STICKY """

Used apktool to rebuild Superuser.apk with that permission added to AndroidManifest.xml, test-signed and pushed to the device.

Now works fine. :-)

(Clarity: This occurred whether Superuser.apk was pushed to /system/app or /data/app)

[ChainsDD]

Can you get me the rest of the stacktrace for this error? I'm not sure where Superuser is attempting to use a sticky broadcast...

[kmdm]

I'll dig around a bit later in logcat and try to find more relevant extracts from logcat. :-)

(Tbh I was kinda assuming it was the intent from the su-binary since as best as I understand it it's running with the uid of the Superuser.apk at that point...[but I could very well be wrong about that :P])

[git-core]

Well, current su-binary from master may send sticky broadcast by chance. It puts garbage at the very end of the parcel sent to Superuser. The problem is that should happen on all Android versions, not only ICS.

Could you try su-binary from gc or gc-ics branch? With original manifest content, of course.

[kmdm]

Compiled gc-ics branch using mm under external/ - result:-

""" E/su (22599): sudb - Opening database E/su (22599): Couldn't open database: unable to open database file E/su (22599): sudb - Could not open database, prompt user W/Parcel ( 407): Attempt to read object from Parcel 0x59a0ec7c at offset 644 that is not in the object list E/Bundle ( 407): readBundle: bad magic number E/Bundle ( 407): readBundle: trace = java.lang.RuntimeException E/Bundle ( 407): at android.os.Bundle.readFromParcelInner(Bundle.java:1643) E/Bundle ( 407): at android.os.Bundle.(Bundle.java:83) E/Bundle ( 407): at android.os.Parcel.readBundle(Parcel.java:1469) E/Bundle ( 407): at android.os.Parcel.readBundle(Parcel.java:1454) E/Bundle ( 407): at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:305) E/Bundle ( 407): at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1714) E/Bundle ( 407): at android.os.Binder.execTransact(Binder.java:338) E/Bundle ( 407): at dalvik.system.NativeStart.run(Native Method) W/ActivityManager( 407): Permission Denial: broadcastIntent() requesting a sticky broadcast from pid=22599, uid=10171 requires android.permission.BROADCAST_STICKY """

[kmdm]

(Worth noting: There is a similar traceback in 3.0.3.2)

[kmdm]

Same traceback when running with my hacked/fixed Superuser.apk but without the warning. Although in its place there is a rather conspicuous looking:-

""" I/Intent ( 407): @test_code: getHtcIntentFlag: 0 obj: 1096386184 """

[git-core]

The last traceback is irrelevant, I guess. It's an informational message (has I as log level). Why is su unable to open the permissions database? Do you have a fresh install? (Both questions aren't related to a buggy intent that I see. I'd like just to check that everything before the intent goes well.) What is the value of the property "ro.build.version.sdk" on your ICS?

[kmdm]

I'm guessing because I wipe the data for Superuser each time so permissions.sqlite has not been created yet. It seems to exist once I allow something (with the patched apk).

$ adb shell getprop ro.build.version.sdk 15

And yea, I noticed it was informational - just highlighting HTC have been messing with the framework ;)

[kmdm]

Okay - I've got this one solved (but I don't know how you'll fix it properly ;))

Looking at Intent->readFromParcel() on this ROM:-

iput-object v2, p0, Landroid/content/Intent;->mExtras:Landroid/os/Bundle;

.line 6533
invoke-virtual {p1}, Landroid/os/Parcel;->readInt()I

move-result v2

iput v2, p0, Landroid/content/Intent;->mHtcFlags:I

After the mExtras Bundle there is an extra Integer field for mHtcFlags, so adjusting the su-binary (as a test) to be:-

data.writeInt32(0); /* HtcFlags */
data.writeString16(NULL, 0); /* resolvedType */

...worked just fine.

So now I guess we need to establish how to determine if a ROM has that extra field in the Intent Parcel.

[git-core]

I may help you to do so. Could you share your ROM properties (output from getprop). Please, send it to me privately and remove all sensible information from the output. My guess is the phone model doesn't count due to AOSP based ROMs like CM9 may exist there, so we need some signature suitable for HTC ROMs only. By the way, is this official HTC ICS ROM?

[kmdm]

Yep, 100% official/stock HTC ICS ROM. - E-mail sent with filtered getprop output.

[leif1981]

I've also issues with superuser. It worked fine for me for a long time, but today I tried to use a new app which requires root and I couldn't get it to work. After trying also other apps it looks like superuser itself has an issue.

My results from testing so far.

• happened on Galaxy Nexus (4.04) as well as Asus Transformer Prime with Android ICS 4.03
• when I switch system language to english it works, but on german it's broken
• i never get the request to give or deny the rights
• even when I change the su settings to always allow it those apps as well as SU log report they got denied

Not sure which causes it since if I remember right there was a superuser update in the last weeks(?) and both of my devices got updated in the last weeks as well.

[kmdm]

On the assumption my e-mail didn't land with you:-

ro.product.model: HTC One S ro.build.fingerprint: htc_europe/ville/ville:4.0.3/IML74K/47230.2:user/release-keys

I was toying with the idea of caching the fingerprint against a check of framework.odex for the "HtcIntentFlag" string so on first invocation it'd check framework.odex and each subsequent invocation it just needs to check the flag stored against the fingerprint.

Updating the ROM would change the fingerprint and thus require a re-check of framework.odex.

(But that still feels a bit messy.)

Although I'm personally holding off cause a) my hacked up su-binary works and b) I haven't found a single other person with this issue :-/ (which I would have expected by now!)

[git-core]

On the assumption my e-mail didn't land with you

In fact, it didn't.

I was toying with the idea of caching the fingerprint ...

I'm afraid, it's too much work for little su. Anyway, I'm going to choose very simple solution: check ro.product.device. It shall contain "ville" according to your fingerprint. Perhaps later, we have to check for HTC 4.0.3 or higher. My assumption is HTC will continue to put its crap in the intent body for every ROM it ships.

I haven't found a single other person with this issue

Experienced enough to dig in and find out there is a crap inside intent??? I doubt... There should be some reports on unusual behavior of su or root apps, definitely.

[kmdm]

Yep - I can't disagree that it's too much work / too messy.

However, I would very much prefer that any solution does not by default break AOSP implementations. So could we check (and I'm ignorant of how AOSP sets these variables) ro.product.device and for example ro.product.version ?

(I'm obviously giving a very liberal meaning to "we" in the above...)

I've been looking on the XDA One S forums - I'd just expect more threads about su/SuperUser not working... or maybe a relatively low number of enthusiasts/rooters have purchased one.

I'll try to find time to check the T-Mobile One S HTC ROM to see if this extra field is present there too (partly clutching at straws).

[git-core]

could we check ... ro.product.version?

For existence? For concrete numbers? Sorry, I can't divine what numbers HTC has put into product.version for One S. Anyway, could you post output of getprop | grep -i htc There shall be some properties that are specific for HTC, I guess. Perhaps, something like ro.htc.common.version, ro.com.google.clientidbase, or even ro.error.receiver.htc.apps as a last resort.

(I'm obviously giving a very liberal meaning to "we" ...)

(I meant just "an abstract group of su developers")

[kmdm]

Yes, quite right. Sorry, I was just asking about the concept of checking ro.product.version which I guess is easier to evaluate if you have the version number of the device in front of you curses self for assumptions - anyway, just for reference it was 1.53.401.2. :-)

Anyway, there should be a good choice from:-

$ adb shell getprop | grep -i htc dev.defaultwallpaper: /system/customize/resource/scene_wallpaper_htc_default.jpg dev.deviceimage_large: /system/customize/resource/ville-htc_187x370.png dev.deviceimage_small: /system/customize/resource/ville-htc_32x58.png htc.audio.alc.enable: 1 htc.audio.global.profile: 0 htc.audio.global.state: 0 htc.audio.lpa.a2dp: 0 htc.audio.q6.topology: 0 htc.audio.swalt.enable: 1 htc.audio.swalt.mingain: 14512 htc.htcmode.state: offline init.svc.htc_ebdlogd_rel: running init.svc.htcfs: running persist.htc.audio.pcm.channels: 2 ro.aa.maincid: HTC001 ro.build.fingerprint: htc_europe/ville/ville:4.0.3/IML74K/47230.2:user/release-keys ro.carrier: HTC-WWE ro.cid: HTC001 ro.com.google.clientidbase: android-htc-rev ro.config.htc.enableCOTA: 1 ro.config.htc.noappupdate: 0 ro.config.htc.nocheckin: 0 ro.cwkey: HTC001 ro.htc.checkin.delay: 3 ro.htc.htcmode.data.path: /dev/ttyHSUSB3 ro.phone.min_match.HTC016: 7 ro.phone.min_match.HTC__J15: 7 ro.phone.min_match.HTC__Y13: 7 ro.product.brand: htc_europe ro.product.manufacturer: HTC ro.product.model: HTC One S ro.ril.ecc.HTC-Dutch: 112 ro.ril.ecc.HTC-EastEurope: 112 ro.ril.ecc.HTC-FRA: 112,911 ro.ril.ecc.HTC-GCC: 999,112,997 ro.ril.ecc.HTC-ITA: 112,911 ro.ril.ecc.HTC-SPA: 112,911 ro.ril.ecc.HTC-WWE: 999 ro.ril.enable.a52.HTC-ITA: 1 ro.ril.enable.a53.HTC-ITA: 1

[git-core]

Thank you for the output. I choose ro.com.google.clientidbase. While it looks like a random choice, the rationale is

1. it's definitely HTC, 2. AOSP-based ROMs seem to set android-google.

I've pushed the fix in the gc-ics branch. Could you try, please?

[kmdm]

Works for me.

(I'm still uneasy about the lack of general complaining about "root does not work!!!!!!!" on the XDA forums though!)

[git-core]

Could you, please, also check whether the commit 5688e8996072e29d554ac5834d3586aa8633c5a6 is required for your ROM? The simplest way is to revert this commit, become root from a non-privileged account, and invoke pm or am command. They shall print their help texts if the fix isn't required and get SIGSEGV (segmentation fault) otherwise.

I'm still uneasy about the lack of general complaining about "root does not work!!!!!!!"

If you will be able to pull off logcat from the posters, I may help. You may use my gmail account I've sent a private message to kmdm2... from. Unfortunately, it's practically impossible to understand why su fails without logs.

[m-ric]

XDA forum > root does not work!!!!!!! :-)

I am having the same issue on AOSP-4.0.4 on pandaboard. I need su for droid-VNC-server by onaips. I read you guys' thread, and I think I may be of some help to see what prop is making su do things wrong.

I guess first thing for me is to try the gc-ics branch for superuser... I have just cloned Superuser, and I can't see gc-ics branch. What did I miss?

[EDIT] my bad, I thought su-binary was embedded in Superuser.apk...

[m-ric]

Just tried commit 5688e89 on my pandaboard running AOSP-4.0.4 (API 15). I pushed su in /system/xbin. Superuser.apk recognized it as version 3.1. Then starting VNCserver leads me to:

/ # logcat VNCserver:V su:V *:S
V/VNCserver( 4480): Running as root...
V/VNCserver( 4480): Starting /data/data/org.onaips.vnc/files/androidvncserver  -r 0 -s 100 -P 5901 
E/su      ( 4715): chown (/dev/com.noshufou.android.su, 10035, 10035) failed with 2: No such file or directory
W/su      ( 4715): request rejected (10036->0 /system/bin/sh)
V/VNCserver( 4480): Could not start server :(

# find / -name com.noshufou.android.su
/data/data/com.noshufou.android.su

[EDIT] Same issue pushing su in /system/bin...

[m-ric]

I think I have a mismatch with socket handling between my su binary and Superuser.apk. I tried Superuser-3.0.7-efghi-signed.zip provided on http://androidsu.com/superuser/ but that does not work. Checking the git tree, I see two or three commits in dev branch above 3.0.7 dealing with sockets. Then I probably need to rebuild Superuser.apk in eclipse. Any suggestion to do that, I am not a (experienced) java developer...

I just tried to hack su.c to make it not deny access if chown (/dev/com.noshufou.android.su, 10035, 10035) fails. But I now have setgroups failing...

V/VNCserver(  622): Running as root...
V/VNCserver(  622): Starting /data/data/org.onaips.vnc/files/androidvncserver  -r 0 -s 100 -P 5901 
E/su      (  721): chown (/dev/com.noshufou.android.su, 10035, 10035) failed with 1: Operation not permitted
E/su      (  721): setgroups failed with 1: Operation not permitted
W/su      (  721): request rejected (10036->0 /system/bin/sh)
V/VNCserver(  622): Could not start server :(

All this makes me believe that my pandaboard may not be rooted properly. In my android build system, I made /system to be mounted in RW, start init shell as user root and group root, and grant root privilege to adb. Is that enough? What am I missing?

[git-core]

E/su ( 4715): chown (/dev/com.noshufou.android.su, 10035, 10035) failed with 2: No such file or directory E/su ( 721): setgroups failed with 1: Operation not permitted which looks like you don't set suid bit on the su binary. And no, there is no socket mismatch problems. Well, at least, I didn't plan to add them intentionally. Any relatively modern Superuser should work w/ su from gc/gc-ics branches. Even Superuser 2.x might work somehow, but I'm not sure.

[m-ric]

/system/bin # md5sum  /system/xbin/su /system/bin/su
084c9e3841fb271d44c4e0a708026f05  /system/xbin/su
084c9e3841fb271d44c4e0a708026f05  /system/bin/su
/system/bin # ls -l /system/xbin/su /system/bin/su
-rwxrwxrwx    1 0        0            18496 May 10 20:54 /system/bin/su
-rwxrwxrwx    1 0        0            18496 May 10 20:54 /system/xbin/su

What else should it be? Ok for the socket, thanks.

[EDIT] I installed the busybox manually. It oversedes most of android toolbox command, eg chown... my busybox lies in /system/bin and is as follows:

/system/bin # ls -l /system/bin/busybox /system/bin/chown 
-rwxr-xr-x    1 0        0          1999200 Jan  2  1970 /system/bin/busybox
lrwxrwxrwx    1 0        0                7 Jan  2  1970 /system/bin/chown -> busybox

[EDIT] ok I fixed this issue with :

/ # chmod gu+s /system/bin/su
/ # ls -l /system/bin/su

-rwsrwsrwx 1 0 0 18496 May 10 20:54 /system/bin/su

I didn't what ths 's' meant before today :). Thanks. Running the vncserver again leads me to:

V/VNCserver(  964): Running as root...
V/VNCserver(  964): Starting /data/data/org.onaips.vnc/files/androidvncserver  -r 0 -s 100 -P 5901 
E/su      ( 1024): sudb - Opening database
E/su      ( 1024): sudb - Database opened
E/su      ( 1024): sudb - Database closed
E/su      ( 1024): write(ARG_MAX) failed with 32: Broken pipe
W/su      ( 1024): request rejected (10036->0 /system/bin/sh)
V/VNCserver(  964): Could not start server :(

[git-core]

E/su ( 1024): write(ARG_MAX) failed with 32: Broken pipe and now it looks like you're using Superuser version from the repository. It's too experimental. Sorry, when I said "any relatively modern Superuser", I didn't mean so modern. Please, use an official version.

[m-ric]

ok. I use Superuser v3.7, it recognized your su v3.1. But I am not sure I install it the right way, I simply do:

$ mkdir Superuser-3.0.7-efghi-signed
$ unzip Superuser-3.0.7-efghi-signed.zip -d Superuser-3.0.7-efghi-signed
$ adb push system/app/Superuser.apk /system/app

I never copy META-INF/ files. Is it correct? Anyway, I'm getting further. Now my vncserver seems to execute dumb things:

V/VNCserver( 1711): Running as root...
V/VNCserver( 1711): Starting /data/data/org.onaips.vnc/files/androidvncserver  -r 0 -s 100 -P 5901 
E/su      ( 1765): sudb - Opening database
E/su      ( 1765): sudb - Database opened
E/su      ( 1765): sudb - Database closed
E/su      ( 1765): 10036 org.onaips.vnc executing 0 /system/bin/sh using shell /system/bin/sh : sh failed with 17: File exists
V/VNCserver( 1711): Could not start server :(

I'm gonna check what file it tries to access. Thanks.

[git-core]

"It" doesn't try to access a file. According to the log, su is invoked as su root failed with 17: File exists Obviously, "sh root failed with 17: File exists" is wrong command, it terminates w/ error status. I guess, you wanna ask the author of the server about this strange behavior.

[m-ric]

My bad, I changed LOGD into LOGE in my yesterday debugging session... su and Superuser are just fine now. And I workarounded vncserver to make it work with small tweaks. Thanks a lot git-core, you made my day :-)

[rhcp011235]

I must add a note here. Superuser is an app such as "sudo" which allows su to run as root. We all run/install it to get root. why not just add the missing permission and be done?

having an extra permission on the superuserapp i dont see being a big deal as we all install it to get root anyway. #justsayin

[kuzm2000]

And I workarounded vncserver to make it work with small tweaks. m-ric, could you please let us know what was a workaround ?

[m-ric]

droid-VNC-server last images targets gingerbread, not ICS. The androivncserver binary that is called by the java app has been compiled for GB, and it didn't work on my ICS AOSP. I made few things to generate a androidvncserver_ics. But this is not related to Superuser at all, I don't think it is any value in here.