There will be a new version released soon, possibly today. Lots of bugs fixed.
High CPU load issue and zombie processes causing it should be gone now. Not sure about the preferences remembering, what can help solve that. I have not been able to replicate this behavior as of yet.
I found the problem and fixed it. It had to do with how you send the command: you write the command to STDIN, then flush and close STDIN. Though obviously possible this is not exactly "expected" behavior. I'm surprised that actually works on normal sh/su - I would have half expected the command to simply be dropped. Had you either padded the command with \n and closed STDIN, or padded with \nexit\n (as would be normal for the way you run scan) and no closed STDIN, there would not have been a problem. Interesting edge-case though. This will work in the next update.
No idea. You can try
That is one bad app... I have adjusted SU to use much less CPU during full logging and nothing is going on, but this app just fires off SU process, and never closes them. If you start this app 20 times, you have 20 SU processes running around eating your resources
Unfortunately, after intensively testing different apps with root permissions, at some point, there were 3 (!) su processes occupying whole CPU.
Hope it can be fixed in the future, because I can possibly relate to some apps' preferences in SuperSU which are still not remembered (please see a previous attachment:
http://xdaforums.com/attachment.php?attachmentid=946519&d=1331719645 )
Thanks.
High CPU load issue and zombie processes causing it should be gone now. Not sure about the preferences remembering, what can help solve that. I have not been able to replicate this behavior as of yet.
I'm the author of DiskUsage. I've got an alert of the diskusage referenced here.
DiskUsage just runs "su", types 'scan' (included scanner binary), closes input stream and reads output from the binary, skipping first characters until '\0' byte, which indicates the end of potential garbage before 'scan' output.
http://code.google.com/p/diskusage/...ogle/android/diskusage/NativeScanner.java#149
If the output doesn't match the expected format, the error can be seen. I'm a bit suspicious about logging you mentioned. If it goes in the same stream, it can be a problem.
I found the problem and fixed it. It had to do with how you send the command: you write the command to STDIN, then flush and close STDIN. Though obviously possible this is not exactly "expected" behavior. I'm surprised that actually works on normal sh/su - I would have half expected the command to simply be dropped. Had you either padded the command with \n and closed STDIN, or padded with \nexit\n (as would be normal for the way you run scan) and no closed STDIN, there would not have been a problem. Interesting edge-case though. This will work in the next update.
Dude, does this app remove root access (temporarily)?
My friend has got an app that accesses secure mailserver, and it will not work on rooted phones. Do you think SuperSU would work?
The app is this:
https://play.google.com/store/apps/...=W251bGwsMSwxLDEsImRrLmV4Y2l0b3IuZG1lbWFpbCJd
No idea. You can try
Ok, I was messing around with SD Speed Increase app ( which increases buffered read cache - wanted to test the SD card, to check if there are issues with it with your latest LPQ kernel , offtopic, is maybe the SD with WIFI restart problem solved with ICS / LPQ / your kernel fixes ? ).
I discovered that from the moment I start the app, su binary goes nuts.
Please see the screenshot and the ps output.
In this case, the SuperSU had Full Logging configured for all apps.
In case that I disable full logging and leave it to no logging, it seems that all goes well (hopefully).
Thank you.
That is one bad app... I have adjusted SU to use much less CPU during full logging and nothing is going on, but this app just fires off SU process, and never closes them. If you start this app 20 times, you have 20 SU processes running around eating your resources