As stated in the title, Adaway after reboot will be disabled, have to re-enable it each time, have read sometimes it's device specific, reference to the HTC I believe, because of how it's partitioned. Wonder if the same for Moto X?
Wondering if anyone else has figured it out. Thanks
M973 said:
As stated in the title, Adaway after reboot will be disabled, have to re-enable it each time, have read sometimes it's device specific, reference to the HTC I believe, because of how it's partitioned. Wonder if the same for Moto X?
Wondering if anyone else has figured it out. Thanks
Click to expand...
Click to collapse
Are you rooted, booting into recovery to disable write protection, and then running AdAway?
That's all you should need to do. Then reboot normally and the .hosts file changes should stick. This is what I've been doing and it works every time.
Pretty sure this is because the system partition isn't normally mounted read/write. AdAway works by editing the hosts file, which lives in the system partition.
Are you rooted with MotoRoot, or PwnMyMoto? The only way AdAway settings could stick through a reboot is to boot into PwnMyMoto's write protection bypass mode (recovery mode), and run it there.
I rooted with PwnMyMoto, installed xposed framework for Motoxposed, rebooted only then into recovery to enable write so motoxposed would work, which is running fine. I'll have to look at how I run the app Adaway from within recovery.
Thanks
Edit: so meaning, if I reboot, I need to reboot from recovery, as opposed to other rooted apps that stay set even with a normal reboot, I may need to reboot recovery each time? Otherwise, I find after a normal reboot, just launching Adaway and "enabling" does fine, too, no reboot after needed.
I have the same issue, but if I boot from recovery, wifi will not work. So, I can either choose no ad block or no wifi and no idea how to fix either.
Sent from my SAMSUNG-SM-N900A using Tapatalk
Related
From all I am reading, Android disables write protection when you boot into recovery and any changes that you make in recovery stick when you boot into system. And if you have root access, you can make changes to system in recovery.
So what advantages are there to having write protection disabled when you boot into system? Why can't you make any changes you want while in recovery? Isn't that safer anyhow? Do some apps need write protection disabled to run?
Cozume said:
From all I am reading, Android disables write protection when you boot into recovery and any changes that you make in recovery stick when you boot into system. And if you have root access, you can make changes to system in recovery.
So what advantages are there to having write protection disabled when you boot into system? Why can't you make any changes you want while in recovery? Isn't that safer anyhow? Do some apps need write protection disabled to run?
Click to expand...
Click to collapse
I don't have a technical response or even very good response, but I do have an example of why you need access to the write protection.
I use AdAway to block advertising on my phone. (The ethics of doing this are up for debate, but lets leave that to another venue)
AdAway needs root access and the ability to modify the hosts file on the phone, which is a system protected file (for good reason). If write protection is on, then AdAway fails to modify the phone's hosts file and the ad blocking does not take place. With write protection off, AdAway is successful an my browser screen is far less cluttered when surfing.
I set the app to notify me when updates are available, but not to automatically apply the updates. Then I manually reboot to recovery and update my hosts file via AdAway. After I get the successful update I reboot normally and use my phone in the regular non-recovery mode.
_Boondock_ said:
I use AdAway to block advertising on my phone. (The ethics of doing this are up for debate, but lets leave that to another venue)
AdAway needs root access and the ability to modify the hosts file on the phone, which is a system protected file (for good reason). If write protection is on, then AdAway fails to modify the phone's hosts file and the ad blocking does not take place. With write protection off, AdAway is successful an my browser screen is far less cluttered when surfing.
I set the app to notify me when updates are available, but not to automatically apply the updates. Then I manually reboot to recovery and update my hosts file via AdAway. After I get the successful update I reboot normally and use my phone in the regular non-recovery mode.
Click to expand...
Click to collapse
Ok, but that is my point - you can do it in recovery and in fact it is safer to do it in recovery. Stock android disables write protection when you boot into recovery.
So we don't have to boot into recovery everytime we modify system.
Sent from my XT1053 using XDA Premium 4 mobile app
c19932 said:
So we don't have to boot into recovery everytime we modify system.
Click to expand...
Click to collapse
Right, for convenience sake. But what I am asking is it ever necessary to have write protection disabled when you boot into system? Meaning, is there anything that you would need it for that booting into recovery to make the changes wouldn't work?
Cozume said:
Right, for convenience sake. But what I am asking is it ever necessary to have write protection disabled when you boot into system? Meaning, is there anything that you would need it for that booting into recovery to make the changes wouldn't work?
Click to expand...
Click to collapse
You can't make changes to the system part I on with out write protection being disabled. Jcases method is a hacked recovery that when selected from fastboot boots you into a disabled system and you make your changes then reboot normally.
Sent from my XT1058 using Tapatalk
The only time I need write protection off is if/when I'm making changes to /system or make changes to or add an Xposed module.
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,
So I have a problem here. I rooted my X1049 with kingroot, to get temp root, removed write protection with the remount command on the terminal emulator, and installed Safestrap. It installed just fine. But when I reboot my phone to enter Safestrap, it doesn't show up, because when my phone boots up and I check the system partition with my file explorer, both Su and Safestrap have been removed. I have also tried to replace Kingroot with SuperSU, which doesn't work as when I open SuperSU it says I need to upgrade the Su binaries which fails. And when I reboot my phone, Su is removed, yet again. So to me it seems like the main problem is Android rolling back my changes to /system. I really need help with this, so plz respond as soon as possible.
Sent from my XT1049 using Tapatalk
Write protection cannot be turned off yet, all changes to /system will always rollback.
If anybody finds any way to disable write protection on the Moto X 4.4.4 please post here.
Sent from my XT1049 using Tapatalk
I know that some root methods have it so that when you enter recovery from the bootloader, android boots into write protection off. Does anyone know how this is done? And is it possible to do something like this on 4.4.4?
Hi,
I'm currently so confused as to why my Magisk isn't working. I'm currently running the last CM 13 snapshot for the Galaxy S5 (G900F, klte), and root and Xposed work fine via Magisk.
However, what isn't working is Magisk Hide, and I'm not sure why. However, I'm noticing that even though I fully unrooted cm-su (using SuperSU, in a way that means the only root I can select in Dev Options is ADB only), I'm still getting cm-su detected by Magisk.
I'm confused -- is there anyway I can remove it? I've tried looking through TWRP file manager, but whenever I do so, I can't even see /system/ files, and mounting only mounts to USB, but that's unrelated.
Thanks for any help!
intcompetent said:
Hi,
I'm confused -- is there anyway I can remove it? I've tried looking through TWRP file manager, but whenever I do so, I can't even see /system/ files, and mounting only mounts to USB, but that's unrelated.
Click to expand...
Click to collapse
I don't think SuperSU removes the in-built CM superuser. Use the UNSU zip by osmosis instead. https://forum.xda-developers.com/showthread.php?t=2239421
Also magisk hide will NOT hide Xposed. Yes not even systemless 87.1 Xposed.
SuperSU removed its own root only, CM root is unaffected.
Also, Magisk hide only works with Magisk's own phh root.
And, as far as I know, it can't successfully hide Xposed either. Doesn't matter if it is systemless or not.
Cheers for the replies.
I wasn't aware that Magisk Hide didn't hide Xposed, that's my bad.
As for the presence of CM-SU, SuperSU did do something, as the Developer Options root option is now ADB only while previously it offered the option to Apps too. I'll try unsu.
Here's what I'm meaning btw: imgur.com /a /yTOTw (sorry for the link bypass, there's no other way for me to simply demonstrate the issue) (as you can see in the first screenshot, Magisk detects "cm-su" along with phh. When phh was disabled before I removed cm-su, it only detected cm-su, hence leading me to believe cm-su remains).
e: tried unsu, still cm-su remains. At this point, I'll leave it -- I presume that it's permanently ingrained into the ROM. I've gotten around the restriction I was facing anyway, and I'll adjust. Thanks anyway!
intcompetent said:
Cheers for the replies.
I wasn't aware that Magisk Hide didn't hide Xposed, that's my bad.
As for the presence of CM-SU, SuperSU did do something, as the Developer Options root option is now ADB only while previously it offered the option to Apps too. I'll try unsu.
Here's what I'm meaning btw: imgur.com /a /yTOTw (sorry for the link bypass, there's no other way for me to simply demonstrate the issue) (as you can see in the first screenshot, Magisk detects "cm-su" along with phh. When phh was disabled before I removed cm-su, it only detected cm-su, hence leading me to believe cm-su remains).
e: tried unsu, still cm-su remains. At this point, I'll leave it -- I presume that it's permanently ingrained into the ROM. I've gotten around the restriction I was facing anyway, and I'll adjust. Thanks anyway!
Click to expand...
Click to collapse
If there are SU files in /system/bin and /system/xbin, then CM root was not removed. Not completely.
To actually remove it you have to delete those files.
Pwnycorn said:
If there are SU files in /system/bin and /system/xbin, then CM root was not removed. Not completely.
To actually remove it you have to delete those files.
Click to expand...
Click to collapse
@intcompetent Osmosis's unsu zip removes those files. If those files are still there after flashing the unsu zip, I'd ask in his thread.
knpk13 said:
@intcompetent Osmosis's unsu zip removes those files. If those files are still there after flashing the unsu zip, I'd ask in his thread.
Click to expand...
Click to collapse
Or just remove them manually, jeez. It's just two files.
I've been doing it manually for months and everything works as intended.
As an a closer, there's nothing there. I presume that Magisk is picking up something freaky from somewhere, or something's up, but I'm good guys. I won't need anymore help.
Cheers!
I found this zip around somewhere. I believe it works to remove all root (systemless as well) and I've always flashed it before rooting normally. It should also remove CM root afaik.
As a test, after flashing, check and see if you pass safetynet before installing magisk
intcompetent said:
As an a closer, there's nothing there. I presume that Magisk is picking up something freaky from somewhere, or something's up, but I'm good guys. I won't need anymore help.
Cheers!
Click to expand...
Click to collapse
I
L
Could someone please point me at instructions on how to root LN14.
I've searched the HD/HD+ forums for 'root LN14' and 'rooting LN14' and got no results (which by itself is suspicious).
have you enabled Developer Options?
I, for one, had no luck with either SuperSu or addon su. The first would put the HD+ into a permanent boot loop necessitating a re-install from scratch,and the latter would install but the unit still indicated it was not rooted. Doing the Dev Op made no difference. A real mystery!
harryzee said:
I, for one, had no luck with either SuperSu or addon su. The first would put the HD+ into a permanent boot loop necessitating a re-install from scratch,and the latter would install but the unit still indicated it was not rooted. Doing the Dev Op made no difference. A real mystery!
Click to expand...
Click to collapse
The file addonsu-14.1-arm.zip in the main folder is the one to use. As I seem to recall, you might have to enable, disable, then re-enable, in order for root access to take effect.
digixmax said:
The file addonsu-14.1-arm.zip in the main folder is the one to use. As I seem to recall, you might have to enable, disable, then re-enable, in order for root access to take effect.
Click to expand...
Click to collapse
That is the one I flashed using 3.0.1.0 TWRP. Not clear on your second sentence: "...enable, disable,, then re-enable...". Forgive me for being lost as to what you physically/specifically mean. Please explain.
Thanks.
harryzee said:
That is the one I flashed using 3.0.1.0 TWRP. Not clear on your second sentence: "...enable, disable,, then re-enable...". Forgive me for being lost as to what you physically/specifically mean. Please explain.
Thanks.
Click to expand...
Click to collapse
I meant "enable, disable,, then re-enable" the root access option in "Developer Options".
Aha! Will give it a go. Thanks.
5/2/2018:
Okay: I d/l three android root checkers and titanium backup. The first root checker (Clivin Inc. with small green android robot graphic) told me I was not rooted both before following your above instructions and after. The other two (d/l after following the above) both say I am rooted. However, I was not and am still not able to get "TB" to run. It says "failed" and that I am not rooted.
Since the HD+ is running really well now in its stripped down mode, I can "leave well enough alone" or try to get "TB" working so I can remove anything not needed for my chosen minimal functionality (ereader, viewing videos, photo review/minor editing) that would further reduce unnecessary battery drain.
Thanks again for the above clarification and any additional thoughts.
I am having this same problem
- Root options *do* appear in my Developer settings, but no amount of toggling on/off/on seems to enable root
- I have flashed the Lineage SU addon, log shows successful in TWRP but no change after boot
- SuperSU from Play Store says "SU Binary occupied"
- Adaway says "Rooted Android required- Either the su binary could not be found or you did not allow root permission for Adaway" ie I believe I am indeed *not* rooted.
- SuperSU flashable zip is a broken link on their website.... http://www.supersu.com/download
Out of ideas here, anyone got anything else I can try?
Edit: I was able to obtain Root properly by flashing Magisk & installing the Magisk Manager APK from here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
You got it. Use Magisk. Works wonders and way better than SuperSU or any other root permission tool I've came across. It's even akin to, and even has within it, xposed and other magical rooted modules for you to try out for a day or two and then decide you don't need it.
pchc_lx said:
I am having this same problem
- Root options *do* appear in my Developer settings, but no amount of toggling on/off/on seems to enable root
- I have flashed the Lineage SU addon, log shows successful in TWRP but no change after boot
- SuperSU from Play Store says "SU Binary occupied"
- Adaway says "Rooted Android required- Either the su binary could not be found or you did not allow root permission for Adaway" ie I believe I am indeed *not* rooted.
- SuperSU flashable zip is a broken link on their website.... http://www.supersu.com/download
Out of ideas here, anyone got anything else I can try?
Edit: I was able to obtain Root properly by flashing Magisk & installing the Magisk Manager APK from here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
Click to expand...
Click to collapse