I'm not responsible for anything blah blah
This is intended to disable forced encryption on the nexus 6. You can still encrypt the device after doing this, but it won't be automatically done.
After observing how this force encryption stuff works, I got it mostly figured out. (It's entirely a SW layer, as is already widely known). Basically when all the devices from fstab are mounted in android with the forceencrypt option, fs_mgr sets a flag for encryption (something like IF This_Device_Isnt_Encrypted; then This_Device_Needs_Encryption). on devices (looks like android only allows you to encrypt 1 device, which is probably to prevent such cases as over-resource usage ,maybe some other conflict that it doesn't support over 1 device, idk) that have forceencrypt set on them, if it can't unmount the device before doing these encryption checks - in other words if it's usy (like a file is open) - it just skips encryption all together. So if the device had a file preventing it from being unmounted, it just says "oh well, skip encryption." I found this kinda odd behavior anyway
You can still encrypt the device, it just isn't forced. Some people are complaining about the slowness of the encryption SW-layer (why force SW encryption? At least put some HW for it in the device). This makes it the way it probably should be - optional.
Stock LMY47D/LMY47E/LMY47M/LMY47I (5.1.0) - No force encrypt:
https://www.androidfilehost.com/?fid=95916177934540533
Stock LRX22C (5.0.1) - No force encrypt:
https://www.androidfilehost.com/?fid=95857557620392411
Stock LRX21O (5.0) - No force encrypt:
https://www.androidfilehost.com/?fid=95784891001613336
Prerequisites:
- You should be running the same build as the kernel you install (E.G. if you are running 5.1.0 LMY47D you should install the LM47D no force encrypt kernel)
- Your bootloader must be unlocked (fastboot oem unlock)
How-to install kernel:
1.) Reboot to boot loader
2.) Download the appropriate boot.img above
3.) Install it via fastboot (fastboot flash boot boot_noforceencrypt.img)
To disable forced encryption after kernel is installed:
1.) Reboot to boot loader
2.) Format userdata (fastboot format userdata) - This will erase all of your data (apps, sd card, etc.) - so make appropriate backups
Look who's back!! ?
Awesome work man... I'll be testing as soon as my whale arrives tomorrow.
*Also, hit me up on Hangouts... I might have something you'd be interested in. Mike is in, come December I think... Could be fun.
jjhiza said:
Look who's back!! ?
Awesome work man... I'll be testing as soon as my whale arrives tomorrow.
*Also, hit me up on Hangouts... I might have something you'd be interested in. Mike is in, come December I think... Could be fun.
Click to expand...
Click to collapse
Will do, I'm quite swamped in projects at the moment :laugh: Got one app I'm supposed to finish up by the 30th. Will I get the time, who knows
Damn it feels good to be back on a Nexus, with all the dev support. You did awesome things back with toro. I enjoyed my time with the Moto X, but the development forums were like a ghost town. Thank you for taking the time to do this, I will be trying it out tomorrow.
Ooo really interested in the read/write speeds between encrypted and non-encrypted!
And we're back! Nice work @bbedward!
bbedward said:
I'm not responsible for anything blah blah
I haven't tested this, because I don't have a nexus 6 at the moment. But this is a boot.img that (should) disable forced encryption. Rooted and non-rooted versions available.
What this does is disables forced encryption (and adds root, or not)
This isn't tested, but I'm fairly confident it will work after observing how this force encryption stuff works. Basically when all the devices from fstab are mounted in android, fs_mgr sets a flag for encryption on devices (up to 1 device I guess) that have forceencrypt set on them, if it can unmount the device or it isn't busy (if it can't it just goes on without encryption )
You can still encrypt the device, it just isn't forced. Some people are complaining about the slowness of the encryption SW-layer. This makes it the way it probably should be - optional.
Rooted (Chainfire) - no force encrypt:
https://www.androidfilehost.com/?fid=95784891001613334
Stock - No force encrypt:
https://www.androidfilehost.com/?fid=95784891001613336
Stock (in case these don't work for some reason you can just use this one to go back):
https://www.androidfilehost.com/?fid=95784891001613337
How-to:
1.) Reboot to boot loader
2.) Unlock device (fastboot oem unlock) - will wipe all data
3.) I think unlocking the device will automatically run encryption jobs, so don't do anything important because you'll need to factory reset again
4.) Download 1 of the above no force encrypt files (Chainfire rooted one, or stock one - up to you)
5.) Flash it in the bootloader (fastboot flash boot boot_noforceencrypt.img)
6.) If it works, factory reset the device and it should no longer be automatically encrypted (check in Settings -> Security)
7.) If it doesn't work, go back into the bootloader and flash the stock image.
Like I said, I don't have my own nexus 6 to test yet, but I'm just trying to help out.
Click to expand...
Click to collapse
flashed the rooted one after data wipe/factory reset trying to normal boot with this version i get an infinite loop of the chainfire auto root script running. flashed the noenforce version and was able to boot up fine but super su says no root. the encryption disable did work however.
purian23 said:
And we're back! Nice work @bbedward!
Click to expand...
Click to collapse
Affinity Nexus 6 ROM uploaded for flashing tomorrow?
djkinetic said:
flashed the rooted one after data wipe/factory reset trying to normal boot with this version i get an infinite loop of the chainfire auto root script running. flashed the noenforce version and was able to boot up fine but super su says no root.
Click to expand...
Click to collapse
I'm not sure how the chainfire stuff works entirely TBH. I saw in the thread over there people had it looping a few times before coming to.
You need to factory reset after flashing this, too. Which can be done with fastboot erase userdata.
Looks like, cf-auto root doesn't call "fastboot flash boot" just "fastboot boot" - is that a difference or is it the same thing?
djkinetic said:
flashed the rooted one after data wipe/factory reset trying to normal boot with this version i get an infinite loop of the chainfire auto root script running. flashed the noenforce version and was able to boot up fine but super su says no root. the encryption disable did work however.
Click to expand...
Click to collapse
What I'm sure everyone is dying to know is if you can run Androbench and report what the NAND scores are after disabling encryption.
bbedward said:
I'm not sure how the chainfire stuff works entirely TBH. I saw in the thread over there people had it looping a few times before coming to.
You need to factory reset after flashing this, too. Which can be done with fastboot erase userdata.
Looks like, cf-auto root doesn't call "fastboot flash boot" just "fastboot boot" - is that a difference or is it the same thing?
Click to expand...
Click to collapse
i ended up flashing noencrypt, then factory reset, then running cf root after a full reboot, end result encryption off and root with twrp =) life is good.
djkinetic said:
i ended up flashing noencrypt, then factory reset, then running cf root after a full reboot, end result encryption off and root with twrp =) life is good.
Click to expand...
Click to collapse
Looks like I misunderstood how CF-auto-root works. it just boots within the bootloader and does stuff. I'll update the OP
NeoteriX said:
What I'm sure everyone is dying to know is if you can run Androbench and report what the NAND scores are after disabling encryption.
Click to expand...
Click to collapse
Haha you just voiced what everyone lurking in this thread is hoping to see.
Thank you so much for this. Here are some quick I/O scores after disabling encryption.
http://imgur.com/DquRHEo
seoulstyle said:
Thank you so much for this. Here are some quick I/O scores after disabling encryption.
http://imgur.com/DquRHEo
Click to expand...
Click to collapse
For the lazy people, such as myself, is that an improvement?
cheami said:
For the lazy people, such as myself, is that an improvement?
Click to expand...
Click to collapse
Huge improvement. I didn't think to benchmark before, but here's some Nexus 5 scores with encryption enabled/disabled for comparison.
https://plus.google.com/+JeremyCamp1337/posts/iDyPjEuEf51
cheami said:
For the lazy people, such as myself, is that an improvement?
Click to expand...
Click to collapse
Huge improvement. Like, 5x better based on the benchmarks I've seen.
cheami said:
For the lazy people, such as myself, is that an improvement?
Click to expand...
Click to collapse
That looks like a vast improvement, faster than the note 4.
http://arstechnica.com/gadgets/2014...premium-price-still-comes-with-compromises/2/
Woot woot
Side question, if we flash this image to disable encryption, have root, and unlocked bootloader, will we still get the OTA updates?
aznalan15 said:
That looks like a vast improvement, faster than the note 4.
http://arstechnica.com/gadgets/2014...premium-price-still-comes-with-compromises/2/
Woot woot
Side question, if we flash this image to disable encryption, have root, and unlocked bootloader, will we still get the OTA updates?
Click to expand...
Click to collapse
I think so, but this boot.img would be overwritten after an OTA update so it'd turn back on the forced encryption (which would encrypt after the OTA rebooted/booted). You'd probably also lose root, assuming it formats /system.
cheami said:
For the lazy people, such as myself, is that an improvement?
Click to expand...
Click to collapse
http://i.imgur.com/XKDye36.jpg
This is someone's Androbench scores on a stock (encrypted) Nexus 6 for comparison. It's quite a lot better.
Related
Q&A for [How-To] Disable Forced Encryption on Nexus 9
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [How-To] Disable Forced Encryption on Nexus 9. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
You are awesome dude! I don't have enough posts so I have to post in the original post, I'll just send you my thanks here.
Some benchmarks
I can't post in the main thread, so maybe someone can post these findings up there?
All in all, it doesn't look like there's much overhead on the N9. I was actually hoping that there would be more of a difference to explain some of the baffling lag on the damn thing. My Nexus 6 saw HUGE differences once I ran it unencrypted.
(Encrypted results were snagged from AndroidPolice's article (whoops, can't post links either) on the N6. Because it didn't seem like it had much of an affect on performance, I restored the stock boot.img and ran the tests again after the encryption process completed. They're listed as Re-Encrypted below. Some odd results, but that can probably be attributed to the fact that I only ran the tests once (maybe twice).
4KB RW (MB/s)
AP - Encrypted - 3.14
Unencrypted - 3.12
Re-Encrypted - 4.33
256KB SR (MB/s)
AP - Encrypted - 39.4
Unencrypted - 40.55
Re-Encrypted - 39.48
4KB RR (MB/s)
AP - Encrypted - 18.41
Unencypted - 19.88
Re-Encrypted - 17.57
Are people seeing a better user experience doing this?
JustusIV said:
Are people seeing a better user experience doing this?
Click to expand...
Click to collapse
The difference hadn't been super noticeable except for some websites I visit that have a lot of dynamic data (comments) being MUCH faster.
atlharry said:
I can't post in the main thread, so maybe someone can post these findings up there?
All in all, it doesn't look like there's much overhead on the N9. I was actually hoping that there would be more of a difference to explain some of the baffling lag on the damn thing. My Nexus 6 saw HUGE differences once I ran it unencrypted.
(Encrypted results were snagged from AndroidPolice's article (whoops, can't post links either) on the N6. Because it didn't seem like it had much of an affect on performance, I restored the stock boot.img and ran the tests again after the encryption process completed. They're listed as Re-Encrypted below. Some odd results, but that can probably be attributed to the fact that I only ran the tests once (maybe twice).
4KB RW (MB/s)
AP - Encrypted - 3.14
Unencrypted - 3.12
Re-Encrypted - 4.33
256KB SR (MB/s)
AP - Encrypted - 39.4
Unencrypted - 40.55
Re-Encrypted - 39.48
4KB RR (MB/s)
AP - Encrypted - 18.41
Unencypted - 19.88
Re-Encrypted - 17.57
Click to expand...
Click to collapse
If we go technical
The nexus 9 most likely has an accelerator that uses our 64bit cpu which makes it faster
unlike the Nexus 6
Wanted to ask in the right place.
So I understand, I disable forced encryption and everything works as normal?
If there is an OTA update I need to NOT install it and wait for an img to be posted here on XDA. I then need to flash that image?
When I do that, I will lose any saved data on my device and have to re-setup the device?
Thanks,
-Jason
Jsunn said:
Wanted to ask in the right place.
So I understand, I disable forced encryption and everything works as normal?
If there is an OTA update I need to NOT install it and wait for an img to be posted here on XDA. I then need to flash that image?
When I do that, I will lose any saved data on my device and have to re-setup the device?
Thanks,
-Jason
Click to expand...
Click to collapse
At worst, you'll have to re-flash the original boot.img, adb sideload the update, then re-flash the no-encrypt boot.img. All without rebooting the device.
As far as i can tell though, since the N9 utilizes the HW cryptography module in the K1, it's not worth the effort since there really aren't any measurable gains. Not like it is with the N6.
atlharry said:
At worst, you'll have to re-flash the original boot.img, adb sideload the update, then re-flash the no-encrypt boot.img. All without rebooting the device.
As far as i can tell though, since the N9 utilizes the HW cryptography module in the K1, it's not worth the effort since there really aren't any measurable gains. Not like it is with the N6.
Click to expand...
Click to collapse
Oh, cool! That's cool! I didn't know that.
Getting a N9 in the next few days and plan on using adb and fastboot to unlock, root, install recovery, etc. At which point should I flash the unencrypted boot.img?
Still Encrypted
After flashing the modified boot and data reset Nexus 9 stills shows as encrypted under Security tab.
How to root after removing encryption?
Before I removed the forced encryption, I was rooted.
Now I see that root has been removed since removing forced encryption.
How do I reinstate root without re-encrypting my Nexus 9?
Neville Bailey said:
Before I removed the forced encryption, I was rooted.
Now I see that root has been removed since removing forced encryption.
How do I reinstate root without re-encrypting my Nexus 9?
Click to expand...
Click to collapse
The same way you rooted it before
Sent from my Nexus 5 using XDA Free mobile app
jd1639 said:
The same way you rooted it before
Sent from my Nexus 5 using XDA Free mobile app
Click to expand...
Click to collapse
Which is what I did, but then the encryption was reinstated.
In bootloader, I flashed inject.img and patched.img and, after the tablet rebooted, it automatically encrypted the tablet.
Neville Bailey said:
Which is what I did, but then the encryption was reinstated.
In bootloader, I flashed inject.img and patched.img and, after the tablet rebooted, it automatically encrypted the tablet.
Click to expand...
Click to collapse
You dont flash the patched.img
Just flash a custom kernel
USBhost said:
You dont flash the patched.img
Just flash a custom kernel
Click to expand...
Click to collapse
Thank you - that did the trick!
Why need I close the forced encyption?
Disabling forced encryption with Nexus Root Toolkit not working on my Nexus 9
Hi everyone,
I wanted to disable the forced encryption in my Nexus 9 using the Nexus Root Tolkit v1.9.9. I succesfully installed all the drivers and apparently was able to unlock + root my device. However, when I try to disable the forced encryption the tool somehow isn't successful in flashing the new flashboot, and when the device reboots it is still encrypted.
Did anyone come accross this issue?
Thanks very much for your help!!
Thanks for the tip
could someone share the new img 5.0.1 without encryption? i could not download it from mega
Sent from my GT-N7000 using XDA Premium 4 mobile app
Since there seems to be no way of installing current (and future) patches from stock recovery when the device is rooted, it'd be good to know if someone has information about whether it's possible or not to develop a custom recovery. The old method using 5.02 droidboot won't work because the updates mess up the whole system if you use them. So since we have unlockable bootloaders in 5.1, could there be the possibility of compiling a permanent CWM?
since there seems no one to be working on it at the moment, i'll start a few tries myself and document the progress in this thread. Feel free to help or comment.
For now, i', stuck at unlocking the bootloader and still don't know why. "OEM unlock" was set in the developer options, rebooted to fastboot and tried "fastboot oem unlock". Results as attached. :\
I'll google a bit around and see if i can get it working....
What's the question - how to load the tethered CWM when you're running Lollipop 5.1? Because I can do that and provide insructions.
He's asking about a recovery that can be installed to the recovery partition, not just tethered.
It's possible, but we'd need somebody to build one. I tried one a while back from the Zenfone 2, but it didn't want to boot.
jumpup said:
What's the question - how to load the tethered CWM when you're running Lollipop 5.1? Because I can do that and provide insructions.
Click to expand...
Click to collapse
no, it's not about the tethered one. The method booting tethered CWM won't work anymore once you installed the stagefright update. We'd need a 5.1 post-stagefright boot.img and system.img for that. And as the bootloader can be unlocked now, i think it might be the better solution to build a untethered CWM for the future.
@xBIGREDDx: do you have any good step by step instructions for setting up a build environment for that? The most things i found we not that complete. E.g. where to find the "vendor-specific files" and what they even are.
toxic_garden said:
no, it's not about the tethered one. The method booting tethered CWM won't work anymore once you installed the stagefright update. We'd need a 5.1 post-stagefright boot.img and system.img for that. And as the bootloader can be unlocked now, i think it might be the better solution to build a untethered CWM for the future.
@xBIGREDDx: do you have any good step by step instructions for setting up a build environment for that? The most things i found we not that complete. E.g. where to find the "vendor-specific files" and what they even are.
Click to expand...
Click to collapse
There is a means of booting to tethered CWM after the Stagefright update. You must first flash the old 5.02 droidboot firmware via Intel Flash Utility (while in bootloader mode). Afterward, you can run the tethered CWM.
@xBIGREDDx made some instructions on this. Let me find it.
http://forum.xda-developers.com/showpost.php?p=64391058&postcount=16
This is not straightforward, but you *can* get to tethered CWM and root your 5.1 system. I did exactly this.
jumpup said:
There is a means of booting to tethered CWM after the Stagefright update. You must first flash the old 5.02 droidboot firmware via Intel Flash Utility (while in bootloader mode). Afterward, you can run the tethered CWM.
Click to expand...
Click to collapse
that'S exactly the problem: if you flash the 5.02 droidboot over a system that applied the stagefright fix, you'll completely mess up the system. The fix contains a new boot.img and patches to the system.img, so even rolling back after super su to the stock 5.1 boot and system.img will get your tablet in a messed up state. If there'd be a way to dump the actual system and boot img without root, we could still use this method, but i don't know of one.
toxic_garden said:
that'S exactly the problem: if you flash the 5.02 droidboot over a system that applied the stagefright fix, you'll completely mess up the system. The fix contains a new boot.img and patches to the system.img, so even rolling back after super su to the stock 5.1 boot and system.img will get your tablet in a messed up state. If there'd be a way to dump the actual system and boot img without root, we could still use this method, but i don't know of one.
Click to expand...
Click to collapse
*OH*! Now I understand. Could you post a screenshot of the build version with the Stagefright patch applied? I want to compare to mine. See attached.
Sent from my Venue 8 7840 using Tapatalk
jumpup said:
*OH*! Now I understand. Could you post a screenshot of the build version with the Stagefright patch applied? I want to compare to mine. See attached.
Sent from my Venue 8 7840 using Tapatalk
Click to expand...
Click to collapse
Here's mine. Software version doesn't seem to be changed, but the kernel is different...
With my current Android installation, CWM does not seem to be able to back up the data partition which is unfortunate.
However, I have always used a multi-tiered backup system:
* Titanium Backup (FULL on Sunday, INCREMENTAL every other day)
* Online NAndroid Backup (One per week using CWM format)
Each app's backup data syncs to the home NAS and Dropbox once a week.
I thought I had the Stagefright fix already in place. That's why I wanted to compare build/version details with a device that has the fix installed.
jumpup said:
With my current Android installation, CWM does not seem to be able to back up the data partition which is unfortunate.
Click to expand...
Click to collapse
Yeah, /data is encrypted, so CWM can't access it for backup.
And since the stagefright fix won't install when it recognizes the /system partition as "tempered" (which means e.g. having the superSU binaries installed), it's pretty hard to keep root. That's the trap we're in.
back to topic: i'm gonna boot my linux netbook today and see if i can get the "oem unlock" option working...
toxic_garden said:
Yeah, /data is encrypted, so CWM can't access it for backup.
And since the stagefright fix won't install when it recognizes the /system partition as "tempered" (which means e.g. having the superSU binaries installed), it's pretty hard to keep root. That's the trap we're in.
back to topic: i'm gonna boot my linux netbook today and see if i can get the "oem unlock" option working...
Click to expand...
Click to collapse
D'oh. I should have remembered about the data encryption. Need more caffeine
If you need anything tested or confirmed in the field, I'd be glad to help.
Sent from my Venue 8 7840 using Tapatalk
toxic_garden said:
Here's mine. Software version doesn't seem to be changed, but the kernel is different...
Click to expand...
Click to collapse
The build number of a 5.1 install prior to Stagefright is different as well. Ends in 171200DEL instead of 173600DEL post-Stagefright patch.
jumpup said:
The build number of a 5.1 install prior to Stagefright is different as well. Ends in 171200DEL instead of 173600DEL post-Stagefright patch.
Click to expand...
Click to collapse
oops you're right. Didn't even notice.
First steps forward: it seems like it's not possible to unlock the bootloader with installed sf-patch. No matter which version of fastboot i tried, i always got "FAILED: (some text i can't remember)". After downgrading to 5.1 stock firmware, unlock was possible. So as i now at least have the possibility to boot another recovery, i'll try setting up the build env. The Recovery Builder from CWM seems to be out of order at the moment.
toxic_garden said:
Here's mine. Software version doesn't seem to be changed, but the kernel is different...
Click to expand...
Click to collapse
I now have the Stagefright patch installed. Used the 5.02 droidboot temporarily to engage tethered CWM and install SuperSU. Reflashed 5.10 droidboot and firmware before proceeding. All is well. As you mentioned, it makes for a mixed 5.1 boot system, but I simply cannot live without root.
Here are the new build/version details:
After taking your advice and flashing the sg droidboot, my IWFI version is in line. I'll see if any system issues occur.
Is anyone still working on the 7840? Would be nice to have TWRP or CWM
I've been poking around on my 7840 on and off for a few weeks now. I seem to have verified that, after unlocking the bootloader, you can modify the boot and recovery partitions to your heart's content. However, any time I rebuild the kernel myself, I end up back at the "Dell" screen, frozen. Any other files are free game.
Assuming that the kernel needs to be signed using some tool I haven't figured out yet, I'm going to see if I can get a version of CWM working w/ the stock kernel. I tried dumping the version from the tethered recovery onto the recovery.img, but running it results in a black screen. I'll keep poking around though.
I got a new Motherboard and daughterboard in my HDX Apollo. I was able to get TWRP on it, but it keeps saying i dont appear to have root. I tried installing the latest supersu but it apparently didnt work. Anyway, i have realized that i just keep getting myself into trouble playing with root. All i want is to get my 3rd gen back to 4.5.5.1 fire os and wait for the fire os 5 update for it(hopefully) Any help on how i can do that? Ive tried downloading the latest Kindle update for apollo, renaming the .bin to update.zip and transferring it over and installing it but it never boots further than the 'kindle' screen.
Thanks for your help, sorry to be a pain
If you're on Fire OS 4.x you don't have TWRP, but Safestrap v4. After what you've done, do you still have access to Safestrap? Installing an amazon update with Safestrap installed, or even just rooted could easily mess up the device, i.e. brick it.
I don't think it's fire os 4x then. It does boot into the twrp interface and is fully functional but when you go to reboot into a different recovery it says something like "it appears you do not have root. Would you like to install supersu?" Even if I say yes it acts like it installs but apparently doesn't. I can post pics later
Sent from my SM-G920V using XDA-Developers mobile app
Cl4ncy said:
If you're on Fire OS 4.x you don't have TWRP, but Safestrap v4. After what you've done, do you still have access to Safestrap? Installing an amazon update with Safestrap installed, or even just rooted could easily mess up the device, i.e. brick it.
Click to expand...
Click to collapse
Oh and I'm not sure what the new board had on it. It never fully booted. That's why I installed twrp. Thanks for the reply though!
Sent from my SM-G920V using XDA-Developers mobile app
mhuck0625 said:
I don't think it's fire os 4x then. It does boot into the twrp interface and is fully functional but when you go to reboot into a different recovery it says something like "it appears you do not have root. Would you like to install supersu?" Even if I say yes it acts like it installs but apparently doesn't. I can post pics later
Click to expand...
Click to collapse
mhuck0625 said:
Oh and I'm not sure what the new board had on it. It never fully booted. That's why I installed twrp. Thanks for the reply though!
Click to expand...
Click to collapse
- how did you "install" TWRP (method)?
- how are you accessing TWRP - just pressing the power button or some key combination (yes, it's important)?
- does a graphic vaguely resembling Frankenstein appear when you power up the device?
Davey126 said:
- how did you "install" TWRP (method)?
- how are you accessing TWRP - just pressing the power button or some key combination (yes, it's important)?
- does a graphic vaguely resembling Frankenstein appear when you power up the device?
Click to expand...
Click to collapse
I installed TWRP using the method instructed here: http://forum.xda-developers.com/kin...-to-unbrick-kindle-fire-hdx-firmware-t3277197
When i want to get to TWRP i press and hold Power + Vol UP until it rebootes into the Teamwin screen and TWRP. It is version 2.8.7.0 now(the instructions got 2.8.5.0 installed then i upgraded)
I dont remember what the graphic looked like when booting into TWRP but i know it said TeamWin. I can check when i get it charged back up enough to turn on. Ive had it sitting unplugged for days and the battery ran dead. I hope this is enough info to help get me pointed in the right direction. Thanks!
Ok, if it's the real TWRP which it seems to be, Safestrap has no TeamWin logo at boot, I'd suggest you leave it be. Currently you can use all available ROMs, so if there'll be a future version of Fire OS you could use a TWRP flashable version of it. I doubt there will be a Fire OS 5 update for the "old" Thor/Apollo line though.
You would destroy the possibilities you currently have by updating to Fire OS 4.5.5.1.
Meanwhile you can unlock your bootloader (if you haven't already), and update TWRP to 3.0.0-1 (requires unlocked bootloader).
Don't I need root though? How can I unlock my bootloader from the stage I'm at now? I'm just a bit afraid of proceeding in case I brick it again
Sent from my SM-G920V using XDA-Developers mobile app
Cl4ncy said:
Ok, if it's the real TWRP which it seems to be, Safestrap has no TeamWin logo at boot, I'd suggest you leave it be. Currently you can use all available ROMs, so if there'll be a future version of Fire OS you could use a TWRP flashable version of it. I doubt there will be a Fire OS 5 update for the "old" Thor/Apollo line though.
You would destroy the possibilities you currently have by updating to Fire OS 4.5.5.1.
Meanwhile you can unlock your bootloader (if you haven't already), and update TWRP to 3.0.0-1 (requires unlocked bootloader).
Click to expand...
Click to collapse
Don't I need root though? How can I unlock my bootloader from the stage I'm at now? I'm just a bit afraid of proceeding in case I brick it again
Sent from my SM-G920V using XDA-Developers mobile app
There's no risk in unlocking, the bootloader either unlocks or it errors/fails. Try the one-click-solution first (might require the PDANet drivers). It's recommended to update the bootloader to 3.2.3.2 (do it only, if the unlock worked ok).
TWRP can be updated from TWRP itself, so I'd recommend doing it that way. Just be sure to flash the TWRP image to the recovery partition.
Cl4ncy said:
There's no risk in unlocking, the bootloader either unlocks or it errors/fails. Try the one-click-solution first (might require the PDANet drivers). It's recommended to update the bootloader to 3.2.3.2 (do it only, if the unlock worked ok).
TWRP can be updated from TWRP itself, so I'd recommend doing it that way. Just be sure to flash the TWRP image to the recovery partition.
Click to expand...
Click to collapse
Tried 1-Click. In both Linux(Ubuntu 16.04) and Windows(10.1 x64) i get an error saying ADB is not enabled on the device. Ive tried booting into fastboot(with fastboot cable) tried using the regular cable and booting into TWRP. Any combination of boot modes and cables i can think of wont work. Where should i go from here?
Thanks
mhuck0625 said:
Don't I need root though? How can I unlock my bootloader from the stage I'm at now? I'm just a bit afraid of proceeding in case I brick it again
Click to expand...
Click to collapse
Root is irrelevant at this stage as nothing has been flashed to the system partition (where ROMs live).
Davey126 said:
Root is irrelevant at this stage as nothing has been flashed to the system partition (where ROMs live).
Click to expand...
Click to collapse
Ok, so i will need root to install ROMs then? How do i solve my problem unlocking the bootloader?
mhuck0625 said:
Tried 1-Click. In both Linux(Ubuntu 16.04) and Windows(10.1 x64) i get an error saying ADB is not enabled on the device. Ive tried booting into fastboot(with fastboot cable) tried using the regular cable and booting into TWRP. Any combination of boot modes and cables i can think of wont work. Where should i go from here?
Thanks
Click to expand...
Click to collapse
Lack of a functioning ROM could prove problematic if ADB is not enabled. I do not recall if the version of TWRP you installed provides native support for MTP which is essential for moving files onto the device. You may need to go the manual route to unlock bootloader which still requires tethered access but only at the fastboot level.
Nearing the edge of my pay grade on this topic; looking for others with more recent experience to jump in...
Davey126 said:
Lack of a functioning ROM could prove problematic if ADB is not enabled. I do not recall if the version of TWRP you installed provides native support for MTP which is essential for moving files onto the device. You may need to go the manual route to unlock bootloader which still requires tethered access but only at the fastboot level.
Nearing the edge of my pay grade on this topic; looking for others with more recent experience to jump in...
Click to expand...
Click to collapse
I do have mtp access and can transfer files easily. Should I try installing a Rom to see if I get adb access? What's a good Rom to try
Sent from my SM-G920V using XDA-Developers mobile app
Davey126 said:
Lack of a functioning ROM could prove problematic if ADB is not enabled. I do not recall if the version of TWRP you installed provides native support for MTP which is essential for moving files onto the device. You may need to go the manual route to unlock bootloader which still requires tethered access but only at the fastboot level.
Nearing the edge of my pay grade on this topic; looking for others with more recent experience to jump in...
Click to expand...
Click to collapse
Just curious on one thing. Whenever i see a ROM to download it says i need to unlock the bootloader and have root before i can do that. In MY case i do NOT have either, yet i was able to flash a new recovery(TWRP) How is this possible? How would i go about installing a new ROM or unlocking the bootloader?
Is there a way to flash the stock recovery back so i can reinstall fireOS and start from scratch?
Is there a way to tell what bootloader i have from within TWRP?
I realize i probably should have done a little more reading before i started messing with it :/ I do appreciate all the help you have been able to provide so far!
mhuck0625 said:
I do have mtp access and can transfer files easily. Should I try installing a Rom to see if I get adb access? What's a good Rom to try
Click to expand...
Click to collapse
mhuck0625 said:
Just curious on one thing. Whenever i see a ROM to download it says i need to unlock the bootloader and have root before i can do that. In MY case i do NOT have either, yet i was able to flash a new recovery(TWRP) How is this possible? How would i go about installing a new ROM or unlocking the bootloader?
Is there a way to flash the stock recovery back so i can reinstall fireOS and start from scratch?
Is there a way to tell what bootloader i have from within TWRP?
I realize i probably should have done a little more reading before i started messing with it :/ I do appreciate all the help you have been able to provide so far!
Click to expand...
Click to collapse
- traveling; response will be brief
- suggest flashing cm11 as it does not require an unlocked bootloader nor GAaps for basic functionality
- include SuperSU in flash package to secure root
- follow flashing directions in cm11 OP
- report back results; will go from there
Davey126 said:
- traveling; response will be brief
- suggest flashing cm11 as it does not require an unlocked bootloader nor GAaps for basic functionality
- include SuperSU in flash package to secure root
- follow flashing directions in cm11 OP
- report back results; will go from there
Click to expand...
Click to collapse
Downloaded CM11 and installed via this thread
http://forum.xda-developers.com/kin...-cm-11-safestrap-20150628-unofficial-t3145547
Copied it as well as the latest SuperSu(v2.65) to the Kindle Fire
Went to Install, saw both Zip files. Selected them(CM11 first, then Supersu second) Swipe to install, rebooted and nothing came up. Rebooted into TWRP and repeated the process after wiping dalvik/cache. Still nothing
mhuck0625 said:
Downloaded CM11 and installed via this thread
http://forum.xda-developers.com/kin...-cm-11-safestrap-20150628-unofficial-t3145547
Copied it as well as the latest SuperSu(v2.65) to the Kindle Fire
Went to Install, saw both Zip files. Selected them(CM11 first, then Supersu second) Swipe to install, rebooted and nothing came up. Rebooted into TWRP and repeated the process after wiping dalvik/cache. Still nothing
Click to expand...
Click to collapse
Makes sense. Likely no kernel. Will probably need to install a full version of FireOS for underlying components. Need to have a think about which build to maximize results, minimize rework. More later....
Davey126 said:
Makes sense. Likely no kernel. Will probably need to install a full version of FireOS for underlying components. Need to have a think about which build to maximize results, minimize rework. More later....
Click to expand...
Click to collapse
You have no idea how much i appreciate the help!
I look forward to hearing what you come up with!!
I would be happy just going straight back to full fire os - Stock EVERYTHING and not even worrying about running another OS. I just want to have a usable tablet again!
Trying to root Nougat (Android 7)? Then read the comments at the bottom please...
I will first state I do NOT own a Moto G4, I own the G3 and the X Pure which are both 3rd Gen devices, but I was requested to write this tutorial by a few users here due to lots of failed root attempts using older "standard" methods that do not work on this device. I also do not like the "one click" root methods, because they can and do fail (KingoRoot will brick a Moto G3/4, regardless of what it's web page says), and when they do people have no idea how to fix it. The manual way is not difficult, and it teaches you how to work on, fix, and use your device on a level above that of the average smartphone user.
I will only cover rooting, the prerequisites are covered elsewhere in detail and I will link to reliable sources for the information. Specifics of the prerequisites are outside of the scope of this tutorial, but are open for discussion in this thread. Remember, I do not own this device although the methods used are the same as similar devices.
Prerequisites:
0) Be running Marshmallow (Android 6.x) stock ROM, at this time Nougat (Android 7.x) is not working via any method.
1) Device must have an unlocked bootloader. See Moto - Unlocking the Bootloader for more info.
NOTE: As of 7/18/2016, Amazon ad-subsidised Moto G 4th Gen devices cannot be bootloader unlocked, therefore they cannot be rooted. Sorry, Lollipop and newer Android security changes pretty much put an end to that.
2) You need to have TWRP installed or one-time booted via fastboot. CWM and other recoveries will NOT work at this time. See TWRP's Moto G 2016 page
3) You need a copy of the latest stable SuperSU ZIP from Chainfire's site on the internal storage or SD card of your device. SR1-SuperSU-v2.78-SR1-20160915123031.zip is the lastest version verified to work with this method.
Note: Do NOT use any 2.77 version, it was a beta intended specifically for the SG Note 7 and will not work, it does not harm but fails to root.
4) Reboot and start TWRP recovery, and PERFORM A COMPLETE BACKUP IN TWRP (Nandroid)!!!
How to do it:
Now, the procedure is the same whether you are trying to root the first time, or you did it the old way just flashing SuperSU and are now not able to boot...
In TWRP, go to Advanced and open the Terminal, in the terminal type this EXACTLY as shown:
Code:
echo SYSTEMLESS=true>>/data/.supersu
Now press enter (there is no confirmation returned), then exit and press the Home key. Go to Install and select the SuperSU zip file you downloaded from Prerequisite #3 and swipe to flash it and reboot. No need to clear caches or anything else but you are welcome to if you wish. You can install SuperSU updates normally through the app going forward (as of this posting).
Why do I have to do this???
For whatever reason, the install script for SuperSU does not recognize that this device (like many others) requires a systemless root installation. By creating /data/.supersu in the TWRP recovery environment, the SuperSU install script parses the file and sees "SYSTEMLESS=true" and ignores what it auto-detects and forces a systemless root installation.
Hope this is helpful to someone!
As always, if this is the first time you have booted TWRP or attempted root... BACKUP IN TWRP FIRST!!! Once the system is modified, it cannot be undone (easily) and you will always have a known good starting place if the worst happens.
EDIT: Photos added showing what a proper command and flash should look like. Note that in picture 1 the exit command is not needed, you can just back out. In pictures 2 and 3 a proper flash of SuperSU is shown, note that system-less mode is specified and the boot image is patched, this is what should occur. It is normal for it to loop once or twice, but that is it, first boot could take 10 minutes plus.
Notes on Nougat/Android 7... At this time this method of rooting does not work properly on the official Nougat ROM for this device, it causes WiFi issues and interface problems (settings crashes, etc) and with no complete factory image there is no work fix other than to restore your Nandroid backup to pre-root status. If you wish to play with this method and try it, your on your own, I will try to assist but as I stated earlier I do not own this device. To my knowledge as of this posting, there is no working root on stock Android 7 on this device.
I can confirm this worked on my formerly-amazon XT1625 16GB G4. You will get an error about not being able to mount /data, but it proceeds and works anyway.
This is exactly what was missing! I rooted as normal with the latest SuperSU expecting it to just work like on other phones/tablets, but yeah. Before specifying systemless, it hung on boot. After following your instructions it booted right up. Thanks!
Also if you setup adaptable storage with your SDcard, so it works like internal storage, TWRP can't find any files on the SDcard. You will need to revert to non-adaptable storage for TWRP to find the supersu ZIP file.
And make sure you're using the latest SuperSU-- I accidentally tried a very old version which did not work!
Scared Noobie
I should probably be posting this on some noobie forum, but I read Motorola's "Unlock Your Bootloader" and it scared the **** out of me. Can someone give me a ballpark figure of the chances of bricking the phone? (I know this particular phone is new, but I'm just looking for a rough estimate. How common is it generally to brick a phone just from unlocking the bootloader?)
Appreciate this. I miss the old days where it was all simple. Everything was flashable. Never had to flash back to something or re flash.
cuvtixo said:
I should probably be posting this on some noobie forum, but I read Motorola's "Unlock Your Bootloader" and it scared the **** out of me. Can someone give me a ballpark figure of the chances of bricking the phone? (I know this particular phone is new, but I'm just looking for a rough estimate. How common is it generally to brick a phone just from unlocking the bootloader?)
Click to expand...
Click to collapse
It's about as common as bring bricked from performing a factory reset, because that is the only part that really does much... So extremely rare, but the possibility is always there. Remember to have patience, the resets and wipes can take what seems like forever.
The dangerous part is what you do after the bootloader is unlocked.
Sent from my MotoG3 using Tapatalk
cuvtixo said:
I should probably be posting this on some noobie forum, but I read Motorola's "Unlock Your Bootloader" and it scared the **** out of me. Can someone give me a ballpark figure of the chances of bricking the phone? (I know this particular phone is new, but I'm just looking for a rough estimate. How common is it generally to brick a phone just from unlocking the bootloader?)
Click to expand...
Click to collapse
Very rare...all you need is read, read, read and follow the instructions. Good luck
Very nice and just what I needed. Worked perfectly on my Amazon Moto G4 with ads. I got no errors or messages but booted fine-got caught in a boot loop once as the SuperSU file explains after it installs. Boots in less then a minute first time.
Marty
acejavelin said:
It's about as common as bring bricked from performing a factory reset, because that is the only part that really does much... So extremely rare, but the possibility is always there. Remember to have patience, the resets and wipes can take what seems like forever.
The dangerous part is what you do after the bootloader is unlocked.
Sent from my MotoG3 using Tapatalk
Click to expand...
Click to collapse
Hey i wiped this up based on your post it should really help. it completely automates the process check it out if you want to and you can also ad it to the OP if you want to.
DOWNLOAD TOOL HERE Root-moto-g-4th-gen
Tomsgt said:
Hey i wiped this up based on your post it should really help. it completely automates the process check it out if you want to and you can also ad it to the OP if you want to.
DOWNLOAD TOOL HERE Root-moto-g-4th-gen
Click to expand...
Click to collapse
cheers mate
I signed up for xda just to give you props! I rooted my phone using instructions not from here and i was suck in a boot loop. your little command there fixed it! I freakin love you.. wish i could buy you dinner! Thanks a million
zipjay said:
I signed up for xda just to give you props! I rooted my phone using instructions not from here and i was suck in a boot loop. your little command there fixed it! I freakin love you.. wish i could buy you dinner! Thanks a million
Click to expand...
Click to collapse
Your welcome... Just give click thanks on the first post, but if you feel absolutely compelled to buy me dinner, there is the Donate button.
Sent from my MotoG3 using Tapatalk
I rooted my G4 in the normal way using supersu 2.46, and now boot hangs on the white Moto screen. (advice from another site)
I am waiting for a SD card to update to 2.76 with the systemless command.
Is there anything else I can do in the interim, I tried deleting the contents of /supersu from Twrp and that hasnt made any difference. I have also wiped data and caches.
thanks .. Mike
mikeruss said:
I rooted my G4 in the normal way using supersu 2.46, and now boot hangs on the white Moto screen. (advice from another site)
I am waiting for a SD card to update to 2.76 with the systemless command.
Is there anything else I can do in the interim, I tried deleting the contents of /supersu from Twrp and that hasnt made any difference. I have also wiped data and caches.
thanks .. Mike
Click to expand...
Click to collapse
Can't you just use MTP mode of TWRP to copy the latest SuperSU to internal storage then flash after creating the config file?
Sent from my MotoG3 using Tapatalk
thank you, worked fine.
would I be right in thinking I need the sdk23, arm, 64 bit version of xposed ?
mikeruss said:
thank you, worked fine.
would I be right in thinking I need the sdk23, arm, 64 bit version of xposed ?
Click to expand...
Click to collapse
I don't know... I don't own the G4 *yet* but possibly in the near future now that I know the Amazon version can have the ads striped out easily enough... I would do a nandorid and try it, if it fails, restore and use the 32-bit version.
Someone else may have a better answer for you.
acejavelin said:
I don't know... I don't own the G4 *yet* but possibly in the near future now that I know the Amazon version can have the ads striped out easily enough... I would do a nandorid and try it, if it fails, restore and use the 32-bit version.
Someone else may have a better answer for you.
Click to expand...
Click to collapse
32 bit
Sent from my Moto G (4) using Tapatalk
thanks, xposed works fine
Well, I was planning on joining all of you with your Moto G4's soon, or possibly the G4 Plus... but since the Amazon version can't be unlocked anymore I got cold feet, and today Best Buy was running a special on the Moto X Pure 32GB edition for $249 (My Best Buy Elite members only), I pulled the trigger on that one instead. No change in helping though, I didn't have the device to begin with so I will continue to assist with this thread as I can.
Important notice! : iLLNiSS made me aware of a serious risk!
If you play with the firmwares manually and not with the flash all bat then DO NOT flash the blobs!
These are the actual bootloader files and stuffing up here will cause a hard brick!
I have to stress this out as it is serious thanks to not having working APX drivers a flshing programs for the Shield!
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
I have done some extensive tests since the first block based update wrecked my rooted Shield.
Some of it will end up in this post as info for everyone.
But lets start with what seems to be the problem for a lot of users right now who run a rooted Shield : Fixing the problem
A downgrade is officially not supported by Nvidia but my tests showed it works just fine if you only go back to the 7.1.
So far my tests showed differen sources for a Shield no longer working after the OTA.
1. The device had an unlocked bootloader and you got the 422mb block update.
This would have stuffed your bootloader and the Shield won't go past 1/4 on the progress bar for the update.
You are in luck as just flashing the 7.1 bootloader will fix it.
After that just dismiss the update and change the settings to manual updates.https://forum.xda-developers.com/editpost.php?do=editpost&p=78466377
2. Your device was already fully rooted and you got the full update that resulted in your Shield doing all sorts of thing but nothing properly anymore.
As long as your apps are still there and the Shield is still somhow usable you are lucky again.
A downgrade to 7.1 will fix it, I will explain the steps required further down.
3. You made bid mods, used Magisk or other rooting tools and now your Shield complains that your system is corrupt.
Bad luck if your bootloader is locked as you loose it all.
Lucky if the bootloader is unlocked as you might be able to keep most if not all during the downgrade.
General words of warning:
Even if your bootloader was unlocked from day one I can not garantee that the downgrade will keep all settings, apps, databases and so on.
For me it works fine as I kept all vital databases on external storage.
The procedures are all based on the developer firmware, on the stock firmware some things can still be done but then again you should not have more than software problems.
On the stock firmware the bootloader is locked by default and you can use some things required to owngrade due to the restrictions of a stock system.
General downgrade procedure for the developer firmware to get back to 7.1 :
If the update did get stuck on the progess bar early on and a reboot won't fix it so you can dismiss the update you just follow the steps.
If you can reboot into the 7.1 then just dismiss the update.
Trust issues or curruption warnings at boot but an otherwise working shield on 7.1 require to flash the 7.1 bootloader again.
In some cases it is possible to skip the corruption warning with a connected controller.
A reboot once you got to the homescreen will determine how bad it is.
Reboot goes fine: You are good.
Reboot keeps nagging with warnings other than the unlocked bootloader: Downgrade.
The downgrade is only required if you have problems or the Shield already runs on the 7.2!
In almost all other cases just flashing the 7.1 bootloader is sufficient.
Fixing a stuffed Shield by sideloading the 7.1 firmware while keping all apps and things:
Enable USB debugging and allow the connections for the computer if you still have access to the settings.
Otherwise you need to flash the 7.1 fresh and might loose vital things that need to install again.
Reboot into the stock recovery, if you use TWRP flashed on the Shield already then please flash the recovery from the 7.1 firmware first.
Hook up the controller and pressing A or B should get you into the normal recover screen past the dead droid.
ADB sideload XXX - where the xxx stands for the filename you have for the developer ZIP.
After the rebbot you should be back on your 7.1 homescreen and can dismiss the 7.2 update.
Also change the update settings while at it
Fixing a fully stuffed Shield and then downgrading to the 7.1 firmware:
If all went down south then you tried a few things and realised there is no way to get your data back and even less to prevent the 7.2 update.
Installing the 7.1 from scratch forces the setup wizard and before you can get anywhere you need to update to 7.2
So much easier to use the linked 7.2 update from above until Nvidia provides it on their download servers.
A vital thing to do is to keep the bootloader locked!!
Same for NOT having TWRP installed on the Shield!
If in doubt flash the 7.1 boot and recovery partitions first then go back into the stock recovery and wipe the cache.
Coming from a stock developer firmware with just an unlocked bootloader you are good to go.
Sideload the 7.2 update.
Unplug when the reboot starts and go into fastboot to lock the bootloader: Fastboot oem lock.
This is a vital step as the new kernel otherwise could ruin the completion of the install.
Ignore the double hassles and go through the wizard so you can enter the settings again to enable the developer mode and USB debugging.
Unlock the bootloader so you can do it all again Last time I promise!
Once you have both the bootloader unlocked AND the Shield in a usable condition past the setup wizard:
Reboot into the recovery to sideload the 7.1 firmware.
After the next reboot you are back on the 7.1 homescreen drirectly and can dismiss the update.
Possible tricks that can help you to prevent the installation of the 7.2 update if you come from a fresh 7.1 install instead:
Don't allow the reboot and instead use ADB to reboot into the recovery.
Wipe the cache - this will remove the scripts required to start the update after the reboot.
The next reboot should bring you back to the homescreen where you can stop the new download of the update and change the update settings.
TWRP, full root and new security measures in 7.2:
The 4.9 kernel used also makes use of a Fstab configuration that no longer includes the system partition.
This and other restrictions currently make the normal use of Magisk impossible.
With no system partition available to Magisk the changes in the boot process come to a stop and the Shield gets stuck during boot.
The added restrictions also make it very, very hard to manually add SU and busybox.
At least without getting the currupt system popup on every boot and finding out that a lot of things still don't work properly.
A final 7.2 firmware is said to be available on the download servers today.
If this final is no different from the current OTA then it will not be of any use for users requiring a fully rooted devices.
With the stock recovery still using the old kernel all attempts to use recovery functions to alter the system for rooting fail as well.
Can't blame the company as all this is part of Google revamp og security and closing backdoors and loopholes for possible attackers.
Personally I think it is Googles way of keeping control over devices they don't actually own.
Anyways I did make some little progress:
Plans for the near future:
Security is good but I like to know what my Android devices are doing and especially what Google likes to collect if I can not find ways to stop it.
So I will not try to use any backdoors or secrurity vulnerablilites in the new kernel to allow a full root on my Shield.
I will go the route I know best: Manual labour
The bootloader is already fixed to allow what we are used to from previous developer firmwares.
As SU and busybox can not be manually entered at this stage I will try to include them directly in the stock 7.1 firmware while renaming the OTA updater to have it a bit easier.
Assuming that works as expected I will do the same on the 7.2 firmware and compare the corresponding scripts and so on.
If the standard SU still works on an "unlocked" 7.2 I should be able to adjust the Magisk ZIP accordingly to implement it into the bootloader.
Only need to figure out if Magisk then has enough rights to work and the system is still happy to accept the changes.
I noly have the 16Gb 2017 model to work with but since the bootloader seems to be same for all Shield models I think if it works then it should do so for all models.
In the meantime I hope the infos here will help some pople to get their shield back without the need to sent it in.
Update 25/12/18: I got TWRP working on 7.2
This is only true for the 2017 model though as I have only this for testing.
Currently creating a backup to the internal storage.
If the restore works then I will upload the new TWRP - for the said model only!
Give me a day or two to fix it for the other models too.
There is progress on the rooting front as well.
Created new scripts for my kitchen to be able to handle the new file_context thing.
A fully pre-rooted and totally unsecure (in terms of ABD, DM-verity and such) is already cooked, just did not dare yet to try it out as I have a real life job too.
As for the pre-rooted firmware:
Things have changed quite a bit with the new kernel in terms of "just adding SU or Magisk".
Magisk might see an update for this problem soon, SU however seems to tally fail on two levels.
So far I was unable to do a full install of the modded firmware.
Flashed all at once and the boot just hangs.
Bootloader, reboot, then the rest seems to work.
At least for the basic install of the system.
If I add SU and busybox the system still ends up with a corrup notice during boot and then it fails.
Tune in over the next few days for progress updates at the end of the thread.
Major developments will be added right here.
Just a matter of finding the last restrictions.
Once that is done Magisk should be possible as well.
Ok, TWRP boot fine, does a backup but fails to restore the system to a bootable state.
Will now check if at least installing a zip works.
Well, it did not, so TWRP has to wait a few more days
I edited post 3 with instructions on how to "unbrick" and go back to 7.1.
Update 27/12/18: A friend of mine found some intersting stuff.
A 7.2 firmware offering a pure Android without any TV stuff but also a full root possible.
I hope he will share his finding here soon or allow me post it all in his name.
For now lets just say: It really works if done the rght way!
Full write rights, installing Magisk modules and all.
All thanks to an undocumented flaw in the device security structures, so even without any hidden backdoors or such LOL
Update: Whiteak was so kind to provide a working root solution in post 36, please check it.
I can confirm it is working as promised.
So the credits for this one go to Whiteak and the credits for the idea and use of the DTB file to Zulu99 - great idea!
To prevent any problems I advise to perform a factory wipe after the install and before the first boot.
Switch to the stock recovery to do this then boot as normal an enjoy.
A complete firmware with the required mods is sitting on my PC just waiting for idiot behing the keyboard to figure out how to pack it properly for flashing.
Once that problem is sorted and also TWRP working again things will get a lot easier.
Annoying update:
I was not able to confirm my web findings on the 7.2 firmwares bootloader but it seems other devices running the same type of kernel and bootloader and a bit lost now.
AVB is fully implemented on the latest level.
(Again I am working on confirming or denying these findings!)
This means any alteration to vital parts of the system will fail with a corruption warning or worse.
Custom recovery access is limited if not fully restricted.
But even if it works you still need a firmware to flash that either is able to disable all this crap, hoping the bootloader alone will allow it, or
to hope Nvidia will provide a future bootloader update with these restrictions removed.
We can not downgrade the bootloader and even if there is some old one out there that would actually be flashable the risk is high to end with a brick anyway.
The DTB, at least in my tests gives us the required system wide write access but I have no information about the AVM verfified boot other than that Zulu99's firmware works.
But if it was compiled with the NVidia developer suite then it will be signed accordingly so the bootloader accepts it.
Could not find any info on how his firmware was actually created.
It gives me the hope though that once I have a fully working TWRP again that my modded 7.2 will work as expected and with no restrictions anymore.
Thanks for the info.
Edit: Will use this post to list options to recover the Shield is all seems lost.
As a result of far too much rom cooking and mods I needed a 100% working way to recover the Shield in case things turn very ugly.
So lets sum up what I define as very ugly when playing with firmwares:
1. Firmware installed but the Shield just hangs on the logo.
2. Firmware installed and now the system is corrupt and even it is boots it takes forever to get around the nag screens.
3. Firmware downgrade attempted but now the Shield won't even boot anymore.
4. Anything that would qualify for a soft brick.
My worst case when I only got a flashing white screen after trying to restore a TWRP backup under 7.2.
There any many way that work for a variety of boot problems but it takes too long to list all cases I encountered with a list of fixes that work or a comment that only the below way works.
So just to be clear here: This is not for any recovery purpose other than fixing what can't be fixed through a factory reset or fresh flashing of the firmware!
1. Get the Shield into Fastboot mode: Connect wired controller and male to male USB cable.
2. Power the Shield up while holding A and B on the controller.
Keep holding until you see the fastboot menu on the screen.
3. Install the 7.1 recovery firmware for your Shield type after unpacking it.
With Fastboot connection working type: flash-all.bat and hit enter.
4. Keep an eye on the progess!
5. Once the Shield is finnished and reboots, hold the A and B buttons on the controller again to enter fastboot mode!
Do not let the Shield boot up other than into the fastboot mode!
6. Lock the bootloader! Fastboot oem lock
Confirm with the controller, then go down and select the recovery kernel.
7. Once the dead droid is on the screen press B on the controller to enter the real recovery.
If B does not work try A
8. Select the factory reset option to wipe all!
9. Once the wipe is done you can boot into 7.1 as normal again.
10. With a bit of chance you might even get directly to the homescreen if the previous setup was completed.
If you need the full seup wizard again and are forced to update to 7.2 then at least the update will work fine this time around.
In case you desire to go back to the 7.1:
If you just finnished the above only to end with the 7.2 then set it up and flash the 7.1 - you won't get the setup wizard again and can skip the update.
If you are on a working 7.2 that was update the OTA way but want to go back:
1. Install the 7.1 firmware.
2. Lock the bootloader.
3. Boot and then skip the update to 7.2.
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
psycho_asylum said:
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
Click to expand...
Click to collapse
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Downunder35m said:
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Click to expand...
Click to collapse
I have not been able to get to the dead droid screen.
Downunder35m said:
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
(snip)
Click to expand...
Click to collapse
Thanks for posting this, but please note that this firmware is only for the 2017 16GB model and cannot be used with a 2015 or Pro model.
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Weird, I am not getting the 7.2.1 at all here.
And since yesterday the OTA only tries the block based but not the full image.
AthieN said:
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Click to expand...
Click to collapse
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Thanks downunder this kind of in-depth info is always appriciated man........i like to learn these kind of things, having bits here and bits there gives a better picture of the whole, while also giving us upto date current info.
Thanks for taking the time to write this :good:
---------- Post added at 07:35 AM ---------- Previous post was at 07:27 AM ----------
Edit
Hi downunder, could you confirm i have this correctly
With no access to fastboot thus no twrp or root, are you implying, assuming your able to inject root into stock firmware, that, i'd be able to flash this stock+root rom in STOCK recovery, which i do have access to?
Edit: im under the impression that stock firmware zips are checked by stock recoveries, so modifying a stock firmware zip tends to fail this check and thus wont install/flash.......which makes me think im misunderstanding here......or just hoping im not
If so, im interested
Edit
i just read your second post which near enought answers my curiousity, so that'll teach me to read beyond the first post before asking answered questions ........even if the post excites me............ahhh, who am i kidding, ill probabably do it again........the equivelancy of a mental post boner........not controllable
Sorry for the disgusting analogy
SyberHexen said:
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Click to expand...
Click to collapse
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
ErAzOr2k said:
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
Click to expand...
Click to collapse
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
As long as we don't jump to Android 9 we should always be able to downgrade through a full factory firmware.
Once Android 9 comes this might not work anymore due to the massive changes involved for the boot and system checks.
@banderos101: Unless you really did something bad you should always be able to enter the fastboot mode to flash a full firmware.
If I have some time after xmas I will have another look on the options of signing the zip properly or simply to fake it.
Biggest problem will be to generate the corret SHA checksums ince all is installed so I can use the same checksums in the check files.
The bootloader needs them to identify the system and vendor as genuine.
The system needs them to confirm all is actually unmodified as otherwise all fails to boot at some stage.
Modding a proper userdebug firmware is not really that hard, but converting a release version that also is a true and secure user release...
Lets just say that it won't be an easy task.
As it looks like the kernel is a keeper I might have to figure something out unless TopJohnWu won't enjoy a break after his exams and works on a way to get Magisk working with out kernel.
At least I figured out why the recovery trick isn't working for me.
The system partition is not mounted for the sideload mode.
To apply an update the stuff is written directly onto the partition, so no file level access left to play with and break things
In comparison you could say the shield is now like a modern car with keyless operation only.
You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door
SyberHexen said:
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
Click to expand...
Click to collapse
Just wondering what is achieved by going back to 7.2?
What do you mean "going back"?
Right now the 7.2 is the official and latest firmware.
I was unable to get my hands in the 7.2.1 but guess it might have been a testversion for certain models only.
I wasted a few hours trying to fix the system image.
First stage was only to get the basic "features" back, like full ADB support, enabling the support to use SU and busybox....
Just what is required to actually allow these nice apps we like to gain root to work.
This backfired badly as right after the start the bootloader complained about the system being corrup and no override to get past this worked.
So of course I then removed the known restrictions from the bootloader...
As you guessed it the damn thing then did not even boot at all, just jumped right into the (locked) recovery mode.
A half decent comparision with my last manual root on a tv box that was a success showed I still did the right things...
If anyone wondered why we needed a new bootloader for the support of smart helpers an some codes stuff:
We didn't as all this could have been done with the 7.1 bootloader as well.
Since my root attempts so far all ended either in disaster or in a root access that failed shortly after/corrupted the system, I took a look of the general kernel changes that were published for other devices.
Before I could find anything meaningful I realised the 4.9 kernel is actually a requirement for Android Pie!
With that info sorted I started digging inti the new "security" features Pie can offer.
I will try to keep it simple and to the stuff that actually concerns us for rooting purposes:
The new boot process with Pie is aimed at being secure from the hardware level up and all the way into the system partion once the boot is completed.
So the hardware checks if the bootloader is actually usable - we had that for a long time, nothing new.
Once the bootloader starts and reaches the point of actually getting somewhere, all partitions required will be checks by either a hash check or a trusted certificate gererated at boot time that is compared to the previous certificate.
Only if that is fine the bootloader will call upon the system and vendor partitions.
The handover of control from bootloader to the system is made far more secure as well.
SELinux is called early on to ensure that only trusted apps and tasks can work but also to all a new control level.
System related apps no longer run as root or with special permissions.
Instead every single app and service runs as its own user!
And under SELinux conditions this means nothing can access anything that it is not entitled to unless included as a user for the other app.
And with that sorted the vendor stuff is called to ensure all hardware and vendor related stuff is still genuine - this include the required certs but also the recovery and bootloader hash codes and certs.
So if something is fishy either SELinux will stop us or the vendor stuff will just overwrite it all.
Once we finally reach the system stage the recovery is checked if called from within the system, if fully implemented it could mean that using an official update on a modded firmware will delete all data as the encryption from the old system is declared invalid.
Sadly it does not stop there because even with full rigths (faked or otherwise) to access the system partition with write access we still can not just change things.
If something belongs to a user (a secure app) than a change will corrupt the system.
To overcome all this without using vulnerabilities that so far no one has found, a compatible userdebug release has to be created from the official user firmware.
DM-Verity needs to be disabled as well as all partition encryption stuff.
The bootloader needs to be adjusted to reflect these changes and the required turst certificates generated and included in both system and boot images.
The only problem here is that the kernel won't allow these changes unless it itself is a userdebug kernel.
After that it is only the little efford to go through about 60 different scripts to remove or redirect the calls for all boot and system security related things.
If then by some chance all this actually boots up and goes all the way into a usable homescreen the entire stuff needs to be secured again.
This time so that the final system has a correct cert and checksum that matches those we need to include in the bootloader.
Anyone knows how to gain full access to the trusted keystore on the 4.9 kernel? LOL
For the moment I don't really care about all the stuff above.
I would be happy to figue out what to make out of these new fstab configurations without the vital partitions listed.
The real aprtitions used have not changed but it is impossible include them in the fastab, doing so causes the bootloader to fail.
Presumably because the kernel realised we try to get around the verification process.
This and some other minor things are also the reason TWRP fails so badly, same for the stock recovery by the way.
Since TWRP is toy a lot us like:
TWRP and 7.2....
Without a system partion in the bootloader fastab TWRP can not mount it.
Same for all other things TWRP needs to mount as it simply does not have the right to access these areas.
To make things worse, we need system access to even start TWRP through fastboot.
So, now matter if we flash or start it through fastboot: The bootloader and system will realise our recovery does not match the checksum.
What does al this now mean in terms a lot more people are able to understand?
Let me try...
Imagine the 7.2 in a running version would be just some encrypted file with a lot of folders in it.
And like PGP or other encryptions software we know there is a private and a public key.
With the public key you can see a lot and use most the encrypted file - but only to a level that is required, nothing above your low level clearance.
For every attempt to write into this file or to make changes we need the private key.
If you follow so far then lets just say the recovery (stock) and Fastboot can be, to some extent, used for this access.
But since every folder in the encrypted file also uses private and public keys it is like tracing a tree.
Although it is getting too long, let me give you the example of just adding SU to the sytem partition:
Adding SU into the system image is no big deal.
Singing this image to get a usable key and including this key into the keystore is.
Assume we would just be able to do it....
SU needs to be called quite early in the boot process.
It then elevates the access level for certain things and also intercepts all root related requests from apps and services.
Except of course those that already had these rights by default.
Problem here is that adding the scripts we need plus changing some others means violating the tree of trust on the device and we get locked out.
Finding a spot to add the required rights for SU might be still possible.
On the other hand it will be impossible to give SU any rights or access to "trusted user" owned parts, files, folders, partitions....
The entire concept of SU just fails.
I will have to check how much of the new features are active in the 7.2 kernel that hinder us.
If I find enough it might be possible it enough to call for a Magisk update.
But I guess it is of little use for just one set of devices, so maybe once more devices on the 4.9 kernel fail to work with Magisk it will be easier to spot a usable pattern.
In case someone else if already working ona mdified system: Please let me know how you made it boot after the changes
Shield Tv 16 2017 - OTA update 7.2.1 Ready for updating
Im on 7.1. I have been waiting for 7.2 developer image, which is now out and just noticed 7.2.1 is available OTA. I'm really confused what to do. I want to keep root without bricking my Shield. Should I Stay with what I have as it is running well.
I am not even sure if it is safe trying to update to dev 7.2 image (or if I would want to) by hooking to computer and using ADB Fastboot tools.
Is there any good reason to update to 7.2 or 7.21? and if so how would I go about doing it? Which program is good for flashing developer images or OTA updates. I used to use flash-fire, which seems to be obsolete now and have heard TWRP is incompatible rooting with SU with OREO updates????
Should I play it safe and stay with what I have rather than experiment and end up with a brick? (wouldn't be the first time)
Anyone know if 7.21 is some-kind of bug fix?
Alot of questions but hope someone has some answers.
Thanks for any info.
"You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door "
My fastboot issue
Yeah, i think i busted the microusb somehow with a faulty usb hub, whenever i plug the usb to my raspberrypi/windows box(for adb/fastboot) now, it turns off all usb ports on the pi aswell as the windows box, even when the shield is unplugged, some sort of earth problem maybe
......all i have is adb over network, adb reboot bootloader simply reboots back to system, adb reboot recovery works though.
ive read that fastboot over tcp(ethernet) had been introduced a couple of android versions ago, but i dont think its been implemented in our shields
infact heres a link
https://www.androidpolice.com/2016/...-capabilities-wireless-flashing-isnt-far-off/
Looks like it needs to be specifically added onto a build
As far as you making a stock root build, if you can, that would awesome, more then awesome, but if it becomes more work then you thought dont worry about it, its not like their making it easy
Also, sounds like 4.9/future android is gonna be a nightmare for root......... having the ability to root so that the option is there to see whats going on in the background of these devices, these devices posessing cameras/microphones/old+latest sensors/personal files/personal info, which reside on our personal beings or in our homes........is just one reason why i dont want to see root go away
So what is the purpose of the developer image of 7.2?
Rather, I know the stated purpose of the developer image, but if it is locked in the way described it sounds like the benefit is negated for typical developers.
(e.g. sometimes I debug an application without permissions in order to benchmark or debug a problem).
For casual users of the shield, using ad blockers and whatnot, is there any benefit to derive from installing the developer rom over stock? Does "adb root" still work?
What is left as the difference. It doesn't sound like they produced a userdebug build of the OS.
Thanks
The 2 new updates are horrible. I have gone back to 7.1. They have crippled my shield. I'll wait for a new update.