-
Notifications
You must be signed in to change notification settings - Fork 640
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
Conversation
I made the changes as proposed in your first post. |
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. |
(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:
|
Oops! I made an adjustment. Sorry I did not have time to extensively test it, let me know if it works. |
Tested both variants, works fine here! ;) |
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.
I added a function which allows you to add environment variables.