- May 4, 2016
v2.78 SR1 (aka beta) has been released.
Release notes are here: https://plus.google.com/+Chainfire/posts/8mPirmjhgqT
Was the intent of that last item to increase the boot time by a minute? That seems to be the case on my N5 running stock ROM.. just hangs at the Google logo for a long time before continuing..
I've definitely never had any issues with su.d scripts running out of execution time.. my gappsintegrator script always continues to run for up to several minutes after boot completes no problem.
To reproduce the issue I'm assuming you just need a su.d script that sleeps until sys.boot_completed like mine currently does (to set a sysfs value overriding the ramdisk). Hopefully things can go back to executing in the background and not holding up the boot.
@Chainfire i wonder why increasing the su.d script launch time to 60 from 4 seconds?
I haven't tested it but doesn't it cause problem for LiveBoot? And also i have my script to setup lots of things and i want it to be run when bootanim is launched.
But maybe i haven't understand it correctly and it make su.d script 60 secs to excute and passing this delay scripts won't be launched. Which is this case avoid some problem i guess and i have nothing to complain.
Anyway your work is awesome. Thanks for your work!
/su/bin/sush /data/user/0/eu.chainfire.liveboot/files/liveboot &
I was happy to hear about the possible compatibility fix with Magisk, then decided to test. I was in TWRP, mounted /data/magisk.img, deleted the related folder to another super user manager, and I install SuperSU. Already I got a little confused when it was installed in system mode, which before always installed in systemless even without the /data/.supersu terminal command. I thought I'd give bootloop because before when i tried to force the system mode (i was without PC was and could not run the risk of running out of root/TWRP) always entered bootloop, but this time I believe that the changes in the boot.img made by Magisk cause Android boot. I opened the SuperSU app and said no binary was found, but when I opened the FX File Explorer and navigated to /system/xbin/ the binary "su" was there. I thought it was a bug first boot then restarted, but again the same thing. I went back the TWRP, installed the stock boot.img (removing Magisk) and reinstalled SuperSU now installed in systemless and it worked perfectly. So I do not know how it is in other devices, but at least in my seems that compatibility does not work yet
I just updated to 2.78 SR1 and some apps are having problems detecting that the device is rooted (Nexus 7 (2013) stock, build MOB30X and Nexus 6P, stock, build NRD90U). For example Helium or Secure Settings. Titanium Backup or Recently for example don't have any problems.
I can't tell which version was the last one working. I just noticed it after I have reinstalled Secure Settings on my Nexus 7 with SuperSU 2.77 BETA installed and it's telling me now that it's not rooted.
Sounds to me like you had the old app compatibility mode enabled (BINDSYSTEMXBIN) previously, and you have it disabled now.
From adb shell (or Terminal Emulator), run 'su', then:
Then, reflash SuperSU.
Note that if your TWRP cannot decrypt your /data partition, this solution will not work.
Wot you talking about Willis? SuperSU is now a Chinese company?Just reading the release notes and not sure if it's me being paranoid but it says this latest release fixes a vulnerability to the kernel etc, this seems to have happened with the release that ccmt released with notifying @Chainfire and this new release has fixed the security risk.
Normally I wouldn't question this as I've used SuperSU for as long as I've had android but with the knowledge that an unknown Chinese company is in control and suddenly there is a security vulnerability in an app that can pretty much have few reign of your system begs the question as to the actual security behind this app anymore. We all know these Chinese dev companies are renowned for spamming apps or provide back door security issues in apps.
Like I said I may just be being paranoid and reading to much into this but it just raised the question as to how secure is this app becoming now it's in the hands of an invisible entity.