FORUMS
Remove All Ads from XDA

[DEV GUIDE][2016.12.22] How-To SU

11,010 posts
Thanks Meter: 83,899
 
By Chainfire, Senior Moderator / Senior Recognized Developer - Where is my shirt? on 29th October 2012, 08:38 PM
Post Reply Email Thread
16th November 2014, 11:43 AM |#51  
Senior Member
Thanks Meter: 58
 
More
Quote:
Originally Posted by Chainfire

Whether or not a process terminates on closing their STDIN is completely unreliable (though many processes do) and a bad practise in general. Unfortunately, this is a common case among root apps.

Ah yes, this just work when I exit the shell. For some reason I so far never ran into this. Thank you.
 
 
16th November 2014, 03:39 PM |#52  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,356
 
More
Quote:
Originally Posted by Chainfire

They are executing in order, you're just not executing them in the right context, probably, so SELinux denies these commands. There's a whole section in my document about context switching, check that. You probably want the settings commands to execute as system_app.

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?

The su commands are definitely getting called successfully, but not reliably, until I separate them with delays. This is why I thought maybe the commands were running out of order, or concurrently.

Sent from my Nexus 5
16th November 2014, 04:30 PM |#53  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,899
 
Donate to Me
More
Quote:
Originally Posted by Flyview

This is probably terrible practice?

The very worst.
16th November 2014, 05:00 PM |#54  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,356
 
More
Quote:
Originally Posted by Chainfire

The very worst.

Understood. I've also seen something strange happen where after running my superuser code, once in a while, the whole system starts crashing. Apps just close, and eventually it gets very slow, logcat can't even keep up with the errors. Then after powering down and back up, apps are "updated" again (re-odexed?). I wonder, is it the same phenomenon that you mention on your site?

Quote:

All commands that launch Java-based code however must be run as one of the *_app contexts. If you don't, an ART error may be triggered that brings down the entire system. Note that this specific issue does not occur when using Dalvik."

21st November 2014, 10:04 PM |#55  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,356
 
More
Quote:
Originally Posted by Flyview

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?

The su commands are definitely getting called successfully, but not reliably, until I separate them with delays. This is why I thought maybe the commands were running out of order, or concurrently.

Sent from my Nexus 5

Quote:
Originally Posted by Flyview

Understood. I've also seen something strange happen where after running my superuser code, once in a while, the whole system starts crashing. Apps just close, and eventually it gets very slow, logcat can't even keep up with the errors. Then after powering down and back up, apps are "updated" again (re-odexed?). I wonder, is it the same phenomenon that you mention on your site?

I just wanted to update that everything has been working as planned after adding in a su command to switch context to system_app. Thanks Chainfire!
23rd November 2014, 05:59 PM |#56  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,356
 
More
Hi Chainfire,

Please help me with one other thing. I have noticed on Lollipop that after running root commands from my service, the service continues to grow in size at almost 1mB after every call. This was not happening on KitKat. The only thing that has changed is the addition of the context switching command. Am I doing something wrong?

Quote:


public static void setGpsEnabled(boolean enabled, int originalLocationMode) {
if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
int newSetting = originalLocationMode;
String originalLocationProviders = "network", newLocationProviders = "network";

if (originalLocationMode == Settings.Secure.LOCATION_MODE_HIGH_ACCURACY) { //High accuracy becomes Battery Saving
newSetting = Settings.Secure.LOCATION_MODE_BATTERY_SAVING;
originalLocationProviders = "network,gps";
newLocationProviders = "network";
} else if (originalLocationMode == Settings.Secure.LOCATION_MODE_SENSORS_ONLY) { //Device only becomes Off
newSetting = Settings.Secure.LOCATION_MODE_OFF;
originalLocationProviders = "gps";
newLocationProviders = "off";
}

rootCommand(new String[]{
"su --context u:r:system_app:s0",
"settings put secure location_mode " + (enabled ? originalLocationMode : newSetting),
"settings put secure location_providers_allowed " + (enabled ? originalLocationProviders : newLocationProviders)});

}
}

public static void rootCommand(final String[] commands) {
new Thread(new Runnable() {

@Override
public void run() {
Shell.SU.run(commands);
}
}).start();
}

I got this from Eclipse's Memory Analysis Tool (MAT):

Quote:

Problem Suspect 2
300 instances of "eu.chainfire.libsuperuser.StreamGobbler", loaded by "dalvik.system.PathClassLoader @ 0x32c83ce0" occupy 7,632,000 (22.00%) bytes.

Keywords
dalvik.system.PathClassLoader @ 0x32c83ce0
eu.chainfire.libsuperuser.StreamGobbler

24th November 2014, 06:41 AM |#57  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,356
 
More
I've tried to debug what's going on in the Shell.SU.run method. Please see the System.out.println lines I've added. Only the first 1 (TEST1) is reached! It looks to me like proc.waitFor takes forever and the "gobbling" keeps going. This line *is* reached, however, if I do not switch the context to system_app in my root commands that I send.
This is on Android Lollipop, SuperSU 2.27, and the latest libsuperuser.

EDIT: I think I fixed it by running my root commands without "su" before --context u:r:system_app:s0

rootCommand(new String[]{
"--context u:r:system_app:s0",
"settings put secure location_mode " + (enabled ? originalLocationMode : newSetting),
"settings put secure location_providers_allowed " + (enabled ? originalLocationProviders : newLocationProviders)});

}
24th November 2014, 09:15 AM |#58  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,899
 
Donate to Me
More
Quote:
Originally Posted by Flyview

I've tried to debug what's going on in the Shell.SU.run method. Please see the System.out.println lines I've added. Only the first 1 (TEST1) is reached! It looks to me like proc.waitFor takes forever and the "gobbling" keeps going. This line *is* reached, however, if I do not switch the context to system_app in my root commands that I send.
This is on Android Lollipop, SuperSU 2.27, and the latest libsuperuser.

EDIT: I think I fixed it by running my root commands without "su" before --context u:r:system_app:s0

rootCommand(new String[]{
"--context u:r:system_app:s0",
"settings put secure location_mode " + (enabled ? originalLocationMode : newSetting),
"settings put secure location_providers_allowed " + (enabled ? originalLocationProviders : newLocationProviders)});

}

Code:
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);
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
28th November 2014, 11:15 AM |#59  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,899
 
Donate to Me
More
Lots of 5.0 info added the document.
The Following 3 Users Say Thank You to Chainfire For This Useful Post: [ View ]
7th December 2014, 04:01 PM |#60  
Junior Member
Thanks Meter: 0
 
More
Question
I was wondering if the restriction of running binaries outside of the /system partition is lifted by SuperSU? Users report no problems and in my testing all seems well, but can I depend on this to work in the future?

Thanks a lot for your work Chainfire.
7th December 2014, 08:58 PM |#61  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,899
 
Donate to Me
More
Quote:
Originally Posted by Archipelt

I was wondering if the restriction of running binaries outside of the /system partition is lifted by SuperSU? Users report no problems and in my testing all seems well, but can I depend on this to work in the future?

Thanks a lot for your work Chainfire.

Yes it is. And I will do my very best to keep that so.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes