Yes, I know that but like chainfire said, switching context should workaround that problem.
F/libc (17322): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb4da21f0 in tid 17366 (Binder_1)
E/DEBUG ( 186): unexpected waitpid response: n=17366, status=00000000
E/ ( 186): ptrace detach from 17366 failed: No such process
E/ ( 186): debuggerd committing suicide to free the zombie!Process proc = exec(new String[]{"su","--context","u:r:system_server:s0"});
DataOutputStream os = new DataOutputStream(proc.getOutputStream());
os.writeBytes("stop adbd\n");
os.flush();
os.close();
proc.waitFor();Thanks for the response. I will look into switching context. To get around selinux I had also been calling setenforce 0 and setenforce 1 right before and right after those commands. This is probably terrible practice?
Shell.run("su --context u:r:system_app:s0", new String[] {
"settings put secure location_mode " + (enabled ? originalLocationMode : newSetting),
"settings put secure location_providers_allowed " + (enabled ? originalLocationProviders : newLocationProviders)
}, null, true);
new BackgroundThread(command).execute();
class BackgroundThread extends AsyncTask<String, Void, Void> {
private String s;
public BackgroundThread(String command) {
s = command;
}
@Override
protected Void doInBackground(String... command) {
Process process = null;
DataOutputStream os = null;
try {
process = Runtime.getRuntime().exec("su");
os = new DataOutputStream(process.getOutputStream());
os.writeBytes(s+"\n");
os.writeBytes("exit\n");
os.flush();
process.waitFor();
} catch (Exception e) {
}
finally {
try {
if (os != null)
os.close();
else
process.destroy();
} catch (Exception e) {
}
}
return null;
}
}public void run(String command) {
new BackgroundThread(command).doInBackground();
}No it isn't acceptable, but the reason is not what you might think.
Using a generic AsyncTask derived class to run su calls can be a solution. As long as your code ends up running in the background, all is good. However, in my experience what usually happens is that you have to do a lot of things in the background.
For example, imagine that during your app's startup, you need to check some files, perform some su calls, check some more files, do some computations, etc. Those should all go in a single AsyncTask's doInBackground method. That way you can use onPreExecute and onPostExecute to show and dismiss a dialog that tells the user you are busy.
Furthermore, if you had 10 su commands to run, would you just call new BackgroundThread ... 10 times? As the call should return before the su command is finished executing, the order of the executions of those commands becomes semi-random, you can't depend on them being run in any specific order, it even differs between Android versions (some versions run AsyncTasks serially, others run X of them in parallel). Not to mention that you shouldn't create 10 separate su processes to run 10 commands unless you have a good reason. Batching commands together == much higher performance.
The above does depend on which commands you need to execute, the needs of your application, and how you use it. If you only have to execute a single su command, it can be done that way, but I think in general this is not an ideal solution.
Now, the reason why your solution is truly unacceptable is because you are calling doInBackground. This does not make the code run in the background. You override doInBackground and insert your code, but you call the execute method. You should call your code like this:
Code:new BackgroundThread(command).execute();
Else you're still calling on the main thread !
If you really want to keep using this method, keep in mind that you can actually pass parameters to the execute() function that in turn will be passed to doInBackground. Look in the AsyncTask documentation ...
