Question about Root - Nexus 6P Q&A, Help & Troubleshooting

This week I should be getting my new Nexus 6P.
Accomplish - I want to accomplish the list below and still get Android Pay to work
- Root
- Change Kernel (probably Franeco)
- Install Ad Blocker
- Android Pay Works
- I don't really need customer recovery unless its required
Next steps - is it as easy as systemless root and leaving the boot loader unlocked?

roaddaw9 said:
This week I should be getting my new Nexus 6P.
Accomplish - I want to accomplish the list below and still get Android Pay to work
- Root
- Change Kernel (probably Franeco)
- Install Ad Blocker
- Android Pay Works
- I don't really need customer recovery unless its required
Next steps - is it as easy as systemless root and leaving the boot loader unlocked?
Click to expand...
Click to collapse
Android Pay will only work if your /system partition is completely unmodified. Ad blockers modify the /system partition so you won't be able to use those if you want to use Android Pay. The bootloader status has no effect on Android Pay so you can leave that unlocked. Custom recovery is required to flash SuperSU to get root. If you need instrutions I have a guide here:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928

Heisenberg said:
Android Pay will only work if your /system partition is completely unmodified. Ad blockers modify the /system partition so you won't be able to use those if you want to use Android Pay. The bootloader status has no effect on Android Pay so you can leave that unlocked. Custom recovery is required to flash SuperSU to get root. If you need instrutions I have a guide here:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Click to expand...
Click to collapse
Can you modify the kernel or does that get flagged to?
Sent from my XT1575 using Tapatalk

roaddaw9 said:
Can you modify the kernel or does that get flagged to?
Sent from my XT1575 using Tapatalk
Click to expand...
Click to collapse
Kernel is fine I believe.

Heisenberg said:
Android Pay will only work if your /system partition is completely unmodified. Ad blockers modify the /system partition so you won't be able to use those if you want to use Android Pay. The bootloader status has no effect on Android Pay so you can leave that unlocked. Custom recovery is required to flash SuperSU to get root. If you need instrutions I have a guide here:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Click to expand...
Click to collapse
That is not true.
You can have Ad Blockers.
The hosts file and route tables are not checked so an Ad Blocker is fine.

tech_head said:
That is not true.
You can have Ad Blockers.
The hosts file and route tables are not checked so an Ad Blocker is fine.
Click to expand...
Click to collapse
Good to know, cheers.

Related

My 6P is still on 6.0.0 (Oct. build) because instructions not clear. Question about i

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?

Stock Recovery missing

