I'm a little lost on the differences between the shield and every other android phone I've owned. What difference does the developer image offer compared to simply unlocking the bootloader and installing magisk through TWRP on the shipped firmware?
Ultimately I want to root for all the obvious reasons, but also use magisk hide to keep PSVue and the like still working with root undetected. It seems that the developer image is pre-rooted, can that be hidden?
Thanks for any clarification
tstack77 said:
I'm a little lost on the differences between the shield and every other android phone I've owned. What difference does the developer image offer compared to simply unlocking the bootloader and installing magisk through TWRP on the shipped firmware?
Ultimately I want to root for all the obvious reasons, but also use magisk hide to keep PSVue and the like still working with root undetected. It seems that the developer image is pre-rooted, can that be hidden?
Thanks for any clarification
Click to expand...
Click to collapse
No it is not, as long as your bootloader is unlocked and you follow the directions on the thread how to install Magisk you will achieve root
jionny said:
No it is not, as long as your bootloader is unlocked and you follow the directions on the thread how to install Magisk you will achieve root
Click to expand...
Click to collapse
You don't get true root with the ota firmware though.
You won't have write access to the root dir.
Which you will if you use the developer image through adb, or by disabling dm-verity.
You won't be able to do that on the ota.
mLgz0rn said:
You don't get true root with the ota firmware though.
You won't have write access to the root dir.
Which you will if you use the developer image through adb, or by disabling dm-verity.
You won't be able to do that on the ota.
Click to expand...
Click to collapse
So on non dev if I disable dm verity with magisk, I can write to system.
Or is it not that simple.
Sent from my SM-G965F using XDA-Developers Legacy app
Largewoodenspoon said:
So on non dev if I disable dm verity with magisk, I can write to system.
Or is it not that simple.
Sent from my SM-G965F using XDA-Developers Legacy app
Click to expand...
Click to collapse
No you won't be able to get write access on the non dev.
mLgz0rn said:
No you won't be able to get write access on the non dev.
Click to expand...
Click to collapse
I was referring to the Pro version
jionny said:
I was referring to the Pro version
Click to expand...
Click to collapse
Does not matter if it's the pro version or not.
You can only get write access to the root dir using the developer image.
mLgz0rn said:
Does not matter if it's the pro version or not.
You can only get write access to the root dir using the developer image.
Click to expand...
Click to collapse
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
jionny said:
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
Click to expand...
Click to collapse
This ^^
I don't understand why so many people say they don't have write privileges. I've not installed TWRP or any other custom recovery, I've simply used ADB to fastboot (boot only , not flashed) with an image that was posted in the magisk thread. Once loaded , I installed Magisk , let it root my shield, used x-plore and verified that I can change permission on any file in the system folder. All my root related functions work without any issue. Shield 2017 with 7.2.2
jionny said:
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
Click to expand...
Click to collapse
On what firmware version?
I doubt you can write to the /system and /data dir if you are on 7.2+.
---------- Post added at 14:37 ---------- Previous post was at 14:31 ----------
Roamin64 said:
This ^^
I don't understand why so many people say they don't have write privileges. I've not installed TWRP or any other custom recovery, I've simply used ADB to fastboot (boot only , not flashed) with an image that was posted in the magisk thread. Once loaded , I installed Magisk , let it root my shield, used x-plore and verified that I can change permission on any file in the system folder. All my root related functions work without any issue. Shield 2017 with 7.2.2
Click to expand...
Click to collapse
Which image was that?
You can't get write access on the ota that comes with the updater on the shield without modifying the kernel and build.prop.
Hence why they are making a developer image that is prerooted.
jionny said:
Definitely not true I unlocked bootloader and did not use developer image installed magisk, patched and gained full write privileges
Click to expand...
Click to collapse
mLgz0rn said:
On what firmware version?
I doubt you can write to the /system and /data dir if you are on 7.2+.
---------- Post added at 14:37 ---------- Previous post was at 14:31 ----------
Which image was that?
You can't get write access on the ota that comes with the updater on the shield without modifying the kernel and build.prop.
Hence why they are making a developer image that is prerooted.
Click to expand...
Click to collapse
It was the boot.img posted by ACiDxCHRiST in that post : https://forum.xda-developers.com/showpost.php?p=78496132&postcount=163
He has since taken down the boot.img file, but I had saved it in my pc when he posted it. I never flashed it , because I didn't want to brick anything. That is why I had only "fastboot boot boot.img" . Worked fine on 7.2.1 , and then again worked fine on 7.2.2. I haven't tried to root 7.2.3 yet. If you need that exact file to test , I can provide it to you in a few hours when I get back home.
Roamin64 said:
This ^^
I don't understand why so many people say they don't have write privileges. I've not installed TWRP or any other custom recovery, I've simply used ADB to fastboot (boot only , not flashed) with an image that was posted in the magisk thread. Once loaded , I installed Magisk , let it root my shield, used x-plore and verified that I can change permission on any file in the system folder. All my root related functions work without any issue. Shield 2017 with 7.2.2
Click to expand...
Click to collapse
Exactly and I also use x-plore
Roamin64 said:
It was the boot.img posted by ACiDxCHRiST in that post : https://forum.xda-developers.com/showpost.php?p=78496132&postcount=163
He has since taken down the boot.img file, but I had saved it in my pc when he posted it. I never flashed it , because I didn't want to brick anything. That is why I had only "fastboot boot boot.img" . Worked fine on 7.2.1 , and then again worked fine on 7.2.2. I haven't tried to root 7.2.3 yet. If you need that exact file to test , I can provide it to you in a few hours when I get back home.
Click to expand...
Click to collapse
I'm pretty sure that would be the boot.img from the developer build, hence why you can get write access, since it has the modifications needed.
But if you do find it, please share it so I can check .
mLgz0rn said:
I'm pretty sure that would be the boot.img from the developer build, hence why you can get write access, since it has the modifications needed.
But if you do find it, please share it so I can check .
Click to expand...
Click to collapse
That boot.img was patched , most probably by magisk itself. Anyways, sent you the link via PM.
mLgz0rn said:
I'm pretty sure that would be the boot.img from the developer build, hence why you can get write access, since it has the modifications needed.
But if you do find it, please share it so I can check .
Click to expand...
Click to collapse
magisk makes the modifications,, you patch the boot img with magisk then transfer it to your pc then abd fastboot flash boot patched_boot.img... really is that simple.. Has nothing to do with the developers image
Related
It's about time I finally do this. I have 1 question though.
I'm currently on SU2.52, 6.0.0 and I'm updating to SU 2.66 6.0.1. Chainfire mentions that with the newer systemless root we can install it as traditional root instead. I'm just not clear on how and what to do with what he says below...
His full instructions are:
"Notes on 2.62+
A poor man's overlay is used on /system/xbin. We are creating a copy of /system/xbin in /su/xbin_bind, adding a symlink to /su/bin/su there, then mounting the entire thing on top of the original /system/xbin. This is likely to fix some compatibility issues with some apps, without actually modifying /system. Removing /su/xbin_bind and rebooting will disable this feature, or "echo BINDSYSTEMXBIN=false>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash.
If you have one of those devices that refuse to remount system r/w in Android such as the Nexus 6P, but you do want to do this, "echo FSTABSYSTEMRW=true>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash will patch the boot image in such a way that remounting will work. This feature itself breaks OTA compatibility, regardless of if you end up writing to /system or not.
Both of these features are likely temporary.
Notes on 2.64+
There have been a lot of changes to the ZIP installer. Hopefully they won't break a lot of installs. If 2.64 works well, it is likely to be promoted to the "main beta" in place of 2.52, and the How-To SU document will be updated with the relevant information.
A major change in setup is that the ZIP installer will try to detect 6.0 firmwares that can be rooted without doing a systemless install. In other words, a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu").
This may catch (a) firmwares that allow sepolicy reloading from /data but have a locked bootloader and (b) custom firmwares setup to handle this. Regarding the latter, while it is not as clean as systemless, those running custom firmwares are more likely to want to modify /system anyway, it is less likely to mess with updates to those firmwares, and it prevents the necessity of reflashing the ZIP after each kernel switch. Of course, the kernel's SELinux policies must support this! See this thread for details for devs.
Click to expand...
Click to collapse
1.) Can someone rephrase what he said and make it sound a little simpler?
2.) Do I do both of these or one? (I'm flashing 2.66).
echo FSTABSYSTEMRW=true>>/data/.supersu or echo BINDSYSTEMXBIN=false>>/data/.supersu do both or 1?
3.) Should I override this with 6P? "The (2.64+) zip installer will try to detect a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu")."
I have a ton of apps that rely on root so I want to go with the best method that will give me the least compatibility problems. I don't care for android Pay.
Bump please
are you basically saying you want traditional root using 2.66?
Sent from my Nexus 6P using Tapatalk
---------- Post added at 06:02 PM ---------- Previous post was at 06:01 PM ----------
toknitup420 said:
are you basically saying you want traditional root using 2.66?
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
If you want traditional root flash a modified boot.img that will allow traditional root to work. Then flash SuperSU 2.66 and it will automatically install as traditional root.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
are you basically saying you want traditional root using 2.66?
Sent from my Nexus 6P using Tapatalk
---------- Post added at 06:02 PM ---------- Previous post was at 06:01 PM ----------
If you want traditional root flash a modified boot.img that will allow traditional root to work. Then flash SuperSU 2.66 and it will automatically install as traditional root.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Basically I'm trying to decipher what he is saying in his notes I've quoted. There are 3 things he mentions that I could do if I wanted to and I'm asking what those 3 things are (question 2&3 in my op).
I shouldn't need a modified boot for 2.66 and would prefer not to.
JustRootDontCustomRomIt said:
Basically I'm trying to decipher what he is saying in his notes I've quoted. There are 3 things he mentions that I could do if I wanted to and I'm asking what those 3 things are (question 2&3 in my op).
I shouldn't need a modified boot for 2.66 and would prefer not to.
Click to expand...
Click to collapse
You don't need one if you're using systemless root. If you want traditional root then you need modified boot.img or custom kernel.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
You don't need one if you're using systemless root. If you want traditional root then you need modified boot.img or custom kernel.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
JustRootDontCustomRomIt said:
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
Click to expand...
Click to collapse
See the part where he mentions the kernel(boot) se policy, this is what you have to modify for root. So yes. It does require a modified boot to install to system. Which is exactly what is explained in the last 2 paragraphs of that quote. However you can override that and force a systemless install if you desire. See the echo command at the end of the 2nd to last paragraph in quote.
JustRootDontCustomRomIt said:
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
Click to expand...
Click to collapse
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
See the part where he mentions the kernel(boot) se policy, this is what you have to modify for root. So yes. It does require a modified boot to install to system. Which is exactly what is explained in the last 2 paragraphs of that quote. However you can override that and force a systemless install if you desire. See the echo command at the end of the 2nd to last paragraph in quote.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Not saying you're wrong here because I actually don't know but it isn't what I've been reading throughout the forum. Hoping to get a second opinion on this.
JustRootDontCustomRomIt said:
I'm not sure if that's right. I think systemless can be installed into system permanently without boot. The systemless versions patch the boot automatically...
Click to expand...
Click to collapse
You definitely need a modified boot.img for none systemless root that includes a few system checks removed and a sepolicy. I do this myself on every factry imgs because I will never use systemless root is stupid and pointless...So he was dead right for root on 2.66 you need modified boot.img
Tigerstown said:
You definitely need a modified boot.img for none systemless root that includes a few system checks removed and a sepolicy. I do this myself on every factry imgs because I will never use systemless root is stupid and pointless...So he was dead right for root on 2.66 you need modified boot.img
Click to expand...
Click to collapse
Ok. That's a bummer I guess.
Still confusing though because it's the first I hear about this. I could of swore I read that chainfire said the systemless versions will automatically patch boot.. I think I probably misread.
I'm going to sleep right now but could you help me get started? Anything to get me on the right start is appreciated. I know I'll need a modified boot img that works for 6.0.1. you're on 6p right? Because systemless sounds pretty good for me atm. Sounds simpler. It supposedly the same thing as traditional except a very few apps that I hear have compatibility issues. Nothing that can't be fixed with a symlink I believe.
I'm still weighing everything in.
JustRootDontCustomRomIt said:
Ok. That's a bummer I guess.
Still confusing though because it's the first I hear about this. I could of swore I read that chainfire said the systemless versions will automatically patch boot.. I think I probably misread.
I'm going to sleep right now but could you help me get started? Anything to get me on the right start is appreciated. I know I'll need a modified boot img that works for 6.0.1. you're on 6p right? Because systemless sounds pretty good for me atm. Sounds simpler. It supposedly the same thing as traditional except a very few apps that I hear have compatibility issues. Nothing that can't be fixed with a symlink I believe.
I'm still weighing everything in.
Click to expand...
Click to collapse
if you like I can share my modified boot.img I did myself and yes I can help you just PM me. It will only take a few mins. You have working fastboot setup already? It's not the same I don't have time to explain right now tho. If you want help PM me when your ready
Tigerstown said:
if you like I can share my modified boot.img I did myself and yes I can help you just PM me. It will only take a few mins. You have working fastboot setup already? It's not the same I don't have time to explain right now tho. If you want help PM me when your ready
Click to expand...
Click to collapse
Pm you. I have fastboot ready.
JustRootDontCustomRomIt said:
Pm you. I have fastboot ready.
Click to expand...
Click to collapse
I didn't get a Pm. But I'm eating right this minute first you need to flash factory imgs for 6.0.1 via fastboot. Have you don't that before?
Has anyone had any issues trying to flash the latest supersu beta on 7.1.1? I get an abort message whenever I flash
Guitarboarder28 said:
Has anyone had any issues trying to flash the latest supersu beta on 7.1.1? I get an abort message whenever I flash
Click to expand...
Click to collapse
Chainfire has stated before that root with SuperSU on 7.1 may be a while, that he's working on it but a lot has changed (at least I read this all from him on a Pixel related thread...I assume much of it holds true for 7.1 in general).
ohlin5 said:
Chainfire has stated before that root with SuperSU on 7.1 may be a while, that he's working on it but a lot has changed (at least I read this all from him on a Pixel related thread...I assume much of it holds true for 7.1 in general).
Click to expand...
Click to collapse
Oh thanks. I've seen others talk about rooting on 7.1 no problem. I'll have to do more digging I guess
I rooted the 7.1 DP 1 With supersu SR1-v2.78.
No issues at all (even A.R.I.S.E. worked after deleting audio_effects.conf)
Mgrev said:
I rooted the 7.1 DP 1 With supersu SR1-v2.78.
No issues at all (even A.R.I.S.E. worked after deleting audio_effects.conf)
Click to expand...
Click to collapse
Did you root after flashing the ota or full image? I've been trying sr1 and for whatever reason after the ramdisk patch script it fails.
Guitarboarder28 said:
Did you root after flashing the ota or full image? I've been trying sr1 and for whatever reason after the ramdisk patch script it fails.
Click to expand...
Click to collapse
I used Fastboot and flashed every image manually (so that i wouldn't loose data). I used twrp 3.0.2-2 fyi. What about you?
Mgrev said:
I used Fastboot and flashed every image manually (so that i wouldn't loose data). I used twrp 3.0.2-2 fyi. What about you?
Click to expand...
Click to collapse
I was trying after flashing the ota. I even tried the full image without wiping (same version of twrp as you). Something must have just gotten messed up flashing the ota though. I gave up and did a full flash with wipe and sr1 flashed no problem. Thanks for trying to help me out though, I appreciate it
Edit: worded better. @Mgrev no hate was meant, thanks for trying to help me out!
Guitarboarder28 said:
you sound like you need a hug!
Oh thanks. I've seen others talk about rooting on 7.1 no problem. I'll have to do more digging I guess
Click to expand...
Click to collapse
Interesting...maybe he was exclusively referring to the new Pixel partition structure, etc...Not sure. Good luck
I was able to flash SuperSU R1 from TWRP and it worked, but when I added SUHIDE it hangs at boot animation. I flashed the factory image file by file, and not the OTA.
ohlin5 said:
Interesting...maybe he was exclusively referring to the new Pixel partition structure, etc...Not sure. Good luck
Click to expand...
Click to collapse
Yes that's my guess too I'm assuming he's talking about the pixel and it's new partitions
dratsablive said:
I was able to flash SuperSU R1 from TWRP and it worked, but when I added SUHIDE it hangs at boot animation. I flashed the factory image file by file, and not the OTA.
Click to expand...
Click to collapse
oh thanks for the heads up. Who knows if we'll ever see an updated suhide with safetynet checking the bootloader it may never be possible to pass safety net anymore
Guitarboarder28 said:
Yes that's my guess too I'm assuming he's talking about the pixel and it's new partitions
oh thanks for the heads up. Who knows if we'll ever see an updated suhide with safetynet checking the bootloader it may never be possible to pass safety net anymore
Click to expand...
Click to collapse
Well not worried about passing safetynet, since I can do without Android Pay, just want to hide root to play PoGo.
dratsablive said:
Well not worried about passing safetynet, since I can do without Android Pay, just want to hide root to play PoGo.
Click to expand...
Click to collapse
Oh is it no longer using safetynet? There's a new hide method with magisk V8 maybe that'll work
Guitarboarder28 said:
Oh is it no longer using safetynet? There's a new hide method with magisk V8 maybe that'll work
Click to expand...
Click to collapse
Well my bootloader is unlocked, but having suhide installed on the developer preview causes a boot hang. Will have to try the other method out. Thanks.
Guitarboarder28 said:
I was trying after flashing the ota. I even tried the full image without wiping (same version of twrp as you). Something must have just gotten messed up flashing the ota though. I gave up and did a full flash with wipe and sr1 flashed no problem. Thanks for trying to help me out though, I appreciate it
Edit: worded better. @Mgrev no hate was meant, thanks for trying to help me out!
Click to expand...
Click to collapse
I didn't think you meant to express hate either!
I seemed to forget to mention that i backed up my data with titanium backup, flashed, then wiped, and then restored it. So in the end, you probably need to wipe (just like you did)
dratsablive said:
Well my bootloader is unlocked, but having suhide installed on the developer preview causes a boot hang. Will have to try the other method out. Thanks.
Click to expand...
Click to collapse
Magisk hide just hides Magisk itself... it doesn't do anything for root. As for PoGo, right now the only way to do that on 7.1.1 is to NOT be rooted.
Once the kernel sources for the 7.1.1 are released, this patch will make its way onto custom kernels, which means you'll still be able to edit /system while rooted, unroot, and keep the changes via the patched kernel, as well as bypassing the SafetyNet bootloader check.
A kernel does exist now with that patch (francokernel), but it is based on the 7.0 kernel sources, so some things are broken if used on 7.1.1.
In re: to the superSU ramdisk install failure, this will happen if there are old files left over in /data from a previous magisk install and/or patched boot images. The SuperSU installer script will detect those and step into code branches that it doesn't need to be in, and thus fail. The solution is deleting the offending files from TWRP w/ adb, and installing SuperSU zip again.
/thread
Thread cleaned a bit, please stay on topic.
Have a good day!
Forum moderator,
Matt
Works fine for me flashed 7.1.1 OTA then flashed SuperSU zip
I have a simple question why don't I just follow the nvidia developer guide to root my shield instead of any of these third party solutions?
Also, how do I get
Code:
su
on my shield rooted from nvidia since they state their image does not come with it... is that why we need third party solutions for root?
Anyone know this? I thought it's pretty simple question
[email protected] said:
Anyone know this? I thought it's pretty simple question
Click to expand...
Click to collapse
I have a 2015 pro. I have always been rooted since Nougat... I just upgraded to 7.2.2 following nvidia guide for the developer pro image then I Patched boot.img with Magisk,, went flawlessly
jionny said:
I have a 2015 pro. I have always been rooted since Nougat... I just upgraded to 7.2.2 following nvidia guide for the developer pro image then I Patched boot.img with Magisk,, went flawlessly
Click to expand...
Click to collapse
thanks but not sure that answered my question, why did you need to patch boot.img instead of stay with pro image that is rooted?
Also what guide did you follow to patch boot.img?
[email protected] said:
thanks but not sure that answered my question, why did you need to patch boot.img instead of stay with pro image that is rooted?
Also what guide did you follow to patch boot.img?
Click to expand...
Click to collapse
You have to patch boot.img using Magisk Manager, Pro image is rooted but not su and after I upgraded to 7.2 I had problems with root and found for me Magisk was the easiest solution besides I wanted youtube Vanced.
I have the Pro version if you have the 2017 16 gb I believe its a different procedure for Magisk. However there is a guide located in this forum just search for it. For Pro version
Install Magisk Manager on shield
You need to extract the boot.img from the 7.22 zip put it somewhere easy u can find
open Magisk manager click install, click patch boot image
Transfer the patched boot.img to your pc
adb reboot bootloader
fastboot devices
fastboot flash boot patched_boot.img
Then reboot and shield is rooted with Magisk
Like I said there is a more detailed guide on here just search for it
I still do not think you answered the OP question. If the developer images are pre-rooted and no NOT include the SU binary, why not just flash the developer image and then fastboot boot twrp and install a supersu.zip or magiskroot.zip (I do not know what the su binary flashable zip files are called) and be done with it?
I think like the OP its a simple question that hasn't been answered yet. @jionny, I appreciate what you have done and I'm glad it worked for you, but it doesn't address the substance of the OP question. Why do even have to jump through those hoops vs. just "installing" a SU binary after flashing developer image.... konfused i am also.
Sammy4Life said:
I still do not think you answered the OP question. If the developer images are pre-rooted and no NOT include the SU binary, why not just flash the developer image and then fastboot boot twrp and install a supersu.zip or magiskroot.zip (I do not know what the su binary flashable zip files are called) and be done with it?
I think like the OP its a simple question that hasn't been answered yet. @jionny, I appreciate what you have done and I'm glad it worked for you, but it doesn't address the substance of the OP question. Why do even have to jump through those hoops vs. just "installing" a SU binary after flashing developer image.... konfused i am also.
Click to expand...
Click to collapse
You cant use twrp with 7.2.2, I replied I had problems with rooting with su which is my preferred method after 7.1,, this is why I started using Magisk to root
I have the same question.
Hi, just got around to rooting my Kindle. Currently using SuperSu, curious if anyone has used Magisk with this tablet? Any reason not to do so?.
Thanks in advance.
I've debated doing this as well, as I don't like having to default grant everything root access.
As far as I understand though, none of your root apps/su requests can modify the system partition, so I haven't tried it yet.
@diplomatic is this true for the bootless root method without dm-verity?
No, you can modify /system if there's no dm-verity, @Kctucka
diplomatic said:
No, you can modify /system if there's no dm-verity, @Kctucka
Click to expand...
Click to collapse
Oh wow that's pretty awesome.
Sounds like there's no downside to Magisk on the 2017 HD 8 then.
Kctucka said:
Oh wow that's pretty awesome.
Sounds like there's no downside to Magisk on the 2017 HD 8 then.
Click to expand...
Click to collapse
Thanks, guys!
SuperSU access workaround
Kctucka said:
I've debated doing this as well, as I don't like having to default grant everything root access.
.....
Click to expand...
Click to collapse
There is a SuperSU access workaround without having to default grant everything root access:
https://forum.xda-developers.com/hd8-hd10/general/supersu-access-workaround-fire-devices-t3738269
Maybe I am mistaken, but how does one install Magisk on 2017 HD8 without TWRP ?
Dan_firehd said:
There is a SuperSU access workaround without having to default grant everything root access:
https://forum.xda-developers.com/hd8-hd10/general/supersu-access-workaround-fire-devices-t3738269
Maybe I am mistaken, but how does one install Magisk on 2017 HD8 without TWRP ?
Click to expand...
Click to collapse
Yeah I've seen that method, but didn't wanna redo it for every root app I add.
And this is the Bootless Root Magisk method:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
I think I'm gonna try this method when I get some free time.
Kctucka said:
Yeah I've seen that method, but didn't wanna redo it for every root app I add.
And this is the Bootless Root Magisk method:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
I think I'm gonna try this method when I get some free time.
Click to expand...
Click to collapse
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
koop1955 said:
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
Click to expand...
Click to collapse
Yeah will do! I'll probably try it tomorrow or the day after.
koop1955 said:
@Kctucka would you let me know if that method works for you? I tried grabbing the stock boot image and modifying it with the latest version of Magisk, Could not get that to work either via ADB or Flashify because of the locked bootloader - stupid of me not to realize that from the start. I let my excitement get the best of me.
I am out of time today, but it seems like a modified BIN file might be an option.
Click to expand...
Click to collapse
Ok so I successfully have Magisk working, and have been playing around with it for a bit now. I am running the latest version of Magisk Manager. To get it up and running, I chose the option in SuperSu to clean up binaries for different su method.
So far, all of my root apps detect root, except for titanium backup. I've messed around with it for a bit but haven't been able to figure it out. I'm guessing it has something to do with the location of the su binaries.
Also of note, FlashFire did not work at first. I realized that this is because the timebomb method we used along with the older app version, was from before Magisk existed. I grabbed the latest version of FlashFire from apk mirror, and it started without issues. I haven't tested by flashing anything yet though.
Lastly, the one minor inconvenience is that my kernel tweaks I enable at boot, do not work, as there is no root at boot. So I have to manually add zram every reboot. Perhaps there's a better way to do this.
All in all, this is a pretty solid root method, but obviously non ideal due to the locked bootloader.
I've also not tested how easy it is to switch back to SuperSu if desired, but I assume it's as simple as disabling the start up script, and updating su binaries in SuperSu.
@diplomatic is this the case? Or would you also need to delete the created files in the data partition? Thanks again for the awesome method!
Kctucka said:
Ok so I successfully have Magisk working, and have been playing around with it for a bit now. I am running the latest version of Magisk Manager. To get it up and running, I chose the option in SuperSu to clean up binaries for different su method.
Click to expand...
Click to collapse
Was that all that you did? That option and then install? And how did you change the time in your Kindle to get Flashify to work or just the latest APK?
And thanks for everything! Getting back into this after so long I feel like a n00b again.
koop1955 said:
Was that all that you did? That option and then install? And how did you change the time in your Kindle to get Flashify to work or just the latest APK?
And thanks for everything! Getting back into thhis after so long I feel like a n00b again.
Click to expand...
Click to collapse
That option was all I did to remove SuperSu. Then I followed the instructions here:
https://forum.xda-developers.com/showpost.php?p=79626434&postcount=135
Didn't take long to get it working.
And the time change was to get the version of FlashFire working that was compatible with the version of SuperSu we could run. See this post for more info if you're curious:
https://forum.xda-developers.com/hd8-hd10/general/hd-10-2017-xposed-t3722252
But with this new method, the most recent version of FlashFire works, as it's compatible with Magisk. The older version of FlashFire I had is not.
Also, I'm a noob myself. That's why I tagged diplomatic again, to correct the dumb things I might have said
Well, I am busy adding to your "Thanks" quotient, something seems to have fallen by the wayside today. Glad t have you around.
I think ultimately we are going to end up with a custom BIN file with Magisk and Xposed integrated.
Cheers.
koop1955 said:
Well, I am busy adding to your "Thanks" quotient, something seems to have fallen by the wayside today. Glad t have you around.
I think ultimately we are going to end up with a custom BIN file with Magisk and Xposed integrated.
Cheers.
Click to expand...
Click to collapse
That's awesome! Would that pass signature verification? Or would it be through hacked fastboot?
Also, that'd make it much easier to set up the device after a softbrick. FlashFire would be good to flash backups right away.
Kctucka said:
.....
Lastly, the one minor inconvenience is that my kernel tweaks I enable at boot, do not work, as there is no root at boot. So I have to manually add zram every reboot. Perhaps there's a better way to do this.
.....
Click to expand...
Click to collapse
Would you please let us know how did you do your "kernel tweaks" to add zram for a rooted 2017 HD8?
Thanks.
Dan_firehd said:
Would you please let us know how did you do your "kernel tweaks" to add zram for a rooted 2017 HD8?
Thanks.
Click to expand...
Click to collapse
My kernel tweaks were done with KA Mod Reborn, using the "apply on boot" setting:
https://forum.xda-developers.com/android/apps-games/approot4-0-ka-mod-reborn-v18-t3714105
I added 260 MB ZRAM with a swapiness of 10. You can also tweak low memory killer, laptop mode, and a whole bunch of other dials that I don't mess with as I don't fully understand what they do.
Kernel changes could also be done with a number of different apps that do similar things.
Unfortunately, the bootless root method doesn't give root on boot, so it and also most Magisk modules won't work. Can't think of a workaround currently.
Kctucka said:
I've also not tested how easy it is to switch back to SuperSu if desired, but I assume it's as simple as disabling the start up script, and updating su binaries in SuperSu.
@diplomatic is this the case? Or would you also need to delete the created files in the data partition? Thanks again for the awesome method!
Click to expand...
Click to collapse
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
diplomatic said:
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
Click to expand...
Click to collapse
That's super beneficial then, you can swap back and forth easily depending on what you need.
diplomatic said:
Yeah, pretty much. The activation of root depends only the init.d app running the script. The su binaries don't really exist in storage. You can delete all the stuff under /data/adb if you want to wipe everything Magisk. In theory, it should be possible to install Magisk on the system partition. It probably doesn't support that method officially anymore. But if the bootless method works, then a similar script can be added to /system....
Click to expand...
Click to collapse
How about just swapping the install-recovery.sh script for suboot.sh on devices that don't have dm-verity?
I think that's pretty much what SuperSU does as well.
That would give root much earlier during boot and not depend on the extra App.
Probably doesn't even need to run mtk-su each boot then either.
Yeah, that's on the right track, @k4y0z. What you can probably use is a modified SU_MINISCRIPT section of suboot.sh, at least as a starting point. That is the code that needs to be run as root. What should be changed is the path to the magiskinit & magisk binaries. Those could be placed somewhere on /system. You would only need mtk-su if selinux needs to be permissive. But I suspect it does for the 'magiskpolicy --live' call. (But then how does SuperSU handle it with enforcing?)
I just wanted to say that root is possible with the magisk/patch boot.img method. I am currently running the latest Oct. 011.C4 image with root. Titanium Backup is restoring as we speak...
dethknite said:
I just wanted to say that root is possible with the magisk/patch boot.img method. I am currently running the latest Oct. 011.C1 image with root. Titanium Backup is restoring as we speak...
Click to expand...
Click to collapse
Mind sharing your extracted boot.img?
dethknite said:
I just wanted to say that root is possible with the magisk/patch boot.img method. I am currently running the latest Oct. 011.C1 image with root. Titanium Backup is restoring as we speak...
Click to expand...
Click to collapse
I can confirm, root working on my Pixel 4. Used the same method as with the Pixel 3 on Android 10, Magisk patched the boot img, then fastboot flash. I used the canary channel of magisk.
(Link for the factory images)
https://developers.google.com/android/images
---------- Post added at 09:14 PM ---------- Previous post was at 09:03 PM ----------
Shponglized said:
Mind sharing your extracted boot.img?
Click to expand...
Click to collapse
PM sent.
dethknite said:
I just wanted to say that root is possible with the magisk/patch boot.img method. I am currently running the latest Oct. 011.C1 image with root. Titanium Backup is restoring as we speak...
Click to expand...
Click to collapse
Have you got any magisk modules working? If so, which ones?
I tried to root my Pixel 4 using the Pixel 3 method but no luck. Pulled the boot.img from "10.0.0 (QD1A.190821.011.C4, Oct 2019)" for "flame" for Pixel 4. I used the Canary Magisk Manager and patched the boot imaged.
Got this error when trying to flash from ABD.
FAIL (remote: Failed to write to partition Not Found)
Anyone one else successful?
inclusive said:
I tried to root my Pixel 4 using the Pixel 3 method but no luck. Pulled the boot.img from "10.0.0 (QD1A.190821.011.C4, Oct 2019)" for "flame" for Pixel 4. I used the Canary Magisk Manager and patched the boot imaged.
Got this error when trying to flash from ABD.
FAIL (remote: Failed to write to partition Not Found)
Anyone one else successful?
Click to expand...
Click to collapse
You have to flash with fastboot, not adb
Sent from my Pixel 4 using Tapatalk
ajrty33 said:
You have to flash with fastboot, not adb
Sent from my Pixel 4 using Tapatalk
Click to expand...
Click to collapse
I was using ABD with fastboot but was getting that error. Redownloaded to a newer version and was able to root successfully. Now, just to get adaway to work. Thank you
How do I know which system image I should download?
Thanks dude! I just succeed to root my Pixel 4, too!
marc.ientilucci said:
How do I know which system image I should download?
Click to expand...
Click to collapse
Check your current build number under About Phone.
Oh yes..... Best news I've heard so far today.
I'm doing this right now!
cntryby429 said:
Check your current build number under About Phone.
Click to expand...
Click to collapse
What about for future updates?
marc.ientilucci said:
What about for future updates?
Click to expand...
Click to collapse
I'm not entirely sure. I came from the Pixel 2 and, as I recall, anytime there were multiple releases of a monthly patch they would have one generic image and one or more labeled for specific carriers. For example:
9.0.0 (PPR1.180610.009, Aug 2018)
9.0.0 (PPR1.180610.011, Aug 2018, Telstra)
I wonder if this will get corrected or if future patches will be named more clearly.
marc.ientilucci said:
How do I know which system image I should download?
Click to expand...
Click to collapse
I recommend flashing the updated Oct. image (without -w) and then subsequently using its boot image... that is what I am on.
10.0.0 (QD1A.190821.011.C4, Oct 2019)
KHANrad_SIN said:
Have you got any magisk modules working? If so, which ones?
Click to expand...
Click to collapse
I have several modules running--all of the same as my P3 (except edxposed). Even have Viper4Android running using the same AML hack for Android 10.
Noob question, but if I unlock the bootloader and root the device. Do I still get the lastest updates from google?
Vedrick said:
Noob question, but if I unlock the bootloader and root the device. Do I still get the lastest updates from google?
Click to expand...
Click to collapse
Yes. An unlocked bootloader itself won't break OTAs. Being rooted (requiring an unlocked bootloader) requires re-rooting after an OTA since the boot.img is overwritten. Having a custom recovery (not yet available for the Pixel 4) will preclude you from taking an OTA (from within the os, see below).
You can always flash the flashall.bat from the system image using fastboot for a clean install or an edited version of flashall.bat (removing the "-w") to effectively OTA and preserve your data.
what does it exactly mean to patch the bootimage, i want to root my phone because there a few google apps that I really have no need for. Especially considering the limited space on my 64gb model, wanna get rid of all the crap
KHANrad_SIN said:
Have you got any magisk modules working? If so, which ones?
Click to expand...
Click to collapse
KHANrad_SIN said:
Have you got any magisk modules working? If so, which ones?
Click to expand...
Click to collapse
For anyone who is curious, I went ahead and tried some modules myself. I'll list the ones I tried and whether they worked or not.
Viper4Android FX (working)
- so I got this to work, but in order to do so I believe you need to also install AML (Audio Modification Library) and reboot a few times after opening the V4A app and installing the driver, I don't know the exact method I just played around with it until it worked.
Ainur Sauron (working)
- I installed this along with V4A and it seems to be working
AML (Audio modification Library) (working)
- This needs to be installed in order to allow Ainur Sauron and V4A to work in conjunction
- It also needs to be installed for V4A to work in general on Android 10
Youtube Vanced (not the black themed one) (working)
- this was also kind of finicky, I had to install the module, then reboot, go to the settings app --> apps & notifications --> see all apps --> youtube --> disable/uninstall --> re-enable it, then reboot, then uninstall the youtube vanced module, reboot again, then go back to settings and uninstall the youtube app, now finally reinstall the youtube vanced module and reboot
- not entirely sure if all these steps need to be done to get it to work but that's what I did
Active Edge Mod for Pixel devices (was not working before, but is now currently working)
- the official changelog says support was added for the Pixel 4 XL so I figured I would give it a shot out of curiosity
- I tried it and it soft bricked my pixel 4, it got stuck on the "pixel is starting" animation and then I tried to reboot but every time it did it would just go to a black screen after the G logo
- Even doing a clean flash of the factory image didn't get rid of it
- I manged to fix it by relocking and then unlocking the bootloader again
- I have provided the developer with the necessary files to support our devices though and he said he is working on it
- UPDATE: As of October 25th 4:31AM PST he has now updated the module to be compatible with the smaller Pixel 4 and I can confirm it is working
Substratum Lite (some working)
- I only installed the Swift Dark substratum theme
- I also only tried it on a few apps like instagram, snapchat, maps, google play music, and google home
- I have not tried it on the other apps/elements like system UI or any other app so I can't really confirm if those work or not, but I can at least say some apps can be overlayed
Remember YMMV, and I am not responsible for your device getting bricked lol
ahsank128 said:
what does it exactly mean to patch the bootimage, i want to root my phone because there a few google apps that I really have no need for. Especially considering the limited space on my 64gb model, wanna get rid of all the crap
Click to expand...
Click to collapse
Magisk is the current root method. You download Magisk Manager and from within its UI you provide it the stock boot.img and it'll spit out a patched version that you can then flash to the boot partition using fastboot.
Magisk Manager + flashing the Magisk-patched boot.img = root access