Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added support for custom environment #2

Closed
wants to merge 5 commits into from
Closed

added support for custom environment #2

wants to merge 5 commits into from

Conversation

ramdroid
Copy link

I added a function which allows you to add environment variables.

@ramdroid
Copy link
Author

I made the changes as proposed in your first post.

@Chainfire
Copy link
Owner

I didn't add it exactly as you suggested (even with your fix you were adding state information to a static class) but I did add support for environment passing to Shell.run, and for the new Shell.Interactive class, the Shell.Builder class also supports adding environment options. I hope that at least satisfies your needs.

@ramdroid
Copy link
Author

ramdroid commented Mar 4, 2013

(please ignore the commits I just made, I forgot to create a branch before doing the pull request)

The new Shell.Interactive class looks really promising! Great! Unfortunately the environment isn't set properly. You forgot to first create a copy of the current environment:

Map<String, String> newEnv = new HashMap<String, String>(System.getenv());
for (Map.Entry<String, String> entry : environment.entrySet()) {
    newEnv.put(entry.getKey(), entry.getValue());
}

@Chainfire
Copy link
Owner

Oops! I made an adjustment. Sorry I did not have time to extensively test it, let me know if it works.

@ramdroid
Copy link
Author

ramdroid commented Mar 5, 2013

Tested both variants, works fine here! ;)

@ramdroid ramdroid closed this Mar 5, 2013
cernekee added a commit to cernekee/libsuperuser that referenced this pull request Dec 8, 2013
libsuperuser is currently able to handle failures in several different
stages:

1) If the shell cannot be started at all (e.g. missing "su" binary),
Runtime.exec() should throw an exception, causing our open() method to
return failure.

2) If the shell dies while a command is executing, and the watchdog timer
is enabled, the onCommandResult() callback will get invoked so that the
caller can handle the error.

3) If the device operator denies a Superuser request, this typically
falls under case Chainfire#2 as the "su" executable will stay alive for a couple
of seconds until the operator clicks "deny."

But if the shell dies when there is no active command, any queued commands
will get stuck in limbo and the caller will never receive a status
indication.  This will probably cause the app to freeze until the
operator kills it, resulting in a subpar user experience.

The easiest way to reproduce the problem is to try running
libsuperuser_example in interactive mode on the SDK emulator (which has
a trivial "su" implementation that instantly denies root access to all
apps).  It will hang at "Requesting root privilege" forever.

So, we'll add an extra loop to send the bad news to the calling app if
libsuperuser isn't able to execute the requested commands.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants