I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Enough. Seriously.....
Keep it clean, and on-topic... The rules are there for a reason. Don't remember them? HERE you go.
Adromir said:
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Click to expand...
Click to collapse
If you want the files
Then can you please update your Sheild tv to the latest firmware for us 7.2.2
An back up the recovery.img
An back up your build.prob
Because I can't help you! I refuse!
Thx again have a great day
i hope you can port the twrp to nvidia sheild tv thx
Foster_e (Shield TV 2015 16GB) - 7.2.2 (30.7.130.7)
recovery.img + build.prop
https://drive.google.com/open?id=18E_u8as1E9dstmRtRwPb97hALdmsrdsc
The recovery is dumped directly from
Code:
/dev/block/platform/sdhci-tegra.3/by-name/SOS -> /dev/block/mmcblk0p16
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Downunder35m said:
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Click to expand...
Click to collapse
So if I understand you correctly the only way that a recent version of TWRP would work on 7.21 and above are if you have a "rooted" developer image? I have stayed with 7.1 (rooted with a flashed TWRP recovery) My expectation is that Ill stay with it until a stable version is released.
Odd thing is every OTA notification I get refuses to install. It just boots to TWRP without updating. I even opted in for the 7.2.2 beta updates and the shield refuses to update. Kinda thankful as others seem to have so many issues, just not worth it until 7.3 is released perhaps?
Any decent update is worth applying.
But if you ask if it is worth it for those really needing full root access then the answer is no.
The cummunity behind the shield might not be as big as behing Samsung devices but I am sure something will be figured out sooner or later.
@Downunder35m : As I mentioned in a deleted Post, I know how to get these Files from the recovery images. But they are Still 7.2.1 and as 7.2.2 already I didn't see a point in starting with already Outdated Files.
What kind of Things have you been trying already? My Approach was, that maybe TWRP hangs itself, because it can't find the Vendor and system Partition. After unpacking the recovery.img i found out, that the partitions still get mounted, but not over over the fstab anymore but single commands in some init scripts. So my Idea was to patch the kernel of the recovery image with a proper fstab and then use that to build a twrp around it, with the modified boot image. But sadly the resulting TWRP exceeded the Partitionsize. But i didn't set up the Source Tree to compile correctly, because I assumed that with such a breaking approach nvidia did at least moved onward to Android 8.1 ..
A real life job sadly limits my time far more than what I would like.
So maybe my failures are of use to you...
Lets start with the basics:
(All for the 2017 model!)
Firstly, the bootloader has changed and now enforces basically everything Google has on offer.
This means you can not just boot into a custom recovery because the bootloader does not accept it as genuine.
Lets say you get around this problem by, dor example, compiling TWRP from source and with the not yet realesed NVidia 7.2 sources.
There might be other ways but right now I think we can't get around compiling it from scratch.
Once you are able to somehow properly boot into TWRP there is more problems:
A lot if not all special rights and permissions are now handled almost exclusively by the DTB, or to be precise the DTS, which is compiled during boot.
By default TWRP does not make any use of the DTB but instead relies only on the FSTAB configuration.
And since TWRP is not an authorised service, task or app the bootloader won't provide the required rights.
The system partition stays invisible, the vendor part locked and since TWRP is required to copy or store at least some things somewhere this is detected as a possible intrusion.
As that the bootloader now marks the entire system as compromised - the dreaded corrupted system message appears and the system fails to boot.
You could tweak the init files, get the complete FSTAB info from the plat - and nonplat_file_contexts and even fiddle with the rest.
Then you get this happy feeling of a booting TWRP, pull a backup and think all is fine.
That it until you try to reboot and nothing works anymore.
The backup is useless as firstly you can not write it back and secondly it will be encrypted or otherwise corrupt.
To be able to use TWRP ADBD must be able to run in root mode, this is not possible by default on a user or release build, which NVidia now provides as a "developer" firmware.
A bootloader set to enforce all SeLinux and DM-Verity funtions will not allow any vital modifications to any vital part of the system.
In theory you must first at least free the bootloader (we can not do that) or destroy the safety, like by using a modified DTB.
Then you must make sure that you modifiy the prop files so full ADB and ADBD rights are available where they are needed.
After that TRWP will run just fine but it creates a cricle that first needs to be broken somehow
No root rights means no TWRP, no TWRP means no mods to the system.
Magisk currently fails to help us as it does not make use of DTB features at this stage.
And if you ask me then messing with the DTB can backfire badly.
Unlike normal firmwares we won't get a DTB partition included in the boot image or kernel image.
So once the dTB is stuffed too much it will be hard to impossible to install a genuine or custom firmware.
Once Pie comes out this will be worse.
Here the DTB too will be protected and generated/checked during boot.
Unless NVidia wakes up and removes these restrictions from the developer firmwares we will be locked out until someone finds a way to restore full root rights.
Right now I am hopin they will still release the full sources one day.
With a massive effors one could then just compile a normal userdebug firmware and all is fine once more.
Any luck yet? I upgraded one of my Shield TV to 7.2.2 from 7.2.1 dev root and want to install Magisk....
Thanks!
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
UPDATE: Boots but not working correctly so removed links
leezaal said:
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
---------- Post added at 07:06 PM ---------- Previous post was at 07:05 PM ----------
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
Click to expand...
Click to collapse
Every time i open recovery it works, but after trying to reboot it bootloops at nvidia. I flash-all and it works again until i enter recovery (then botloops again on reboot). Am i missing something? (shield 2017 7.2.3 dev edition)
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1BCfXg9pUpFm_3sPXp_nEwBlkNU9nelkg/view?usp=sharing
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
there is always the bug for 4k screen display?
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
Many thanks i renamed this to recovery.img and renamed magisk boot img to boot.img reflashed both as part of the whole 7.2.3 dev OS shield tv 2017 image.
booted into TWRP via adb from my pc it loads up fine on my LG 43" 4k tv no problem rebooted and got back into 7.2.3 also without any issues
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
twrp seems complicated to be functional lately, the same on my mi max 3, but orange Fox might be better on Shield
leezaal said:
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
Click to expand...
Click to collapse
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
rootfan said:
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
Click to expand...
Click to collapse
Thanks for the great feedback will DL the updated TWRP and give it a go will report back shortly
UPDATE: 100% working ! Amazing work all partitions mount etc no problem FULLY working TWRP on my 4k TV too
Related
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.
Ok So I have a Nextbook NX16A10132S Ares 10A
I have TWRP custom recovery installed on it that I used from the Ares 8A.
I've tried flashing the Ares 8A rom, the Remix OS rom for it but no luck.
https://forum.xda-developers.com/remix/supported-devices/port-remix-os-2-0-nextbook-ares-8-t3498015
gives an error does not installed..FML.
So then I found a site with a option to restore this backup for TWRP after just putting it in the backup folder for TWRP.
This I was able to do, it installs the system not the boot part of this backup, but it still doesnt boot into the system.
Literally if anyone has a Ares 10A 11A any ****ing that close to this system that they have TWRP/root on and woul back it up so I can restore it..you will literally have my eternal thanks. Or really anyone else that could get a rom that would work for this intel atom based android tablet that has driven me insane.
I am also at a loss with this Nextbook tablet as well. A customer of mine brought me one that has an activation lock on it. She got ripped off and bought it 2nd hand and didn't know about the lock until it was too late and seller disappeared on her. So now i'm trying to help her figure out a way to at least bypass the activation in anyway. I tried using remix OS but that didn't work, so I am trying Pheonix OS.
have same tablet and twrp backup
i have the same tablet just been playing with it i have a twrp backup image if you need it its incomplete as my version of twrp cant backup the data partition let me know how and where to get the image file to you guys
mi useing twrp meant for ares 8 tablet it works almost perfectly i also have a image file made with nandroid overthe air app but the backup files it makes are too llarge not broken up into 1 gig partials like twrp does
can contact me directly at [email protected]
I gave a working system image made from my unencrypted rooted ares 10a If your bricked you cand hold volume down buttom while plug in usb to carde keep holding vol down button and tablet will boot into recovery from ther you can data wipe or factory restore and make a backipimage vamprila has a good root solution that supplies restore and boot images to flash as well
Decrypt ares 10a
Could you explain how I decrypt my ares 10a I can't find any steps on xda
Nextbook 10
killainferno said:
I am also at a loss with this Nextbook tablet as well. A customer of mine brought me one that has an activation lock on it. She got ripped off and bought it 2nd hand and didn't know about the lock until it was too late and seller disappeared on her. So now i'm trying to help her figure out a way to at least bypass the activation in anyway. I tried using remix OS but that didn't work, so I am trying Pheonix OS.
Click to expand...
Click to collapse
I have a similar problem. I bought this one second hand. And what a bargain it's been. I can't get past the activation lock. Please help. It's nice to know I'm not alone in this Savage world lol
trying to root nx16a10132s need twrp stock boot.img
read thru the root ares 8A with android 6.0.1 thread read it all then this rooting stuff starts to make sense does anyone have the stock boot.img and or stock sys.img you can use the twrp from this post 8A's twrp but HAVE TO HAVE a fixed boot.img before you do anything but twrp backup the boot.img and the sys.img and data.img (the data.img is complicated to get right) another member says he'll fix the 8A boot.img he may do the same thing for us if we can get hmi the 10a boot.img maybe but i think its any of ours only hope. cant really root with out it being modified. the boot file should be areound 30Mb so if you have a stook boot contact me and i'll walk you thru temp twrp extracting it nextbook has changed up thier security measures soo DONT change anything until we all get the modifies boot.img if some one is dareing there are posts on how to modify or repack the boot.img i aint that good yet its beyond me still but it can be done by someone who is a little more knowledgeable also post whick build your device is what kernal it uses blah blah all the stuff under settings>about tablet> these numbers are important if you dont use the matching versions you will end up with no wifi no bleutooth and no sound I've seen posts on how to get around the activation code on the thread i mentioned READ the WHOLE threade before you do anything by the time you finish it LOTS more stuff will make sense and you'll say F**K i so luck i aint really screwed my tablet up
Code:
billybleu97 said:
read thru the root ares 8A with android 6.0.1 thread read it all then this rooting stuff starts to make sense does anyone have the stock boot.img and or stock sys.img you can use the twrp from this post 8A's twrp but HAVE TO HAVE a fixed boot.img before you do anything but twrp backup the boot.img and the sys.img and data.img (the data.img is complicated to get right) another member says he'll fix the 8A boot.img he may do the same thing for us if we can get hmi the 10a boot.img maybe but i think its any of ours only hope. cant really root with out it being modified. the boot file should be areound 30Mb so if you have a stook boot contact me and i'll walk you thru temp twrp extracting it nextbook has changed up thier security measures soo DONT change anything until we all get the modifies boot.img if some one is dareing there are posts on how to modify or repack the boot.img i aint that good yet its beyond me still but it can be done by someone who is a little more knowledgeable also post whick build your device is what kernal it uses blah blah all the stuff under settings>about tablet> these numbers are important if you dont use the matching versions you will end up with no wifi no bleutooth and no sound I've seen posts on how to get around the activation code on the thread i mentioned READ the WHOLE threade before you do anything by the time you finish it LOTS more stuff will make sense and you'll say F**K i so luck i aint really screwed my tablet up
Click to expand...
Click to collapse
I am shocked that the custom twrp, that vampirefo made, that I provided in my ares 8a thread for the nextbook ares 8a, would even work for this tablet?
temp booting twrp is used to create a backup of the original boot.img.
I then unpack it and remove the encryption flag and dm-verity flags, then repack it.
In order for the data partition to be unencypted after this, the data partition must be deleted. you will loose all data on the data partition.
when the tablet is booted with the new, modified boot.img, a new, unencrypted, data partition is created. your old data partition is not magically unecrypted, so you need to backup any important files through, for example and mtp connection to a computer. that also means that only certain types of data can be backed up this way from the internal sd card and the external sd card. any apps you have will have to be reinstalled from scratch. any game and app data will probably be lost also unless you can back it up also some way.
deleting your existing data partition so a new, unencypted on can be created, is the only way I know how to do this.
The user who found a solution as to how to disable the activation of the tablet said he would post how he did it in my thread, but never did and I don't know how to do it. I bought mine from the only legitimate source I know that sells it: Walmart. I purchased my tablets from the store I work at. An activation code is printed on the receipt, and is unique to each tablet.
There are some bits and pieces of what he did to defeat activation, in my thread, but they are somewhat vague. Maybe you can PM him to get him to answer.
Most of the users I have helped and modified boot.images for different versions of the 8a, have taken my modified boot.imgs and ran, no longer to be seen.
When I asked them for supersu systemless, patched images, they never even had the courtesy to even respond to me.
I have become disillusioned by ungrateful xda members who feel entitled and don't give to the community in return.
However I am still, irregardless, trying to help if possible.
I tried to learn how how build twrp myself, but it is a very, very steep learning curve to do it. And it can only be done with a linux computer with lots of disk space to download the twrp source files. That is way beyond my abilities, currently. However, I do run Linux Mint Mate, most of the time now, as it boots and runs much faster than my windows 7 drive, despite being on a persistent, casper-rw, usb key, 32gb.
---------- Post added at 02:51 AM ---------- Previous post was at 02:20 AM ----------
A backed up data partition from the original, stock tablet, doesn't work on the rooted ares 8a either, because it is an encrypted backup. A modified boot.img removes the encyption flag and verified boot, but this does not decrypt an existing data backup in twrp. Hence the need to:
Code:
fastboot format userdata
, hit return
Code:
fastboot format cache
, hit return
Can you successfully flash supersu systemless with vampirefos twrp for the 8a on your 10a and gain sucessful root access? And of course the userdata must be deleted with the above commands, in fastboot mode, if supersu can be sucessfully flashed and works. I use jrummy's root test app, from the play store. I also always flash yds busybox in twrp, also, after supersu flash.
UPDATE: I think you need to delete userdata in fastboot, before you flash supersu in twrp, not after. I am tired so my memory is not as good, so I believe that is the safer way to do it, not after flashing supersu.
I have not written this in the 8a thread, but currently I recommend supersu in its default systemless mode: supersu 2.82 SR5, from the supersu beta thread.
I previously recommended the unoffical, systemmode supersu for the 1.0.8, 1.1.1 and 1.2.0 versions of the 8a.
UPDATE: upon looking at the specs of the ares 10a they are the same as the 8a with it having twice the internal storage space as the 8a: 32gbs vs. the 8a's 16gbs. I am not sure how this would affect the 8a twrp build if used on the 10a the android partitions are more than likely a different size.
a good android utility for determining the partition sizes is called diskinfo.
Here are the partitions for the ares 8a:
system
cache
data
metadata
boot
recovery
misc
bootloader
bootloader2
persistent
config
metadata
sd card
external SD
There are others, but those above are the main ones
PLEASE NOTE: THIS MAY NOT WORK FOR YOUR 10A. THIS MAY BRICK YOUR DEVICE. IT IS ALL THEORY BASED ON THE 8A, WHICH HAS ALMOST IDENTICAL HARDWARE EXCEPT FOR ONLY HALF OF THE 10A'S 32GB STORAGE SPACE.
SINCE VAMPIREFO'S TWRP WAS BUILT FOR THE 8A, THERE MAY BE UNEXPECTED CONSEQUENCES!
YOU HAVE BEEN WARNED! DANGER, WILL ROBINSON! (A LOST IN SPACE REFERENCE, FOR THE YOUNG.)
the bootloader must first be unlocked. See my ares 8a thread for very detailed info on how to do the below steps. One updated change from it though: YOU MUST USE THE OFFICIAL SUPERSU.ZIP, WHICH INSTALLS AS SYSTEMLESS. IT WILL ALSO PATCH YOUR BOOT.IMG TO DISABLE ENCRYPTION AND DISABLE DM_VERITY (ANDROID VERIFIED BOOT), SO NO NEED FOR A USER MODIFIED BOOT.IMG.
THE ORIGINAL UNOFFICIAL SYSTEMMODE SUPERSU I HAD PREVIOUSLY PROVIDED DOES NOT PATCH THE BOOT.IMG TO REMOVE ENCRYPTION AND DM_VERITY.
Code:
fastboot format userdata
hit enter, wait to complete.
Code:
fastboot format cache
hit enter, wait to complete.
this will delete all user data so a new, unencrypted data partition can be created.
Of course, any data will be deleted so a backup is needed through, for example, mtp to a computer. user apps will have to be reinstalled. System apps will still be there.
it look like on should then be able to temp boot the 8a twrp recovery in fastboot mode by issuing:
Code:
fastboot boot Ares8A_recovery_twrp.img
then once into twrp hit the install button and select the SR5-SuperSU-v2.82-SR5-20171001224502.zip systemless and flash it. it must already be on the internal sd card, or the external sd card. If all goes well you should see a message in twrp that supersu has successfully patched your boot.img and backed up the original to a new folder created in the root of the device, called .subackup. the files in that are the originals extracted from your stock boot.img.
The next step is to reboot. The first boot will take a very long time. The last time I did it on one of my 8a's, it took ~5 minutes to get past the animated nextbook animation before going to the android security, usb debugging prompt and setup screen.
See my ares 8a root thread, for better details
Question about ares 10a nextbook
i have brand new ares 10a but dont have an activation code anyway around it? Can i install rom are what? thanks god bless
there was someone who uninstalled one of the system apps and it help get rid of activation code need read thru root ares8 thread there was another person that installed a differnt rom and did the same thing but i wouldnt advise that for the ares10a..thers a link on the nextbook site that is supposed to give you the code if you put in a number from the tablets box but i dont know if thats a 100% solution either but its a starting place to look
thanks I'll check into it once i can someone on ebay is sale the code $15 and info he needs is I believe its all done online for free. LOL
I'll need some information from the tablet itself
YOU WILL NEED
1. a mini-usb cable that plugs into the tablet - this is the same type of cable that charges most android phones (not an apple cord) or a playstation 4 charging cable will work too
2. Laptop or desktop computer with internet access - preferably running windows 8 or windows 10 (you can use windows 7, but you may have to download drivers for it to recognize the tablet)
I will need you to copy a file from the tablet to your desktop and open it - the copy and paste it into this message for me along with your serial number
are you able to do this?
If so, then you can go ahead and pay and i will send the rest of the instructions
my experiance dont trust ebay
I've been looking for some solutions for my ares 10a for months now but NEVER have i seen anything like this ebay guy is offerong... sound to good to be true.....read thru the ares 8a threads 2 hrs of reading may save you a brick tablet or just keep you from getting screwed by a stranget from ebay if you dont find anythig then give em a ty if you risk it
tone4life said:
thanks I'll check into it once i can someone on ebay is sale the code $15 and info he needs is I believe its all done online for free. LOL
I'll need some information from the tablet itself
YOU WILL NEED
1. a mini-usb cable that plugs into the tablet - this is the same type of cable that charges most android phones (not an apple cord) or a playstation 4 charging cable will work too
2. Laptop or desktop computer with internet access - preferably running windows 8 or windows 10 (you can use windows 7, but you may have to download drivers for it to recognize the tablet)
I will need you to copy a file from the tablet to your desktop and open it - the copy and paste it into this message for me along with your serial number
are you able to do this?
If so, then you can go ahead and pay and i will send the rest of the instructions
Click to expand...
Click to collapse
I had the same issue with "/data" not being mountable. I used twrp to wipe that partition and make a new one. There's something wierd with it because i wasn't able to root and install twrp in the recovery partition until I did the wipe. It would default back to stock image when it had issues booting
oxendine9381 said:
I had the same issue with "/data" not being mountable. I used twrp to wipe that partition and make a new one. There's something wierd with it because i wasn't able to root and install twrp in the recovery partition until I did the wipe. It would default back to stock image when it had issues booting
Click to expand...
Click to collapse
My guess would be that your original data was not mounted because it is encrypted. With a modified boot.img to remove encryption and dm-verity, the userdata must be wiped to create a new, unencrypted, data partition, on next boot.
I do not own an Ares 10A, as was stated a few posts above, but I was wondering if any of the info I provided concerning the Ares 8A was useful in getting root on your 10A's?
Thanks
eternal2u said:
Ok So I have a Nextbook NX16A10132S Ares 10A
I have TWRP custom recovery installed on it that I used from the Ares 8A.
I've tried flashing the Ares 8A rom, the Remix OS rom for it but no luck.
https://forum.xda-developers.com/remix/supported-devices/port-remix-os-2-0-nextbook-ares-8-t3498015
gives an error does not installed..FML.
So then I found a site with a option to restore this backup for TWRP after just putting it in the backup folder for TWRP.
This I was able to do, it installs the system not the boot part of this backup, but it still doesnt boot into the system.
Literally if anyone has a Ares 10A 11A any ****ing that close to this system that they have TWRP/root on and woul back it up so I can restore it..you will literally have my eternal thanks. Or really anyone else that could get a rom that would work for this intel atom based android tablet that has driven me insane.
Click to expand...
Click to collapse
GO TO [email protected] FOR FAST HELP
Can rooting help Nextbook NX16A10132S Ares 10A...
Do we have a forum for fixing the bad implementation of Android 6 on the nx16a10132s,—PC Windows 7 sees it as an mp3 player, and its file Modification dates are fake Creation dates of every Move/Copy... 14 GB of these useless Modification dates, of 17 GB usable of 24 GB listed by the filename-abbreviating file manager 'garbage-on-top-of-garbage' of 32 GB advertised... (Rooting doesn't fix this, Or, does it,—Rooting just makes it hang faster—true, or not, true...)
I have a next book 10a and I don't have the activation code. What can I do. PLEASE HELP ME OUT
I was able to get the offending lock-screen app passcode program in the Nextbook NX16A10132S Ares 10A removed. On kernel 3.14.64-x86_64 android 6.0.1 -- This method erased all user data on the device and returned it to factory settings -- only without the lock screen program.
With the device turned off and unplugged, I hold down the power and the volume button that's farther from the power button until the system boots into the fastboot screen. I plug in the USB to the computer and use the Android Developer tool: Fastboot to unlock the boot loader:
fastboot flashing unlock
fastboot format userdata
fastboot format cache
I then tell the device to shutdown.
I Download and Extract the Ares8A_recovery_twrp.img from this thread, and put it into the computer's working directory I'm using fastboot from:
https://forum.xda-developers.com/showpost.php?p=72970060&postcount=82
I unplug the USB and start it back up with the power and volume button again until the fastboot screen appears again. I then plug in the USB and run :
fastboot boot Ares8A_recovery_twrp.img
Once TWRP is running, I click the Mount button on the tablet and check the box to mount System.
Then I use ADB SHELL to rename the bad application:
adb shell mv /system/app/VUDUStartWizard/VUDUStartWizard.apk /system/app/VUDUStartWizard/VUDUStartWizard.apk.bak
Then I shutdown the device, and start it back up normally. Then it works for me with no lock screen.
Ok originally I had come in here because of boot loop caused after removal of specific apps. This has been an issue even before I managed to get it rooted, I still wouldn't mind a streamlined fast alternate rom for my nxa10 but figured out the boot loop issue. Just go back into twrp and factory reset... it wont replace the apps you removed... kind of a weird roundabout way to debloat but hey if it works haha.
Me too!!! I need an Ares 10a ROM
I trashed the system partition on my Ares 10a. I just need A ROM... any working rooted ROM for a 10a. I had a ROM for an 8a that worked just fine... until I killed it.
So please, if anyone knows where to get a working 10a or 8a ROM would you let me know? Thanks.
UPDATED 2/19/2018
Almost enough here to start attempting debug builds... any other builders/devs out there working on this device? Hopefully some of this will be useful.
Minimal Omni device tree for TWRP (full lineage branch in progress as of 2/19/2018)
https://github.com/mightysween/android_device_motorola_payton
Proprietary blobs/vendor (initial push 2/19/2018):
https://github.com/mightysween/android_vendor_motorola_payton
Partition names/locations/mounts...maybe a few missing still:
https://docs.google.com/document/d/1EkPOkc8uUStKIjRGC2-4jkcXpxmj8v3piGPqZi9ctQM/edit?usp=drivesdk
7.1 KERNEL SOURCE:
https://github.com/MotorolaMobilityLLC/kernel-msm/tree/7.1.1-nougat-release-payton
8.0 KERNEL SOURCE:
https://github.com/MotorolaMobilityLLC/kernel-msm/releases/tag/MMI-OPW27.57-40
So what's the deal with the A/B partitions? I've seen that there are some lineage OS commits to handle the A/B partitions. Would it be possible to load an OS to the A partition and put the recovery on the B partition. I'm not familiar enough to know how much control of the boot process we can have with boot time commands. Does the bootloader have a boot to recovery option?
There doesn't seem to be a recovery partition in the list that you provided. I wonder what the fastboot commands look like... just thinking out loud on the internet. I don't have the phone yet, but I did have a look at Best Buy, so that practically makes me an expert. I have a N5X, so I'm lining up the successor for after its sudden, but inevitable betrayal.
gee one said:
So what's the deal with the A/B partitions? I've seen that there are some lineage OS commits to handle the A/B partitions. Would it be possible to load an OS to the A partition and put the recovery on the B partition. I'm not familiar enough to know how much control of the boot process we can have with boot time commands. Does the bootloader have a boot to recovery option?
There doesn't seem to be a recovery partition in the list that you provided. I wonder what the fastboot commands look like... just thinking out loud on the internet. I don't have the phone yet, but I did have a look at Best Buy, so that practically makes me an expert. I have a N5X, so I'm lining up the successor for after its sudden, but inevitable betrayal.
Click to expand...
Click to collapse
There is no traditional recovery partition...handled by boot. A/B is mainly to allow 'seamless' updates (as in OTA that downloads to the other partition for instant reboot). Bit more to it... if you want to read more, check out the Pixel forums.
Well... progress is being made. Wish there were others (there must be!) working on this.
I have the stock kernel, a VERY basic device tree, and cobbled-together vendor... syncing repos and will try to compile TWRP over the weekend. I do not expect it to work
Dealing with this right now on brunch...runs fine up until this point, appreciate any thoughts:
Starting build with ninja
ninja: Entering directory `.'
ninja: error: '/home/mightysween/android/omni/out/target/product/payton/obj/SHARED_LIBRARIES/libcryptfs_hw_intermediates/export_includes', needed by '/home/mightysween/android/omni/out/target/product/payton/obj/SHARED_LIBRARIES/libcryptfslollipop_intermediates/import_includes', missing and no known rule to make it
build/core/ninja.mk:157: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
Click to expand...
Click to collapse
Do I really need the lollipop libs???? Especially if I just want to compile TWRP and not full omni. Ahhhhhhh....so much fun
OK, got TWRP to compile
Need to do some testing in the emulator and double and triple check all sources and configs before even thinking about trying to boot it on the actual device.
But just troubleshooting at this point, so looking good for TWRP in coming days!
UPDATE: oops, totally compiled it with the wrong kernel. Haha... working through some defconfig issues, but hopefully nothing too crazy.
mightysween said:
OK, got TWRP to compile
Need to do some testing in the emulator and double and triple check all sources and configs before even thinking about trying to boot it on the actual device.
But just troubleshooting at this point, so looking good for TWRP in coming days!
Click to expand...
Click to collapse
I hope you can do it! Is the first step to get backups and ROMs. I don´t have the phone yet, but later the normal version that is sell in México and want to flash the Android One version (previously anyone get it working).
I'm returning my Amazon version of this phone and getting Project Fi version. I am willing to help in testing.
Well, my boot.img compiles fine... but will not boot to recovery. Given the fact that it is mostly guesswork on the device tree, I am not shocked.
Pushed my working tree to GitHub and will keep working on it...
https://github.com/mightysween/android_device_motorola_payton
Been looking at Pixel 2 TWRP Alpha... holy cow. So much more to it with this partitioning scheme.
mightysween said:
Well, my boot.img compiles fine... but will not boot to recovery. Given the fact that it is mostly guesswork on the device tree, I am not shocked.
Pushed my working tree to GitHub and will keep working on it...
https://github.com/mightysween/android_device_motorola_payton
Been looking at Pixel 2 TWRP Alpha... holy cow. So much more to it with this partitioning scheme.
Click to expand...
Click to collapse
Have not even peeked into the Pixel 2 forums. I'm afraid this seems to be another ballgame entirely. Do the new Pixel owners even have root passing safety net while allowing these security updates new android phones now get? Gah this is a mess
SR3TLAW said:
Have not even peeked into the Pixel 2 forums. I'm afraid this seems to be another ballgame entirely. Do the new Pixel owners even have root passing safety net while allowing these security updates new android phones now get? Gah this is a mess
Click to expand...
Click to collapse
TWRP has been worked on for Pixel2 by several people, including expert Dees Troy, and is still a heavy alpha. I feel pretty good about booting compiled boot images and not bricking on x4 (as far as I have gotten)
I have been compiling my own stuff for many years, and yes -- this new stuff is foreign. But, we will all learn and in a few weeks/months, there will be plenty of action on this device
mightysween said:
TWRP has been worked on for Pixel2 by several people, including expert Dees Troy, and is still a heavy alpha. I feel pretty good about booting compiled boot images and not bricking on x4 (as far as I have gotten)
I have been compiling my own stuff for many years, and yes -- this new stuff is foreign. But, we will all learn and in a few weeks/months, there will be plenty of action on this device
Click to expand...
Click to collapse
try using fixes from https://github.com/TeamWin/android_device_xiaomi_tissot tree. similar android one device!!
i.snehal.kiran said:
try using fixes from https://github.com/TeamWin/android_device_xiaomi_tissot tree. similar android one device!!
Click to expand...
Click to collapse
Thanks, picked up 3 changes from here already... will test them out soon!
So, I have checked out several XDA threads on this Xiaomi device (tissot) and I think it is going to help quite a bit with the A/B issues.
I am still, unfortunately stuck on getting TWRP to boot. Boot.img compiles fine and I can extract it and see TWRP has replaced stock recovery in the ramdisk, but it will not boot into recovery.
Ideally, we need a way to boot a TWRP image without flashing anything... easier said than done with devices that have recovery baked into the boot image. But once that works, we can extract just the ramdisk from my build and write a script to patch it into the stock boot image from the temporary TWRP running on the device.
Progress! New TWRP thread coming soon...
BTW, there is still a long way to go here... this was just a rudimentary test to get TWRP to boot. Need to start totally fresh with partitions before there is any attempt to actually use it!
Also -- my build environment is a total cluster after weeks of messing around. I need to wipe it and start over. That alone will take me a few days, and TWRP might take a few weeks more.
Incredible! Looking forward to having a custom recovery!
mightysween said:
Progress! New TWRP thread coming soon...
BTW, there is still a long way to go here... this was just a rudimentary test to get TWRP to boot. Need to start totally fresh with partitions before there is any attempt to actually use it!
Also -- my build environment is a total cluster after weeks of messing around. I need to wipe it and start over. That alone will take me a few days, and TWRP might take a few weeks more.
Click to expand...
Click to collapse
I hope later we can flash the Android One firmware on the retail Moto X4, I supose that OTA update will not work but at least we will have the lastest updates if someone make a flashable version
f3r.and0 said:
I hope later we can flash the Android One firmware on the retail Moto X4, I supose that OTA update will not work but at least we will have the lastest updates if someone make a flashable version
Click to expand...
Click to collapse
At the very least, we have the ability to create "nandroid" style backup from A1 device. Theoretically, that could allow anyone to install it...
But yes, in the long run, hopefully the actual firmware is released
mightysween said:
At the very least, we have the ability to create "nandroid" style backup from A1 device. Theoretically, that could allow anyone to install it...
But yes, in the long run, hopefully the actual firmware is released
Click to expand...
Click to collapse
Doesn't the nandroid (or for that matter Flashfire) backup contain personally unique identifiers?
DiDGR8 said:
Doesn't the nandroid (or for that matter Flashfire) backup contain personally unique identifiers?
Click to expand...
Click to collapse
Yes, technically... obviously would need to start with a fresh system and limit to non-data partitions.
No one needs to restore someone else's apps... just their boot/oem/system_image
mightysween said:
Yes, technically... obviously would need to start with a fresh system and limit to non-data partitions.
No one needs to restore someone else's apps... just their boot/oem/system_image
Click to expand...
Click to collapse
This just came to my mind, since this phone has 2 partitions for boot etc. --
Code:
mmcblk0p44: boot_a SIZE:65536 blocks
mmcblk0p45: boot_b
can't we make backup of boot_b ? it will be same as boot_a but unmodified i think ? i mean, use magisk/cf-autoroot/whatever to gain root on boot_a. and make backup of boot_b. so in case if we want to receive update, just restore back boot_b.img to boot_a slot and update through ota ? that way we can practically make full backup which is unmodified. ofc this is until we have fastboot image available and working TWRP.
also it seems all x4's are having same kernel according to this thread. although their build time is different.
Bricked your M5? Post here. I am one of three posters who have posted threads requesting assistance - we might as well create one thread where we can try and help each other.
My model? SHT-AL09 (C636). My story? I apparently made a bad change to my build.prop file, and had USB debugging disabled. I then probably dug myself a deeper hole trying to recover. I don't even get boot animation anymore. I'd happily pay someone to unbrick me.
The only potential progress I have made, is that I was able to install and successfully boot TWRP - although TWRP detects that I have no operating system installed and I am unable to mount any partitions except for my external SD card. Using TWRP's file manager, I can see that the system partition, for example, has not been entirely wiped, but many files seem to be missing. At the very least, TWRP allows me to turn the screen off without seeking to contantly reboot thereafter.
To install TWRP, I followed these instructions intended for Mate 9 owners:
duraaraa said:
This is TWRP to Mate 9/Android O, brought to you by FunkyHuawei.
It's just a preliminary build so I can't promise anything/everything will work! Keep that in mind. I'm not responsible if you brick your device.
EDIT: Does not work with Mate 10 series.
DOWNLOAD LINK:
https://drive.google.com/open?id=0B45NCsO2AL_1NEh2aDFLM3JlYkU
It works on the Android O build here:
https://www.reddit.com/r/FunkyHuawei/comments/75uwkd/october_12_first_official_android_o_beta_for/
and the official European beta.
To install:
First, have Android O running. Unlock the bootloader. Download the twrp image.
Then, run in fastboot mode:
fastboot flash recovery_ramdisk twrp_android_o_mate9_a1.img
Then, reboot holding volume up, and you've got TWRP!
Note: With the Android O update, it is no longer possible to flash the recovery2 partition. Furthermore, the names of the partitions have changed. Please keep that in mind, and don't mess around too much with TWRP, to be sure you don't brick your system!
Click to expand...
Click to collapse
Hmm ... I wanted to ask you whether you have the full OTA package for your device? So you should be able to extract all the partition images from there and to fastboot flash them. But I checked on HFF and I do not see a full OTA package matching your device yet.
AndDiSa said:
Hmm ... I wanted to ask you whether you have the full OTA package for your device? So you should be able to extract all the partition images from there and to fastboot flash them. But I checked on HFF and I do not see a full OTA package matching your device yet.
Click to expand...
Click to collapse
I've tried flashing system.img/ramdisk.img from the c00 package. Maybe I have to wait for c636 firmware, or maybe I have to flash additional .imgs. I am pretty sure that the specs and hardware I have are the same as the c00.
I've tried flashing the entire update.zip file in TWRP...but as noted TWRP is unable to mount internal storage. I'm not sure if I need to wipe and reformat first. I also have no clue whether the TWRP build I installed is properly compatible with the device. I had nothing to lose by giving it a shot.
thref23 said:
I've tried flashing system.img/ramdisk.img from the c00 package. Maybe I have to wait for c636 firmware, or maybe I have to flash additional .imgs. I am pretty sure that the specs and hardware I have are the same as the c00.
Click to expand...
Click to collapse
This will not work as the boot chain will be broken due to mismatching checksums. You need to have the correct images. To flash a OTA image you also need to have the standard recovery image installed ...
So...will someone correct please correct me if this is wrong?
If I were to flash a c00 oeminfo file, I could then install a c00 update.zip via dload folder?
Would c432 work as well (with a flashed oeminfo), even though the Euro hardware has different bands than my hardware?
There is now a full OTA on FF for C635.....still nothing for c636...
Finally, a full OTA is available for c636.
But the 'dload' method (update.app on an sd card) failed at 5%. And flashing ramdisk/recovery/erecovery/system images also failed.
Is this possibly because the OTA is B153, whereas my M5 was shipped B121?
(I hate to be that guy bumping his own thread, sorry)
I'm unbricked!
For those in a similar spot, looking to rebrand, or otherwise interested...
I finally e-mailed Funky Huawei for assistance. Their unbrick tool did not work. However, their e-recovery method worked perfectly (basically, you point your router's DNS to Funky Huawei, enter stock recovery and connect to wi-fi, and Funky Huawei's servers mimic Huawei's servers. If they do not have your firmware on their server, they will add it by request (provided it exists on the internet).
I paid $65 for a 30 day pass - a little steep, but I was impatient. I'm not sure if I could have gotten away with paying less. If you want to try and use my FH account over the next 30 days PM me (although I don't want to get carried away with that).
For those looking to rebrand, if you can flash an OEMinfo file successfully (FH has a rebrand tool and I have no clue how well it works), you should be able to use FH's erecovery method to flash firmware (don't blame me if something goes wrong).
One reason for the trouble I was having, if because I bootlooped after making a change to the vendor/build.prop file. This file was on the vendor partition, not the system partition, and for whatever reason the vendor partition cannot be flashed via fastboot (in theory it can be flashed, in reality it returns an error that doesn't have to do with the size of the partition).
Before reverting to FH, I finally got TWRP installled and functioning, and after all the attempts I made to recover my device, the same build.prop file which initially caused a bootloop was still in the /vendor folder. And TWRP wouldn't mount the system and vendor partitions as read/writeable - that was frustrating.
Now off to experiment with AOSP GSIs while I feel like I have little to lose...
Please help me
hello everyone,
i tried to rebrand my m5pro with help of ministryofsolutions. Something went wrong and my tablet (CMR-AL19) is stucked in the recovery mode. how can i fix it? Someone who ca help me? I will pay
Greeztings
Luigi
thref23 said:
Bricked your M5? Post here. I am one of three posters who have posted threads requesting assistance - we might as well create one thread where we can try and help each other.
My model? SHT-AL09 (C636). My story? I apparently made a bad change to my build.prop file, and had USB debugging disabled. I then probably dug myself a deeper hole trying to recover. I don't even get boot animation anymore. I'd happily pay someone to unbrick me.
The only potential progress I have made, is that I was able to install and successfully boot TWRP - although TWRP detects that I have no operating system installed and I am unable to mount any partitions except for my external SD card. Using TWRP's file manager, I can see that the system partition, for example, has not been entirely wiped, but many files seem to be missing. At the very least, TWRP allows me to turn the screen off without seeking to contantly reboot thereafter.
To install TWRP, I followed these instructions intended for Mate 9 owners:
Click to expand...
Click to collapse
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.