Hey XDA,
My Nexus ha been a dream. Though I've hit a few bumps, I don't expect to waste money on other flagships again.
I don't need to be able to right this instant, but wiping cache is one of my regular troubleshooting tools. Upon troubleshooting an MMS issue I was having, I discovered my recovery wasn't working properly. Though I fixed the MMS issue by resetting APN settings, the recovery thing has been bothering me.
I am running stock and locked. I have done nothing to this phone to warrant it being my fault. The problem is simple (and a Google search indicated, common). When you get to Recovery, you get a droid on its back, a red exclamation mark and "NO COMMAND". Doesn't matter if you hold up and power, tap up, or get there from the bootloader. The recovery software is seemingly missing completely.
I have an extended warranty through the retailer I bought from, but the phone is otherwise fine, so this is a last resort.
My dilemma is that I want to use Android pay. My understanding is that even unlocking the bootloader breaks Android pay. Is this correct? If so, can one reliably reset the phones security trips to allow Android pay after flashing the recovery back on?
Thanks for the help.
No, unlocking the boot loader does not block Android Pay.
There is a systemless root method for the Nexus that allows you to use Android Pay while rooted, there are also a couple of ROMS that have it working currently as well.
celsian said:
No, unlocking the boot loader does not block Android Pay.
There is a systemless root method for the Nexus that allows you to use Android Pay while rooted, there are also a couple of ROMS that have it working currently as well.
Click to expand...
Click to collapse
Quite so? Can you provide links to the root method and mayhaps the roms? Does this mean I could slap TWRP on here with no consequence?
Android pay already patched systemless root. If you want Android pay don't root. You can unlock though. That will not affect Android pay.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
Android pay already patched systemless root. If you want Android pay don't root. You can unlock though. That will not affect Android pay.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Does this mean that I can't flash at least a stock recovery?
Download your system image, unzip it, unlock your bootloader and flash only the recovery.IMG in fastboot, then relock your bootloader again. Android Pay will work fine and your warranty won't be affected so long as you relock your bootloader
Arcaed said:
Does this mean that I can't flash at least a stock recovery?
Click to expand...
Click to collapse
Yes. Myself I would flash full image and start over fresh. But you can go with just recovery if you want. Also do not forget to check allow oem unlock in dev settings before attempting to unlock. If you want twrp you will need modified stock boot image with DM verity removed. Or else it won't boot. I can link you to one from the newest image if you'd like. But if you only want stock recovery you don't need anything other than stock Google image.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
Yes. Myself I would flash full image and start over fresh. But you can go with just recovery if you want. Also do not forget to check allow oem unlock in dev settings before attempting to unlock. If you want twrp you will need modified stock boot image with DM verity removed. Or else it won't boot. I can link you to one from the newest image if you'd like. But if you only want stock recovery you don't need anything other than stock Google image.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Sorry, but are you saying if I wanted to install twrp I would need a modified stock boot img?
The Stig 04 said:
Sorry, but are you saying if I wanted to install twrp I would need a modified stock boot img?
Click to expand...
Click to collapse
Yes.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
Yes. Myself I would flash full image and start over fresh. But you can go with just recovery if you want. Also do not forget to check allow oem unlock in dev settings before attempting to unlock. If you want twrp you will need modified stock boot image with DM verity removed. Or else it won't boot. I can link you to one from the newest image if you'd like. But if you only want stock recovery you don't need anything other than stock Google image.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
In that case, where do I get a full system flash?
Arcaed said:
In that case, where do I get a full system flash?
Click to expand...
Click to collapse
https://developers.google.com/android/nexus/images
Sent from my Nexus 6P using Tapatalk
There are quite a few errors in the information given in this thread.
1. Unlocking the bootloader does not break Android Pay.
2. Android Pay has been patched so you can't have root with Android Pay, even systemless.
3. TWRP recovery does not require a modified boot.img.
4. Flashing any recovery (Stock or TWRP) will not affect Android Pay at all.
If you need directions on unlocking or flashing check my guide:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Heisenberg said:
There are quite a few errors in the information given in this thread.
1. Unlocking the bootloader does not break Android Pay.
2. Android Pay has been patched so you can't have root with Android Pay, even systemless.
3. TWRP recovery does not require a modified boot.img.
4. Flashing any recovery (Stock or TWRP) will not affect Android Pay at all.
If you need directions on unlocking or flashing check my guide:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Click to expand...
Click to collapse
You beat me to it with #3. Unfortunately I'm at work and couldn't come back to this thread quickly enough.
toknitup420 said:
Android pay already patched systemless root. If you want Android pay don't root. You can unlock though. That will not affect Android pay.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
Actually AP now works with systemless root again. I have AP working (yes actually making purchases), currently running the latest Chroma Rom with Supersu 2.61
Found the workaround in this thread.
I'm sure Google will patch it again though.
Arcaed said:
Quite so? Can you provide links to the root method and mayhaps the roms? Does this mean I could slap TWRP on here with no consequence?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=65188325
Heisenberg said:
There are quite a few errors in the information given in this thread.
1. Unlocking the bootloader does not break Android Pay.
2. Android Pay has been patched so you can't have root with Android Pay, even systemless.
3. TWRP recovery does not require a modified boot.img.
4. Flashing any recovery (Stock or TWRP) will not affect Android Pay at all.
If you need directions on unlocking or flashing check my guide:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Click to expand...
Click to collapse
I've always been under the impression that the device will not boot with twrp installed unless you have DM verity checks removed. Has something changed with that.
Sent from my Nexus 6P using Tapatalk
toknitup420 said:
I've always been under the impression that the device will not boot with twrp installed unless you have DM verity checks removed. Has something changed with that.
Sent from my Nexus 6P using Tapatalk
Click to expand...
Click to collapse
It isn't necessary. I'm on my eighth Nexus 6P and I haven't flashed any modified boot.img prior to flashing TWRP.
83097markcynt said:
Actually AP now works with systemless root again. I have AP working (yes actually making purchases), currently running the latest Chroma Rom with Supersu 2.61
Found the workaround in this thread.
I'm sure Google will patch it again though.
Click to expand...
Click to collapse
I can second this. I have systemless root, and AP working, confirmed with purchases. Just a note, if you can successfully add a card, that means it has to contact your bank for approval, therefore it should confirm AP is working.

Temporary root + Android Pay?

I'm trying to find out if there's a possible temporary root solution where I can use it for what I need, and it not affect Android Pay.
Is this possible?
flash supersu 2.68 then use like root explorer to delete /su/xbin_bind and set /su/bin permissions to 751
thepoetlives89 said:
flash supersu 2.68 then use like root explorer to delete /su/xbin_bind and set /su/bin permissions to 751
Click to expand...
Click to collapse
thanks for the quick reply; what does this do?
incarceration said:
thanks for the quick reply; what does this do?
Click to expand...
Click to collapse
i believe the safety net looks at /su/bin and if it can execute then it fails. when you change the permissions it cannot execute on the folder so it passes.
so currently my device is completely stock. haven't unlocked the bootloader, flashed a custom recovery, ROM, or rooted.
to do this, i would have to unlock the bootloader and flash a custom recovery, then SU 2.68, correct?
what about any newer version instead? like 2.70 rc?
incarceration said:
so currently my device is completely stock. haven't unlocked the bootloader, flashed a custom recovery, ROM, or rooted.
to do this, i would have to unlock the bootloader and flash a custom recovery, then SU 2.68, correct?
what about any newer version instead? like 2.70 rc?
Click to expand...
Click to collapse
That's correct, you need to unlock your bootloader and flash TWRP first. Instructions in my guide:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Just use SuperSU 2.68, any higher versions are a WIP for Android N.
Heisenberg said:
That's correct, you need to unlock your bootloader and flash TWRP first. Instructions in my guide:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Just use SuperSU 2.68, any higher versions are a WIP for Android N.
Click to expand...
Click to collapse
awesome, thanks!
Heisenberg said:
That's correct, you need to unlock your bootloader and flash TWRP first. Instructions in my guide:
http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928
Just use SuperSU 2.68, any higher versions are a WIP for Android N.
Click to expand...
Click to collapse
can you confirm i will NOT lose Android Pay functionality? Android Pay functionality is the only reason I have not unlocked\rooted this device (despite all of my previous Android devices)
incarceration said:
can you confirm i will NOT lose Android Pay functionality? Android Pay functionality is the only reason I have not unlocked\rooted this device (despite all of my previous Android devices)
Click to expand...
Click to collapse
I don't use Android Pay so I can't really confirm anything personally. There's a thread discussing root and Android Pay in the general section though, take a look there.
incarceration said:
can you confirm i will NOT lose Android Pay functionality? Android Pay functionality is the only reason I have not unlocked\rooted this device (despite all of my previous Android devices)
Click to expand...
Click to collapse
Yes it works i used it not even an hour ago. just don't install anything like xposed. xposed will break the safety net. Use this to check.
thepoetlives89 said:
Yes it works i used it not even an hour ago. just don't install anything like xposed. xposed will break the safety net. Use this to check.
Click to expand...
Click to collapse
thanks

can't update to marshmallow

Hello friends
My phone is HTC One m8w
There isn't "update" in
Setting
About
Android version,
5.0.1
Software number
1.0.0.m8w
Build number
4.19.1402.15 CL458284 release-keys
Please help me for this problem
How can I update my phone?
Thanks a lot
Hello, I experienced something similar- complete absence of system update! A little digging revealed that any modifications to the system partition would render the device un-updateable, so naturally I downloaded the complete marshmallow package update for my device, booted into standard recovery, and updated from sd card
Hope this helps
Ta3miyyasandwich said:
Hello, I experienced something similar- complete absence of system update! A little digging revealed that any modifications to the system partition would render the device un-updateable, so naturally I downloaded the complete marshmallow package update for my device, booted into standard recovery, and updated from sd card
Hope this helps
Click to expand...
Click to collapse
There isn't any update for my build number
Sent from my HTC_M9pw using Tapatalk
if you are willing to, just root your phone and flash the marshmallow rom on to your phone and use titanium backup to backup everything before you do so.
you can root your phone,flash twrp recovery,flash Marshmallow rom.
lmentor said:
you can root your phone,flash twrp recovery,flash Marshmallow rom.
Click to expand...
Click to collapse
That's exactly what I just said
justinchao740 said:
if you are willing to, just root your phone and flash the marshmallow rom on to your phone
Click to expand...
Click to collapse
You don't need root to install TWRP, nor to install a custom ROM.
Exception is Verizon, where you need root to s-off, and then unlock bootloader; as bootloader unlock by HTCDev.com is not supported for that version alone.
redpoint73 said:
You don't need root to install TWRP, nor to install a custom ROM.
Exception is Verizon, where you need root to s-off, and then unlock bootloader; as bootloader unlock by HTCDev.com is not supported for that version alone.
Click to expand...
Click to collapse
If you get bootloader unlocked, you basically rooted your device cause now you are allowed to modify the system data and make modification that can result in unusable phone. Plus if you are willing to take the risk of unlocking your bootloader, why don't you just root anyways, its just a matter of flashing super su zip.
justinchao740 said:
If you get bootloader unlocked, you basically rooted your device cause now you are allowed to modify the system data and make modification that can result in unusable phone .
Click to expand...
Click to collapse
No, you didn't. Root is a very specific thing. You either have root (SU) priviledge, or you don't. Unlocked bootloader does not give you root privilege. It only allows you to flash unsigned zips to certain partitions.
justinchao740 said:
Plus if you are willing to take the risk of unlocking your bootloader, why don't you just root anyways, its just a matter of flashing super su zip.
Click to expand...
Click to collapse
Because it would be a wasted step (completely unnecessary), if you are going to flash a custom ROM.
redpoint73 said:
No, you didn't. Root is a very specific thing. You either have root (SU) priviledge, or you don't. Unlocked bootloader does not give you root privilege. It only allows you to flash unsigned zips to certain partitions.
Because it would be a wasted step (completely unnecessary), if you are going to flash a custom ROM.
Click to expand...
Click to collapse
Think of it this way. If you flashed a cm ROM without root in the first place, you would get root. I'm not saying unlocking bootloader immediately give you root access but it allows almost anything that you flash to have root access
justinchao740 said:
Think of it this way. If you flashed a cm ROM without root in the first place, you would get root. I'm not saying unlocking bootloader immediately give you root access but it allows almost anything that you flash to have root access
Click to expand...
Click to collapse
Some folks keep incorrectly stating that you need root to flash custom recovery on this device (on some devices, you do - but not this one). I'm just trying to make sure that misinformation doesn't keep getting conveyed (the post after yours said it, too).
Stating the process precisely, is the best way to do that.
redpoint73 said:
Some folks keep incorrectly stating that you need root to flash custom recovery on this device (on some devices, you do - but not this one). I'm just trying to make sure that misinformation doesn't keep getting conveyed (the post after yours said it, too).
Stating the process precisely, is the best way to do that.
Click to expand...
Click to collapse
Agreed plus my post never stated anything about rooting.
justinchao740 said:
Agreed plus my post never stated anything about rooting.
Click to expand...
Click to collapse
While my intent is not to be the guy that always has the last word; I also can't let you state a complete falsehood.
justinchao740 said:
if you are willing to, just root your phone and flash the marshmallow rom
Click to expand...
Click to collapse

Anyone tried Magisk HD8 7th Gen?

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?)

Categories

Resources