checking root using "su"

[GoogleCodeExporter]

You checking root throw using "su"(method InternalMethods.doExec() called from 
InternalMethods.returnPath()).

Call stack:
InternalMethods.doExec()
InternalMethods.returnPath()
RootTools.getPath()
RootTools.isRootAvailable()

I hope you'll find the way to get $path variable without root.

Original issue reported on code.google.com by vynd...@gmail.com on 15 Sep 2011 at 3:09

[GoogleCodeExporter]

I found what you need. Use System.getenv("PATH").

Original comment by vynd...@gmail.com on 21 Sep 2011 at 1:39

[GoogleCodeExporter]

This is an Android command?

Original comment by Stericso...@gmail.com on 21 Sep 2011 at 1:41

[GoogleCodeExporter]

This is standard android method getting enviroment variables. See 
developer.android.com for details:
http://developer.android.com/reference/java/lang/System.html#getenv(java.lang.St
ring)

Original comment by vynd...@gmail.com on 21 Sep 2011 at 2:13

[GoogleCodeExporter]

This should be fixed, now it checks via two different means and I think this 
resolves your issue.

Original comment by Stericso...@gmail.com on 7 Oct 2011 at 1:18

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The exceptions you are seeing are not cause by RootTools...in reality they are 
caused because the first method RootTools uses to find binaries is failing. 
However the second method kicks in and finds su.

01-04 09:26:16.989: D/RootTools v1.4.1(2336): su was found here: /system/bin/

however, to answer your question, I need to see the rest of the stack trace 
before the exception is thrown.

Original comment by StericDr...@gmail.com on 4 Jan 2012 at 6:14

[GoogleCodeExporter]

I guess that first statement doesnt make since...rather I meant to say that the 
exceptions are expected in some circumstances and roottools is ahdnling the 
exceptions properly...you shouldnt have to worry about them.

Original comment by StericDr...@gmail.com on 4 Jan 2012 at 6:35

[GoogleCodeExporter]

hi Sreisco, exception handling is not handled properly . please catch the 
FilenotFound exception in findBinary() as i cannot catch it from the calling 
function. this needs to be added in both places ,before if(!found) as well as 
keep the try catch for if(!found) 

But I wonder why dont you add the second set of paths  in the first try block 
and can delete if(!found) completely .. 

Original comment by Inau...@gmail.com on 11 Jan 2012 at 11:59

[GoogleCodeExporter]

You are not suppose to catch it, RootTools catches the exception.

Please see line 266-270 of RootTools.java (Stable)

The exception is being handled properly. If you do not want to see the 
stacktrace, then turn debug mode off.

Again, in your example, the method does find su as indicated by your log:

01-04 09:26:16.989: D/RootTools v1.4.1(2336): su was found here: /system/bin/

Original comment by Stericso...@gmail.com on 12 Jan 2012 at 12:12

[GoogleCodeExporter]

my bad !!! thanks Stersicso:) one last question how do i find Superuser.apk ? 
is it always gonna be in the same location device is rooted ?

Original comment by Inau...@gmail.com on 12 Jan 2012 at 1:13

[GoogleCodeExporter]

SuperUser.apk I would poll Packagemanager to see if it is installed or just 
scan the phone for the package name....

In reality though, your application doesn't need to worry about whether or not 
a user has or doesnt have superuser installed. If the su binary is installed 
then I think it is a safe assumption that root access is available to you, of 
course assuming permissions is given by the user.

Original comment by Stericso...@gmail.com on 12 Jan 2012 at 5:06

[GoogleCodeExporter]

As I told you before ,i am checking the rooted device programmatically not by 
waiting user's permission. So All I could do to determine is only to figure out 
if su binary is available or not. Is there any other checks I could include to 
determine rooted device in this way ? Your comments are highly appreciated ?

Original comment by Inau...@gmail.com on 12 Jan 2012 at 7:41

[GoogleCodeExporter]

So, is Su is one the device my thoughts are this:

Either, it's just a standard Su binary and does not need SuperUser

OR

It's SuperUsers Su binary and that indicates that SuperUser should be installed.

So the presence of Su is enough evidence of a rooted phone for me.

Although I do check for root access...I have a method for that.. 
isAccessGiven() which should return a boolean which is indicative of whether or 
not you can actually execute rooted applications. Although, if Superuser is 
installed it prompts for the users permission.

.

Original comment by StericDr...@gmail.com on 12 Jan 2012 at 8:29