By default SuperSU 'allow root during boot' (or something similar as I don't have UI is not in English), is unchecked and this appears to cause apps not received root consistently.
As far as my tests goes, SuperSU will start granting root to apps when it receives the BOOT_COMPLETED message, however this message is send in a serialized way to each app having requested it, so any app using root during boot will receive root very inconsistently.
I've verified this on a dozen devices and received numerous reports from end users with the same issue, only enabling the option I mentioned above solves this consistently.
@Chainfire, can this be fixed? Or the default reversed as it's only causing headaches?
Thanks.
Related
hey guys i have one problem with supersu.
i installed clean master and do cleaning **** and startup cleaning things and after reboot all apps that have granted root permission( foldermount, gmd gestures, lightflow, etc), these apps shows no toast popup after boot and to make them grant permissions i have to open them. Same thing when i installed boot manager and did not do anything but boot and again no supersu toast popups about root permissions after boot.
is there a way to keep the root grants after the boot? ( i have checked default acces to grant in supersu app)
I'm having problems with clean master working with SuperSu too.
clean master is so powerfull that disables supersu permissions.
They probably change some file permissions that SuperSU frowns at.
Chainfire said:
They probably change some file permissions that SuperSU frowns at.
Click to expand...
Click to collapse
i want to maintain supersu permissions after every boot no matter what. is there some option in supersu to be activated for that?
i'm on note 3 rooted with stock tw.
''enable supersu during boot''
please explain to me for what is this option
thx :good:
bump
dancapitan said:
''enable supersu during boot''
please explain to me for what is this option
thx :good:
Click to expand...
Click to collapse
This option has a summary that's pretty unclear. I've emailed the dev, hope to receive an answer soon. Fact is apps running during the boot_completed seem to get root randomly if this option is not enabled! Let me insist on the random fact, as my apps get root on boot frequently but not all the time. Other users have reported the same random behavior. Once the option is enabled everything works as expected!
However the option seem to imply that any root request on boot will be granted!? Regardless of user choice????
To make it short, check the option "enable supersu during boot" and root apps will receive root on boot as they used to!
3c said:
This option has a summary that's pretty unclear. I've emailed the dev, hope to receive an answer soon. Fact is apps running during the boot_completed seem to get root randomly if this option is not enabled! Let me insist on the random fact, as my apps get root on boot frequently but not all the time. Other users have reported the same random behavior. Once the option is enabled everything works as expected!
However the option seem to imply that any root request on boot will be granted!? Regardless of user choice????
To make it short, check the option "enable supersu during boot" and root apps will receive root on boot as they used to!
Click to expand...
Click to collapse
You should turn this into a proper bug report in the proper thead (either the beta or its own new thread) with all the useful information you think may be relevant. There is no email support, all support is here.
The option itself is for apps that run before Android is fully up and running, or su from adb shell during a bootloop, etc. I thould not influence apps running su from bootcomplete receivers, and if it does, then that needs to be investigated.
Is there currently any way to enable this feature via ADB on a boot looped phone? I really wish I would have known about this! I wouldn't be stuck where I'm at if I had only checked this option. Device is stuck at LG logo, no download or recovery, but has access to ADB. SU was installed, but I don't have root via ADB since the phone isn't finished booting...thus I'm not able to copy over the proper system.img or change the recovery/laf. Dang!
I have the problem too, when I install Fake Wifi, the automatic SuperSU granted is not working. Please help some advance. Thank's.
Hey guys why root required apps request for root access after installing super su
I have the same problem, have to add a task in tasker, auto open supersu and root granted apps once after boot,
Hey guys, so I'm trying to install BusyBox on my new Nexus 6 running stock 6.0, rooted. When I try to install via Stericson's installer I got from the Play store, I get:
"We could not verify the integrity of the binary selected..." flashes for a moment, then:
"BusyBox installer was not allowed root access. This may be an issue with Superuser, open Superuser and make sure that you are allowing root access. This application will not work without root access."
I've made sure that the app is allowed root access, and have also tried deleting it from SuperSu so it would prompt me and I could grant it access again, but still the same issue. I'm not sure what the deal is, it seems like I could be having root issues? I appear to have root since I am able to use TiBu, but something seems funky. For example usually when I open FKUpdater it says "FKUpdater has been granted super user access..." and then "Unable to acquire ROOT access." Other times it only says "Unable to acquire ROOT access." I haven't tried flashing a kernel with it because I don't want to at the moment while I figure this other issue out, so I'm not sure if it's falsely reporting the root error.
So, I looked into things further and it seems like I may have some sort of permissions issue. I tried using JRummy's BusyBox installer, but that fails also and just tells me to try installing a different version of BusyBox. It also includes a script for fixing permissions, and when I run it I get "error: only position independent executables (PIE) are supported" and "/data/user/0/com.crummy.busybox.installer/files/temp.sh[118]: sync: can't be executed: permission denied."
Permissions for /data/user/0/com.crummy.busybox.installer are set to drwxr-x--x, as is /system. Also /system is only showing 58 MB free but I don't think that's a problem...
Any ideas? I'm totally stumped...
set your SElinux to be permissive(via app or terminal command)
Quick question: why does my Privacy Guard in CM12.1. not show any root access settings at all?
Hi, just bought Amazon Fire Tablet 7", updated to 5.1.1., and installed CM12.1. with SuperSU. Everything worked. However, I decided to switch to CM's built-in root enabler (because it's open-source), so I ditched SuperSU through SuperSU's "Switch superuser apps" feature in SuperSU settings. SuperSU was automatically uninstalled, then I enabled the root privileges through Developer Options and this method too worked like a charm.
However, my Privacy Guard does not show the root access settings, so I have no control whatsoever on which application can or cannot have the root privileges, except turning root off altogether. A few root applications, e.g. AdAway, are working without problem but I was never prompted to grant them the root access in the first place. I've installed new applications, such as Greenify, but it too can access to the root without me explicitly granting the permission. I've also checked if Privacy Guard works at all, and it does, when I disabled locations service, I was prompted to enable it.
I did a factory reset within CM12.1. but to no avail. Any ideas or suggestions? If possible I'd like to get this sorted and try every solution before reverting back to SuperSU. Cheers.
himgil said:
Quick question: why does my Privacy Guard in CM12.1. not show any root access settings at all?
Hi, just bought Amazon Fire Tablet 7", updated to 5.1.1., and installed CM12.1. with SuperSU. Everything worked. However, I decided to switch to CM's built-in root enabler (because it's open-source), so I ditched SuperSU through SuperSU's "Switch superuser apps" feature in SuperSU settings. SuperSU was automatically uninstalled, then I enabled the root privileges through Developer Options and this method too worked like a charm.
However, my Privacy Guard does not show the root access settings, so I have no control whatsoever on which application can or cannot have the root privileges, except turning root off altogether. A few root applications, e.g. AdAway, are working without problem but I was never prompted to grant them the root access in the first place. I've installed new applications, such as Greenify, but it too can access to the root without me explicitly granting the permission. I've also checked if Privacy Guard works at all, and it does, when I disabled locations service, I was prompted to enable it.
I did a factory reset within CM12.1. but to no avail. Any ideas or suggestions? If possible I'd like to get this sorted and try every solution before reverting back to SuperSU. Cheers.
Click to expand...
Click to collapse
Don't have a definitive answer; there are various bug reports from users who have dabbled with SuperSU and the integrated CM12.1 root manager. Thoughts:
- reinstall SuperSU as it is well respected and will likely restore app level access permissions with minimal effort/fuss/risk
- if you prefer to stick with the integrated root manager I would suggest clean flashing CM12.1
- however, since your devices bootloader is likely > 5.0.1 you'll need to use a tool like FlashFire which carries increased risk (albeit small)
- developers tend to test/validate rom updates with SuperSU - a possible consideration moving forward
Davey126 said:
there are various bug reports from users who have dabbled with SuperSU and the integrated CM12.1 root manager.
Click to expand...
Click to collapse
Exactly what I am thinking; something is probably broken along the switching process. Cheers anyway.
Like I said, if the default action is prompt, an app seeks root access and there is no prompt to grant it. If I change to grant as default, everything works. Root Checker, for instance, will fail to detect root in prompt mode but does so in grant mode. Same for Root Browser and, most importantly, Xposed.
I've tried reinstalling SuperSU. Didn't help. I have systemless root on a Moto X Pure and SuperSU 2.82.
I really don't want to leave it with grant as the default action. Not safe. I've been able to find a few other posts with a similar problem but they don't lead to solutions. This is a new behavior. Prompt used to work. About a week ago, I installed the latest version of Sensible Android Auto in Xposed. It worked twice and then stopped. My guess is that is the time when SuperSU stopped granting root. Everything that needs root can get root but ONLY if root is granted automatically to anything that asks for it.
Just rooted my Kyocera Event and deduced it to have the same problem. SuperSU 2.8.2 was not providing prompts and thus not granting root access, however changing to grant default did provide root. I tried installing SuperSU 2.7.9 rc4 but had the same result. I'm now just waiting for a definitive fix while looking for an alternative solution.
I just installed magisk succesfully(?) on my xperia 5 ii following this guide:
https://forum.xda-developers.com/sony-xperia-5-ii/how-to/guide-magisk-twrp-recovery-t4177209/page7
Using the beta channel (stable simply doesn't even boot), magisk manager shows v21 installed. However none of the root apps I tried so far (busybox, adaway, system app remover) works. All of them give some kind of error. The root privileges are being granted (I get the promt to grant/deny and the popup that root was granted). This is very weird and the first time it happens to me on any device. The root browser file managers shows the "root directory" with 0 free space incorrectly (1.6GB used - 1.72 total) I tried copying a file inside the /system directory and it just didn't do anything. I tried reinstalling magisk from the manager, but its still the same. Any help will be appreciated, I really have no idea what to try at this point.
Hard to say... What's "some kind of error"? Maybe the Magisk logs show something (although you'd likely have to switch to the Canary channel to get any useful logs).
I think it's best to wait for a reply to your query in the thread you linked. That's likely to be the best place to get help, since that's where you find other users of the same device...