yashsingh1/xdaforums huggingface dataset:
[SuperSU] occtec:
No initial must be by .zip subsequent updates can be updated through play store ;)

Sent from the wizard of OZ
[SuperSU] 3c:
No as replied already, but to give more details on this: the ZIP includes the SU binary (the actual thing that provides root), the setup script (install-recovery.sh to keep root on every reboot on Android 4.3, not needed (I think) on older Android versions) and the SU app (the thing that actual asks users if they authorize root to an app).

Once this is installed, you can update the APK as usual, through PlayStore, then update SU binary within the app.

Note however if you flash a new system image that does not have root, you'll need to flash the ZIP again.
[SuperSU] ThurstonX:
Interesting. I'm on 4.3, running vorcers' latest kernel (v6), the most recent kernel mods, and SuperSU 1.51 Pro, and I'm looking at my CIFS mounts as I type. I did flash SSU 1.45 after updating to 4.3, and then took the Play Store updates.
[SuperSU] glimmling:
I will try to flash v1.51 in Recovery later.

I started with flashing v1.43 directly after the upgrade to Android 4.3. The next SuperSU update didn't update the su binary in Android mode, so I selected the TWRP method. Then came the update to v1.51 and the popup stated, that the su binary was successfully updated.
[SuperSU] ignaciojn:
As of lately (around the release of SuperSU for Android 4.3), I've a persistent SuperSU screen wakelock ("WindowManager").

Is this normal?

Device details: Samsung GT-I9500, latest stock firmware (4.2.2), CF-Auto-Root, SuperSU v1.51 with updated binaries.
[SuperSU] Chainfire:
I depends on how CIFS shares are mounted. There are old ways of doing it that will no longer work (but they will also likely not work on 4.2) and there are ways that can work.

This is not normal, no. What tool have you used to determine this?
[SuperSU] ignaciojn:
Wakelock Detector v1.5.4

I'm active in another forum (Grupo Android), and there's a couple of users there with the same issue.
[SuperSU] Chainfire:
EDIT: Sorry that's not right.

It's strange that you see no other wakelocks, as WindowManager wakelock can exist, but it should not really be on it's own... very strange. Is there anything you feel triggers this? After a fresh reboot, if you never got the allow/deny popup, will the wakelock be there?

This wakelock is managed by Android in the name of SuperSU, I'm afraid in 4.3 it may be bugged.
[SuperSU] ignaciojn:
I'm quite compulsive about wakelocks, and I've never seen a SuperSU wakelock before. It all started around the time of SuperSU for 4.3. Bear in mind that I'm in 4.2.2.

The wakelock is present, even if there's no Ask/Deny prompt.

I'm attaching the full set of Wakelock Detector screens (screen, CPU, and triggers), maybe it helps. (the massive Android System wakelock is due to Wi-Fi hotspot).

Thank you for your prompt reply, and if there's anything else I can do please feel free to ask.

PS. I'll install BetterBatteryStats, maybe it brings new info.
[SuperSU] polobunny:
Guess you guys aren't alone haha. Cm10.1 nightly

Edit: Ignore me. Greenify had an update and prompted for root for like 2 hours, this is likely it. Not an issue on SuperSU part.
[SuperSU] Chainfire:
I've been hunting through the Android source code for a bit, and the only reason I can find for a "WindowManager" wakelock (again, Android manages this wakelock, not SuperSU) can as far as I can see right now only be triggered by the allow/deny prompt. The thing is, while that prompt is visible, a second and/or third wakelock will also be used.

I'm not sure where this lonely "WindowManager" wakelock could come from right now.

Not an issue, but your screenshot does nicely illustrate my previous point --- this is where I expect to see the "WindowManager" wakelock - next to the others.
[SuperSU] polobunny:
And imagine, it prompted me for 2 hours total. Prompted for su, kept my screen awake in my pocket, then back to sleep after my 1 minute timeout, and almost as soon as it got back to sleep lit up again and prompted me for su to hibernate an app and so on...
[SuperSU] ignaciojn:
I think I've identified the issue.

I'm using the donate version of Greenify, with the experimental setting to display push notifications even if the app is hibernated.

I guess that's what triggering SuperSU constantly, without prompt.

I apologize for the inconvenience. :(
[SuperSU] mickrussom:
SuperSU wont update, stuck at wait 5 mins

I tried to update form 1.45 to 1.51 and its stuck. Please help. "su - " works from command line, it seems supersu works. but it wont update.
[SuperSU] Bill Gamble:
Recommended method is to flash the 1.51 zip from recovery.
[SuperSU] jazzruby:
OK, I had some spare time to play around with this; I could flash <=1.45 yet 1.51 fails using the same ROM/Recovery

I deleted the updater-script and converted the update-binary to shell script and used pipe fd to the recovery binary via the recovery api

Here's the script:

#!/sbin/sh
# arg 1 is recovery api version, generally 3.
# arg 2 is the pipe fd, to the recovery binary.
# communicate with it using the recovery api.
# arg 3 is the zip file
echo -n -e 'ui_print Installing SuperSU\n' > /proc/self/fd/$2
echo -n -e 'ui_print\n' > /proc/self/fd/$2
mount /system
mount /data
unzip -o "$3" "tools*" -d /tmp
chmod 755 /tmp/tools/chattr
/tmp/tools/chattr -i /system/xbin/su
/tmp/tools/chattr -i /system/bin/.ext/.su
/tmp/tools/chattr -i /system/xbin/daemonsu
/tmp/tools/chattr -i /system/etc/install-recovery.sh
rm -f /system/bin/su
rm -f /system/xbin/su
rm -f /system/xbin/daemonsu
rm -f /system/bin/.ext/.su
rm -f /system/app/Superuser.*
rm -f /system/app/SuperUser.*
rm -f /system/app/superuser.*
rm -f /system/app/Supersu.*
rm -f /system/app/SuperSU.*
rm -f /system/app/supersu.*
rm -f /data/dalvik-cache/*com.noshufou.android.su*
rm -f /data/dalvik-cache/*com.koushikdutta.superuser*
rm -f /data/dalvik-cache/*Superuser.apk*
rm -f /data/dalvik-cache/*SuperUser.apk*
rm -f /data/dalvik-cache/*superuser.apk*
rm -f /data/dalvik-cache/*eu.chainfire.supersu*
rm -f /data/dalvik-cache/*Supersu.apk*
rm -f /data/dalvik-cache/*SuperSU.apk*
rm -f /data/dalvik-cache/*supersu.apk*
rm -f /data/app/com.noshufou.android.su-*
rm -f /data/app/com.koushikdutta.superuser-*
rm -f /data/app/eu.chainfire.supersu-*
unzip -o "$3" "system*" -d /
cp /tmp/tools/99SuperSUDaemon /system/etc/init.d/99SuperSUDaemon
chown 0:0 /system/bin/.ext
chmod 777 /system/bin/.ext
chown 0:0 /system/bin/.ext/.su
chmod 6755 /system/bin/.ext/.su
chown 0:0 /system/xbin/su
chmod 6755 /system/xbin/su
chown 0:0 /system/xbin/daemonsu
chmod 6755 /system/xbin/daemonsu
chown 0:0 /system/etc/install-recovery.sh
chmod 755 /system/etc/install-recovery.sh
chown 0:0 /system/etc/init.d/99SuperSUDaemon
chmod 755 /system/etc/init.d/99SuperSUDaemon
chown 0:0 /system/app/Superuser.apk
chmod 644 /system/app/Superuser.apk
/tmp/tools/chattr +i /system/etc/install-recovery.sh
rm -rf /tmp/tools
umount /data
umount /system
echo -n -e 'ui_print Finished!\n' > /proc/self/fd/$2

Flash/Install OK

99SuperSUDaemon is in init.d and install-recovery.sh has immutable bit set and ps | top show daemonsu is NOT running (OS is 4.2.2) so everything appears good and all root functions (firewall, OC, file ops, etc...) seem to be working properly.

[MENTION=631273]Chainfire[/MENTION] do you foresee any issues?

Thanks and have a great day (and vacation)

-JR-
[SuperSU] looppingz:
Today I did a zip install through recovery directly. Worked fine.
[SuperSU] Azerox:
Is there any way i can get notifications in the status bar instead of toast?
[SuperSU] switchgott:
Hi,

Chainfire we need you help!!

I got the new asus memo pad 10 fhd device with intel soc Z2560 (x86) and android 4.2.2

Please, could you help us to root it?

Dont know how.

But the lenovo K900 is still rootet.

Could you find a solution to root it?

BIG BIG Thanks for your help

Bye
[SuperSU] bas-r:
I'm having the same issue as you: cannot update in the app and having the same issue trying to install the zip file through TWRP (on a Nexus 4 with stock 4.3 firmware).

I'm not exactly understanding what you've done to achieve installation, but I guess I need to do the same...

Can you elaborate?
[SuperSU] :
Jorrit no lag no more! Lowering cpu usage really made it smooth as a baby's butt thanks :D
[SuperSU] jeff6125:
Awesome thanks! Root explorer is prompting ok.
[SuperSU] dimebagdan65:
Lol root explorer...
[SuperSU] iamsmallpang:
why i can't upgrade the last version 0.83 in the market

the code show (492)???????????
[SuperSU] shaggyskunk:
You could try unistalling, then reinstalling.. Give it a shot.

Sent From my Two Tin Cans & String Device on The Wookie Network
[SuperSU] Chainfire:
That's a Market error... it'll clear itself up eventually (1-2 days)
[SuperSU] iamsmallpang:
can i download the last v.083 cwm zip....and then flash the last version from CWM (flash update)?

not in market....
[SuperSU] sparksco:
What I did was I had already flashed the older version with the CWM zip and then v0.83 updated from the market just fine. Then I used titanium backup to merge update into rom.
[SuperSU] bolkan.kilicer@hotmail.fr:
No more SU on my galaxy S I9000

I have a bug with SuperSU!

I have no more root access.

Kernel Semaphore, JVU 2.3.6.

HELP Please

Edit: installed Stock+ kernel + and delete SuperSU and everythings returns to OK
[SuperSU] nicholaaaas:
but what makes the frequency drop when the screen is off? without a profile if a process wants to it can still be at max cpu
[SuperSU] monomer888:
BetterBatteryStats and SuperSU

I've seen some unexpected behaviour with SuperSU and BetterBatteryStats 1.6.1.0. The Alarms listing function of BetterBatteryStats asks for a 'dumpsys alarm' and SuperSU prompts for permission now and again even if I've set it to grant permission and not to ask me again.

EDIT (19/3/2012): I noticed since my initial posting that BetterBatteryStats 1.7.1.0 is available. Alas, the above still happens with that version.
[SuperSU] segv11:
Hiding SuperSU

I used Tasker with "application contexts" to do the dirty work. The application context can fire an "entry task" to unroot the phone when the nosy app comes forward, and an "exit task" to re-root when the app is no longer frontmost. I'm sure Chainfire will eventually build this functionality in, either as a tasker plugin, or a published intent.

Since I couldn't find either, I resorted to the following hack: I made the following shell script, put it someplace in /system, and made it executable. Then I call it from Tasker with "Misc / Run Shell" in the entry and exit tasks.

#!/system/bin/mksh
#
# usage:
# hideroot.sh 0 replace su binary
# hideroot.sh 1 remove su binary
su=/system/xbin/su
subackup=/system/.bash/.ssu
mountargs="/dev/block/platform/omap/omap_hsmmc.0/by-name/system /system"
if [ "$1" -eq 1 ]; then
# Un-Root
if [ -u $subackup -a -f $su ];
then
$subackup -c "\
mount -o rw,remount $mountargs; \
rm /system/xbin/su; \
mount -o ro,remount $mountargs; "
fi
else
# Re-Root
if [ -u $subackup -a ! -u $su ]; then
$subackup -c "\
mount -o rw,remount $mountargs; \
cp -f -p $subackup /system/xbin/su; \
mount -o ro,remount $mountargs; "
fi
fi

YMMV; there are some parameters you will want to tweak for your particular device. This is just a hack at this stage, with far too many device- and versions-specific parameters hardcoded.
[SuperSU] Chainfire:
Actually something very similar is coming :)

Still I don't see how making this script and running it from Tasker is any faster than pressing the unroot button in SuperSU ... but maybe that's me, I don't use tasker.

EDIT: ah yeah I see you are triggering it automagically if an app starts or stops. I won't be doing it like that, because such a trigger does not actually pause said task. The trigger and the task (and thus the un/re-root) will run asynchronously, and thus it is quite possible for said task to have detected root before it has been removed.

EDIT#2: also, subackup will soon likely change access and location.
[SuperSU] sparksco:
The unroot button works great for me. I can use it to watch Google Play Movies just fine :) The latest version 0.83 is running much better than previous versions for me. The previous versions were causing me to loose all cellular service where I could not make/receive phone calls or text. This could only be fixed by doing a data/factory wipe and reflashing my rom. A normal reboot would not fix it. I'm not sure if it was related to that cpu usage or ram usage or what, but the bug seems to be gone now. Will have to test for awhile longer and see if it pops up again. Thanks for all the work!
[SuperSU] segv11:
I just intended this to be a quick hack until you could Do It Right. :) Yes, the race condition can be a problem, which needs another work-around with launching the app from a widget-task after first unrooting. I look forward to not needing to do such an ugly hack soon.

And I understand the need for your subackup location to stay one step ahead of nosey app developers who might be looking for it. ;)
[SuperSU] Chainfire:
You can imagine my delight at you posting it :P
[SuperSU] wraithdu:
@Chainfire

Any luck figuring out the funny behavior of BetterBatteryStats that has been posted? I'm seeing the same things on my Nexus. Is this a problem specific to BBS, or a more general bug?
[SuperSU] Andy3105:
Guys, hope someone can help me with this..........

I've posted this elsewhere and i've still not sorted it, anyway every time I try to run Supersu I get an error message saying that there is no binary and Supersu cannot install it.

I have installed it using the zip file via recovery and I have uniinstalled the old Superuser app as this was not automatically done, all my apps that require Supersu permissions are working and Supersu even asks for my permission so it's working fine but I just cannot get rid of this message.....
[SuperSU] Benzoman:
The answer is somewhere in this thread. You might have to search it. I think the quick answer is to goto settings and clear data for SuperSU, but don't quote me on that, I'm old and am lucky I remember my name some days ;)
[SuperSU] jimmkind:
I have this issue too. The question has been asked, but not answered in this thread, or any other. i have searched it. It seems that the app cannot identify the su binary when being on the internal system partition. if it is installed in the data partition it work as it should.

I am on official cm7.2 kang, htc desire

Hope someone can sort it
[SuperSU] CyberpodS2:
I have the exact same issue. I am on the same phone running a custom GB27 tw rom with the agat kernel. I tried using the flashable 1.51 zip in the OP and it seems like it goes through fine. But after rebooting and launching SuperSU it still wants to update the binary and fails. If I use the cwm/twrp option at that prompt, it just boots into recovery and sits at the first menu like it has nothing to do. I am going to wait and see what happens today or tomorrow as it's functional and still have root. I just can't launch the SuperSU app itself. If I hit cancel at the update binary prompt it just closes.
[SuperSU] rdoliv:
Funny thing happening with me.

I'm using a Nexus 4 with JB 4.3, unlocked and rooted with CWM and Su 1.51, no custom rom. However, when I try to enable/disable the GPS directly it says it can't, and that i should root to make it work. (PowerToggles opens the GPS config instead of enable/disable it directly. Also Tasker doesn't accept a profile to change the GPS on/off).

However, Helium recognize root access and it's working fine, as well as Titanium Backup Root.

Is something wrong (or new) with SuperSU 1.51 or the JB 4.3 that disables direct access to the GPS enabling/disabling?
[SuperSU] 3c:
Nothing wrong, as I use a GPS toggle in Android Tuner, running fine on Nexus 4 with JB 4.3 and SU 1.51. I can tell also 4.3 didn't break access to the GPS toggling as I didn't have to make any changes in Android Tuner for the toggle to continue to work.

FWIW, GPS enabling/disabling requires root and system privileges as of Android 4.(x?), so apps need root and make system partition R/W and copy stuff there.

I would assume those apps are mounting /system RW using root user, but then trying to copy their stuff from the app (standard user), and that last bit no longer works on 4.3, the /system partition remains RO for all other users but root. This is very unlikely to be fixable within SU by the way, those apps will have to be updated.

---------- Post added at 01:52 PM ---------- Previous post was at 01:43 PM ----------

Maybe Greenify tried to access root, and the prompt make Greenify wait for 2 hours to get it (or not), however I don't understand why the wakelocks? Those are held by SuperSU, which means that the prompt will wake-up the device and keep it awake.

At any rate, I don't see the need for a wakelock here. And this is definitely not Greenify's the issue: An app requests root the same way whether it's already granted or yet to be confirmed by end-user, and does not wake-up the device for that.

Opening a prompt (UI) to the user should not wake-up the device either. The timeout could start only when the device is turned on and the prompt activity is actually resumed. That's how SuperUser does its stuff I believe.

If you either grant greenify root permanently or deny wakelock permission to SU this will get rid of the issue. I did deny wakelock permission to SU since I read your post, works well so far.
[SuperSU] rdoliv:
The direct access to the GPS by shortcut toggling and by tasker is one of the functions I use the most, and it was working fine before the whole JB 4.3 and SuperSU 1.51 update.

Tried to remove and reinstall it, but nothing changed, I still can't gain direct access to the GPS. Damn... :/

Thanks anyway!

Rodrigo
[SuperSU] 3c:
Removing/reinstalling won't make a difference, the way this app does it no longer works on 4.3. Might want to check what app this app installs to /system/app folder and do it manually. Then it may start working. You can always open the APK (with WinZip or similar), open assets folder, it's likely to contain another APK, copy that APK to /system/app, then it may work as before.

---------- Post added at 02:00 PM ---------- Previous post was at 01:56 PM ----------

After checking both Tasker and PowerToggles on PlayStore, they don't seem to provide that feature, except on CM ROMs:

PowerToggles:

1) Can the GPS toggle be single click instead of a shortcut to system settings?

No. Direct GPS toggle is not possible due to security restrictions on android.

Tasker: * MISC: (Broadcast) Action Intent, Component Intent, Get Location, GPS Status (<2.3 or Cyanogen/submod), Run (ASE) Script, Say, Say To File, Shut Up, Search For, Set Clipboard, Reboot (root only), Set CPU (root only) Set Timezone
[SuperSU] polobunny:
The problem is not with Greenify per se rather than me, because my device woke up, I didn't deny/accept su, then fell back asleep. And after some time, Greenify would try to do its job so it woke up again and so forth.

As for waking up, I do not know if this is an issue related to Greenify or SuperSU, but I honestly don't care. =)
[SuperSU] rdoliv:
The PowerToggles worked like a charm, just one press on the gps icon used to enable/disable it. The Tasker is a new app I just installed today (bought it) and never messed with the gps functioon, so I can't guarantee it.

I'll try to search for solutions, since the Tasker opened a windows requiring me to install "Secure Settings" app the manage the direct gps access. Darn... ;P
[SuperSU] polobunny:
Secure Settings is a pretty neat plugin. I use it for a lot of my stuff and it works wonder. :)
[SuperSU] rdoliv:
Yeah, i saw that! :)

Just to update the issue, the problema is already acknowleged by the developer. The way JB 4.3 delas with GPS changed, and screwed direct access to toggling.
[SuperSU] jesssiii:
I'm using CM10.2 and direct GPS toggle is working fine. (Android 4.3)

Galaxy Nexus Toro
[SuperSU] 3c:
In CM builds, they removed the security restrictions on GPS state, hence it's working fine. But in stock Android 4.3, it's restricted to system apps, hence the use of secure settings in Tasker or a similar plugin in Android Tuner.
[SuperSU] rdoliv:
Yes, CM doesn't count since the custom rom is able to handle direct access to gps toggling.

However, after I post a message on the board of Power Toggles, the developer said if we have root, moving the Power Toggles app to system app solves que question.

I tried, and it really works, 1-click gps toggling! ;)

Now, they have to fix the Tasker to be able to handle GPS on/off.

Best regards,

Rodrigo
[SuperSU] jazzruby:
I basically replaced the update-binary with a shell script, I've attached a zip file of the script (with it's folder structure) to my original post HERE

If you want to try it (at your own risk) just copy the file from my zip and overwrite/replace the one in your SuperSU zip also deleting the updater-script.

HTH,

-JR-
[SuperSU] -Johan:
As some more people in this thread, the app tells me to update my binary and I click accept, normal install won't work and the recovery install won't work either. Other apps tell me I don't have root while I clearly am. Any ideas? Thanks!
[SuperSU] lion7718:
SuperSU told me my binary was missing & I had to re-root to fix...none of my rooter apps worked...I flashed 1.51 with TWRP & all is fine now.
[SuperSU] osm0sis:
[MENTION=631273]Chainfire[/MENTION]

The new CWM 6.0.3.5 will suppress the disable install-recovery.sh prompt if you create a /system/etc/.installed_su_daemon file. Would be a good addition to the zip. :good: :)
[SuperSU] -Johan:
I actually just did this like 2 minutes before I saw your reply, thanks anyways!
[SuperSU] dragxdk:
hi

the app super su by chainfire don t want to update binary... :(

tapatalk

---------- Post added at 10:55 PM ---------- Previous post was at 10:54 PM ----------

hi

me too, some help please...

tapatalk
[SuperSU] SaMi_InF:
Download

How can I download SuperSu v1.51 ?
[SuperSU] polobunny:
Read the first post...
[SuperSU] Sloth:
http://download.chainfire.eu/345/SuperSU/UPDATE-SuperSU-v1.51.zip
[SuperSU] gamepois0n:
no problem flashing 1.51 here

Signup and get 15 Gb free plus an extra 5 Gb each using this link: https://copy.com/?r=vOeT9D
[SuperSU] Vaetheran2107:
I'm not able to update the binary on my nexus 4. It keeps installing like forever and a reboot like suggested doesn't work either.

Gesendet von meinem Transformer TF101 mit Tapatalk 2
[SuperSU] osm0sis:
Yeah. I ran into the same on my GN. Ended up just using the zip again.
[SuperSU] Vaetheran2107:
Sorry but I'm unable to use the zip.

Running stock recovery

Gesendet von meinem Nexus 4 mit Tapatalk 2
[SuperSU] osm0sis:
Sideload it. It's signed.
[SuperSU] Vaetheran2107:
Can you guide me? I haven't sideloaded anything yet.

Thought maybe I should wait for the next update to fix it.

Gesendet von meinem Transformer TF101 mit Tapatalk 2
[SuperSU] osm0sis:
Sure. You need adb and fastboot on your system and the driver installed - Universal Naked Driver is great for Windows. Reboot to recovery. Press Volume up (or maybe down depending on device) and Power to bring up the menu, connect via USB to PC then select the sideload option. From a command prompt where you've got adb and the zip type: adb sideload <filename>
[SuperSU] gialakias:
I didn't know that you can flash zips from stock recovery that are not signed by Google. So the root process is easy even with a locked bootloader? No need to do the steps in efrant's guide and no need to lose data?

Sent from my Nexus 4
[SuperSU] sergiozaki:
After download OTA 4.3 jb to my Nexus 7

Hello everyone

I need help pls , I followed some instructions to download 4.3 Jb on my N7 32gb, Google framework on apps cleared data, them checked for updates and bingo, it downloaded 4.3 . After that N7 automatically rebooted to TWRP menu , please what do I have to do? My N7 is rooted.

Sorry my English, thks
[SuperSU] polobunny:
This is not the right place for that. Get help from your N7 subforum.
[SuperSU] osm0sis:
I know you can sideload zips in stock recovery that aren't signed by Google (but are properly signed) but I'm not 100% sure that the SuperSU zip will work that way.
[SuperSU] RooFgr:
Anyone tried it yet?

If i choose to unistall supersu (from the supersu options) in order to install an other su app will that work?