Linux Research - Shield Android TV General

I finally got a response from Gnurou about this and it seems very promising.
gnurou said:
I have almost nothing but good news about the X1:
- It is supported by upstream Linux
- It is supported by Nouveau (or rather will soon be, I need to
cleanup and send some patches but I have Mesa rendering stuff
already!)
The issue is that a lot of patches for X1 and its GPU are still
in-flight, but please check
https://github.com/Gnurou/linux/tree/staging/nouveau for something
that is up-to-date. You even have a tegra210-p2571-e01.dts device tree
that should be fit for SHIELD TV, if you can get it to interact with the bootloader.
I haven't played with SHIELD TV personally for lack of a device, but
if I can get my hands on one I will probably try to boot that very
configuration and see what happens.
Click to expand...
Click to collapse
One note is that his staging/nouveau branch doesn't have the DTS, but his staging/work branch does. I'm going to assume that's what he meant.
Unfortunately, like he mentioned, this isn't upstream yet. And apparently there's some discussion on how to implement the new platform in the upstream kernel. Guess for now that means we stick with Gnurou's forked kernel until that gets sorted out.
There's one major problem that needs solved (and I won't be able to actively debug and test it for a couple days). There's no known way to pass the bootloader a different dtb. My first thought is to use this patch temporarily to allow appending the dtb to the image. Now like the first reply to the patch states, this is a horrible idea, but it should at least get the device booting. Once I get multirom working, I can load in a new dtb before kexec which will be much cleaner. That doesn't help anyone that wants to fastboot boot, though. Anyone have any ideas on that?
When I'm able to run new builds and start testing this, I'll post more info. Just wanted to get this out there for other interested who might get it done first.

Steel01 said:
One note is that his staging/nouveau branch doesn't have the DTS, but his staging/work branch does. I'm going to assume that's what he meant..
Click to expand...
Click to collapse
You are correct, staging/work is the branch you should use for any upstream-based X1 work. staging/nouveau is my staging area for Nouveau-related patches. staging/work is the same branch merged with the latest -next and many staging Tegra-related patches (including decent X1 support) from the Tegra maintainer (tagr). These patches will make it upstream eventually, but it will take some time.
So yeah, staging/work is actually a linux-next with extra X1 support patches + a few other staging patches of mine, I know this sounds scary but we are careful to keep it in a decent shape.
Steel01 said:
There's one major problem that needs solved (and I won't be able to actively debug and test it for a couple days). There's no known way to pass the bootloader a different dtb. My first thought is to use this patch temporarily to allow appending the dtb to the image. Now like the first reply to the patch states, this is a horrible idea, but it should at least get the device booting. Once I get multirom working, I can load in a new dtb before kexec which will be much cleaner. That doesn't help anyone that wants to fastboot boot, though. Anyone have any ideas on that?.
Click to expand...
Click to collapse
Does bootloader unlocking/fastboot boot work as expected? I haven't been able to check so far.
Regarding device tree: it seems like Android and the bootloader use the same device tree, which is convenient but has the undesired side-effect that if you replace the DTB partition with an upstream DT, the bootloader doesn't work anymore and if you try to boot upstream with the Android device tree, you will have lots of features missing (if it boots at all).
That's something that really ought to be fixed in a future OTA. Can you state the problem precisely and what you think would be a good way to work it around? I can think of using a separate DT for Android, or maybe a way to embed the device tree in the boot image (although the boot image format doesn't seem to allows that?).
I will try to get my hands on a retail device so I can experiment with it myself as well, but not sure when that could happen.

Well, I tried to boot a kernel to no avail, just a black screen. I reverted:
https://github.com/Gnurou/linux/commit/61bd93ce801bb6df36eda257a9d2d16c02863cdd
and applied (not cleanly, one chunk had to be manually patched):
http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03053.html
Nothing. I used an old bbfs from Roth testing. But I didn't spend too much time on it, so it might be as simple as early printk not being on and the kernel was trying to tell me I'm stupid, but couldn't.
Bootloader requests? Well first, the command line support needs fixed. I was working on porting CM and added the disable selinux kernel cmdline flag like I did for the Portable and Tablet and it got completely ignored. That's embedded in the boot image, haven't tried fastboot -c.
So, when I saw the question on how to handle dtbs, I had what I thought was a crazy idea, but turns out I wasn't the first.
http://www.cnx-software.com/2014/05...device-tree-file-from-android-firmware-files/
Hijack the second boot section of the boot image and stuff the dtb in there.
The precise problem is that the bootloader doesn't support swapping dtbs. And worse as you stated, the bootloader won't work unless an android dtb is on the dtb partition. (Incidentally, that partition just got added to my list of never touch partitions on my Shield devices...)
Oh, and yes, fastboot oem unlock and boot work as expected. As does flash and erase. It justctakes the next half of forever to erase the pros user data partition.
I finally had a breakthrough on CM, so I may not have as much time to tinker with this over the next couple days as I expected. But I'll try to get a basic bb booting as soon as I can. It just might drive me up a wall to stare at a black screen with no way to know what's wrong first...

@Gnurou: Any progress on the inside on this? Fastboot is even worse in the latest release. Can't bring it up via a hardware method (have to 'reboot bootloader' to get to it) and fastboot boot is completely broken, just hangs the system when passing it anything, official or not). So doing more testing on the consumer side is much more difficult. Especially since I still haven't figured out how to get kexec/multirom working still...

Hi! I still need to put my hands on a Shield device to be honest. I have been making progress on the GPU front though, to a point where acceleration is now starting to work with upstream to a point where it should be soon possible to use X.
Thanks for pinging me though, I will ask for a Shield retail device and see by myself what needs to be done.

Related

TWRP, ClockworkMod or other custom recovery available?

As topic says, is there a custom recovery available for R819 ?
I found TWRP for Chinese R819T version, but is it compatible also with the R819 ?
samusalo said:
As topic says, is there a custom recovery available for R819 ?
I found TWRP for Chinese R819T version, but is it compatible also with the R819 ?
Click to expand...
Click to collapse
Not yet. Dees_Troy is working on it now, he got an R819 a day or two ago. (Edit: oops, he doesn't have his yet, he was just working with someone else.)
I just got mine earlier today. Right now I am trying to get a complete return-to-stock package from Oppo. Yeah, I could extract everything and eventually build one myself, but it's SO much easier when the manufacturer provides it for you. Unfortunately it's the weekend and the Oppo guys are in a complete different timezone than I am. I think that was the main reason Dees_Troy is halted too - Trying to boot the image using "fastboot boot" doesn't work, and he's (understandably) nervous about flashing a recovery when he doesn't have a return-to-stock image.
Edit: FYI, motochopper works for rooting. It's a royal pain to get it working with this device on Windows machines, but on Linux, you only need to get ADB running by adding 0x22d9 to ~/.android/adb_usb.ini
Entropy512 said:
Not yet. Dees_Troy is working on it now, he got an R819 a day or two ago. (Edit: oops, he doesn't have his yet, he was just working with someone else.)
I just got mine earlier today. Right now I am trying to get a complete return-to-stock package from Oppo. Yeah, I could extract everything and eventually build one myself, but it's SO much easier when the manufacturer provides it for you. Unfortunately it's the weekend and the Oppo guys are in a complete different timezone than I am. I think that was the main reason Dees_Troy is halted too - Trying to boot the image using "fastboot boot" doesn't work, and he's (understandably) nervous about flashing a recovery when he doesn't have a return-to-stock image.
Edit: FYI, motochopper works for rooting. It's a royal pain to get it working with this device on Windows machines, but on Linux, you only need to get ADB running by adding 0x22d9 to ~/.android/adb_usb.ini
Click to expand...
Click to collapse
What about Kernel SOurces and Other Trees ?
GuneetAtwal said:
What about Kernel SOurces and Other Trees ?
Click to expand...
Click to collapse
https://github.com/oppo-source/R819-Kernel-Source-4.2
MediaTek's kernel build system gives me a headache... It's a mess. Also, there are some nasty licensing conflicts between various files there. It's better than no source at all, but there are some issues a few of us are in contact with Oppo to resolve. (Oppo has been EXTREMELY cooperative so far.)
The biggest problem is that right now fastboot won't allow you to flash or boot any kernel images, whether normal boot or recovery. This means that if you hose up a device by flashing a bad recovery or kernel, you've got a brick. Supposedly Oppo is also working on fixing this too.
I successfully wrote a test TWRP image that Dees_Troy provided me, but I'm not going to make it public for the following reasons:
1) MTK's dumchar driver used to read/write kernel and recovery partitions does not do any size enforcement. Backing up a kernel in recovery will result in a 4GB backup image at the moment... I've figured out how to fix the driver, however:
2) Being unable to recover from bricks using fastboot means that this thing is extremely dangerous
3) The fstab is probably still not right for the device
The biggest blocker is 2) above - once that's resolved it should be a matter of only a few days.
Edit: I was partially wrong. It's not possible to flash recovery from fastboot, but you can flash replacement boot images.
Entropy512 said:
https://github.com/oppo-source/R819-Kernel-Source-4.2
MediaTek's kernel build system gives me a headache... It's a mess. Also, there are some nasty licensing conflicts between various files there. It's better than no source at all, but there are some issues a few of us are in contact with Oppo to resolve. (Oppo has been EXTREMELY cooperative so far.)
The biggest problem is that right now fastboot won't allow you to flash or boot any kernel images, whether normal boot or recovery. This means that if you hose up a device by flashing a bad recovery or kernel, you've got a brick. Supposedly Oppo is also working on fixing this too.
I successfully wrote a test TWRP image that Dees_Troy provided me, but I'm not going to make it public for the following reasons:
1) MTK's dumchar driver used to read/write kernel and recovery partitions does not do any size enforcement. Backing up a kernel in recovery will result in a 4GB backup image at the moment... I've figured out how to fix the driver, however:
2) Being unable to recover from bricks using fastboot means that this thing is extremely dangerous
3) The fstab is probably still not right for the device
The biggest blocker is 2) above - once that's resolved it should be a matter of only a few days.
Edit: I was partially wrong. It's not possible to flash recovery from fastboot, but you can flash replacement boot images.
Click to expand...
Click to collapse
WEll it is same as Xperia C's Source and other Leaked Source :/ i Don't know why Mediatek don't make a Simple Filesystem like that of Nvidea and Qualcomm
i think it comes with cwm right,thats what a developer told me:fingers-crossed:
Zpik said:
i think it comes with cwm right,thats what a developer told me:fingers-crossed:
Click to expand...
Click to collapse
No, it does not. Stock Android "3e" recovery.
There's a TWRP image nearly ready, but who knows when it will be fully ready for public consumption. I won't be working on it (or anything else) at all this week for various reasons.

Switching from SuperSU to MagiskSU

Okay so after getting tired of safetynet and other issues Google has put on us I'm wanting to switch to magiskSU but Everytime I tried I bootloop and have to clean flash my rom. This is what I'm doing
1. Flashed unSU in twrp
2.flashed stock boot.img
3. Flashed the magisk.zip
4.got an error saying it failed to install magisk.zip
But whenever I try to reboot to system (I've tried reinstalling SuperSU and without reinstalling as well) I got a bootloop Everytime can someone instruct me or tell me what I'm doing wrong?
WeUseLord- said:
Okay so after getting tired of safetynet and other issues Google has put on us I'm wanting to switch to magiskSU but Everytime I tried I bootloop and have to clean flash my rom. This is what I'm doing
1. Flashed unSU in twrp
2.flashed stock boot.img
3. Flashed the magisk.zip
4.got an error saying it failed to install magisk.zip
But whenever I try to reboot to system (I've tried reinstalling SuperSU and without reinstalling as well) I got a bootloop Everytime can someone instruct me or tell me what I'm doing wrong?
Click to expand...
Click to collapse
What carrier/rom/update/etc?
WeUseLord- said:
Okay so after getting tired of safetynet and other issues Google has put on us I'm wanting to switch to magiskSU but Everytime I tried I bootloop and have to clean flash my rom. This is what I'm doing
1. Flashed unSU in twrp
2.flashed stock boot.img
3. Flashed the magisk.zip
4.got an error saying it failed to install magisk.zip
But whenever I try to reboot to system (I've tried reinstalling SuperSU and without reinstalling as well) I got a bootloop Everytime can someone instruct me or tell me what I'm doing wrong?
Click to expand...
Click to collapse
In Short. Currently for our device to have magisk, you need to use the boot image that @joemossjr and @Uzephi developed with Magisk support. Then install the magisk app. No zip install.
Refer to Joe's thread for the boot image at this link
https://forum.xda-developers.com/z2-force/how-to/how-to-root-moto-z2-force-t-mobile-t3672933
I would have went into detail and used a short link, but my head is currently throbbing so this is easier lol.
Edit: then realized your replied a minute before I Uzephi haha.
Uzephi said:
What carrier/rom/update/etc?
Click to expand...
Click to collapse
Spring stock rom on the original August update
Sent from my Moto Z (2) Force using XDA Labs
Acoustichayes said:
In Short. Currently for our device to have magisk, you need to use the boot image that @joemossjr and @Uzephi developed with Magisk support. Then install the magisk app. No zip install.
Refer to Joe's thread for the boot image at this link
https://forum.xda-developers.com/z2-force/how-to/how-to-root-moto-z2-force-t-mobile-t3672933
I would have went into detail and used a short link, but my head is currently throbbing so this is easier lol.
Click to expand...
Click to collapse
I know but when I tried that method and just installing the boot.img through twrp it failed and gave me a boot loop as well
Sent from my Moto Z (2) Force using XDA Labs
WeUseLord- said:
Spring stock rom on the original August update
Click to expand...
Click to collapse
I would suggest updating to November. I have a rooted magisk image, but you need to flash the decryption zip to get it to boot. If you update to November, I am going to release a flash-all type zip sometime today (after I fiddle with getting 4.4.107 upstream done) and working on a Google Pixel 2 skinned ROM for us here shortly with oem bloat completely removed
WeUseLord- said:
I know but when I tried that method and just installing the boot.img through twrp it failed and gave me a boot loop as well
Sent from my Moto Z (2) Force using XDA Labs
Click to expand...
Click to collapse
Have to ask this general base question of course lol. are you trying to dirty flash or did you do a full clean install?
But in general, what Uzephi said, as this is his project. I'll let him go ahead and take over. Goodluck
WeUseLord- said:
I know but when I tried that method and just installing the boot.img through twrp it failed and gave me a boot loop as well
Click to expand...
Click to collapse
You using stock kernel? To get crypto changes in 4.4.101-103 added, it breaks encryption on our phones and will cause a boot loop due to Motorola's dirty code. Hopefully when Oreo ROM drops (since Google is kinda telling oems to stay upstreamed) it will fix those issues in our stock ROMs.
Uzephi said:
I would suggest updating to November. I have a rooted magisk image, but you need to flash the decryption zip to get it to boot. If you update to November, I am going to release a flash-all type zip sometime today (after I fiddle with getting 4.4.107 upstream done) and working on a Google Pixel 2 skinned ROM for us here shortly with oem bloat completely removed
Click to expand...
Click to collapse
That's nice I think I'm gonna stick with SuperSU for now this phone is confusing
But one thing I must ask will we have a customisable rom like CM or something like that soon?
Sent from my Moto Z (2) Force using XDA Labs
WeUseLord- said:
That's nice I think I'm gonna stick with SuperSU for now this phone is confusing
But one thing I must ask will we have a customisable rom like CM or something like that soon?
Click to expand...
Click to collapse
Hard to say. Those of us that have tried hard bricked the device. Not readable via USB and wouldn't boot anything after the flash.
WeUseLord- said:
That's nice I think I'm gonna stick with SuperSU for now this phone is confusing
But one thing I must ask will we have a customisable rom like CM or something like that soon?
Sent from my Moto Z (2) Force using XDA Labs
Click to expand...
Click to collapse
To build off what Uzephi said. It's not that rom's wont be capable. It's just working with new things that are being implemented and changed until something starts going right. The jump to Nougat changed a lot of things with security and the switch to Oreo is changing even more that Google is wanting to push for android that inadvertently also affect security and compatibility.
This is speculation, but since they introduced Kotlin, I feel like they are trying to alter everything over the long run to become more streamline and compatible around it. Especially given they can control the progress of the script language to help them better. Which will really show true or false come mid next year.
We are lucky that Motorola sticks to a super close to stock experience because it's one less issue to deal with when playing with the new code and functions to try to get things to work. I'm really optimistic on this stuff because I like doing things that people think can't be done. So I believe that there will for sure be more customization and capabilities as we figure things out. Just takes time and effort. We worked for months and months on the S8 where people said impossible, and ended up getting it. So i have faith on this.
Acoustichayes said:
To build off what Uzephi said. It's not that rom's wont be capable. It's just working with new things that are being implemented and changed until something starts going right. The jump to Nougat changed a lot of things with security and the switch to Oreo is changing even more that Google is wanting to push for android that inadvertently also affect security and compatibility.
This is speculation, but since they introduced Kotlin, I feel like they are trying to alter everything over the long run to become more streamline and compatible around it. Especially given they can control the progress of the script language to help them better. Which will really show true or false come mid next year.
We are lucky that Motorola sticks to a super close to stock experience because it's one less issue to deal with when playing with the new code and functions to try to get things to work. I'm really optimistic on this stuff because I like doing things that people think can't be done. So I believe that there will for sure be more customization and capabilities as we figure things out. Just takes time and effort. We worked for months and months on the S8 where people said impossible, and ended up getting it. So i have faith on this.
Click to expand...
Click to collapse
Motorola already admitted the Z series will not be a part of Project treble meaning we need to try different vendor files to see if builds work. Sadly the ones used for the Z1 and wahoo mixed together cause the phone to go haywire and brick itself.
Uzephi said:
Motorola already admitted the Z series will not be a part of Project treble meaning we need to try different vendor files to see if builds work. Sadly the ones used for the Z1 and wahoo mixed together cause the phone to go haywire and brick itself.
Click to expand...
Click to collapse
And I understand that this means lack of simplicity in developing custom rom's. But it doesn't mean incapability. From what I understand as well, that treble can be implemented at a later date even though it will not be included with the initial Oreo update. You are working on a pixel rom conversion if I am correct right? Because I might have an idea...
But treble is still def exciting to think about being able to have one rom work on many different phones without modification. I honestly haven't divulged too far into it, but what are the odds of tearing apart the code and possible making support for it ourselves? I'm all for ridiculously long spans of working towards absurd goals hah
Acoustichayes said:
And I understand that this means lack of simplicity in developing custom rom's. But it doesn't mean incapability. From what I understand as well, that treble can be implemented at a later date even though it will not be included with the initial Oreo update. You are working on a pixel rom conversion if I am correct right? Because I might have an idea...
But treble is still def exciting to think about being able to have one rom work on many different phones without modification. I honestly haven't divulged too far into it, but what are the odds of tearing apart the code and possible making support for it ourselves? I'm all for ridiculously long spans of working towards absurd goals hah
Click to expand...
Click to collapse
Unless Motorola can repartition the phone, Treble won't come out, it needs a vendor partition. I can say at least on my Sprint phone the OEM block is about 1.5 GB when there is only about 200 MB of data on it, so they can splice that to save user data. Only other way is to repartition /system or /userdata for the space needed for the new partition.
Yes, I am doing a pixel conversion ROM. Tried just booting the pixel /system and it didn't work. I am taking assets from the Tamien and putting them into our November update using SuperR.
Uzephi said:
Unless Motorola can repartition the phone, Treble won't come out, it needs a vendor partition. I can say at least on my Sprint phone the OEM block is about 1.5 GB when there is only about 200 MB of data on it, so they can splice that to save user data. Only other way is to repartition /system or /userdata for the space needed for the new partition.
Yes, I am doing a pixel conversion ROM. Tried just booting the pixel /system and it didn't work. I am taking assets from the Tamien and putting them into our November update using SuperR.
Click to expand...
Click to collapse
I know there are few devs out there working on making it work on non treble phones. Repartitioning and adding a vendor partiion wouldn't be the issue with making it work. Rather trying to get the vendor source for drivers to add to it, and if they need to be reworked to add support. I've been off for a few months with health issues so I'm still getting back into things with oreo, but that seems to be the biggest issue at the moment that I could find.
When my health is back to 100 percent within a couple weeks I will dive into work with you and aid in any way possible for this. To me, trying to get driver source and make it work sounds fun. but we are far off topic now for this post so I'll leave this here haha.

Shield TV 2017 (16GB) How to... DTB...

I own a Shield TV 2017 (16GB) remote only (P2894, Darcy) which currently has Nvidia 7.1.0 developer OS, unlocked bootloader and the boot.img was patched using Magisk Manager 6.2.1/Magisk 18.0.
It has been noted patching boot.img using Magisk Manager 6.2.1/Magisk 18.0 only performs a partial root and that something else in the "DTB" information needs to be modified in order to allow full root access to read/write.
I'm new to this so please forgive me if I ask something obvious.
I've connected my Shield TV to my PC via ADB and executed
fastboot oem dtbname
...
(bootloader) tegra210-darcy-p2894-0050-a08-00.dtb
OKAY [ -0.000s]
finished. total time: -0.000s
I don't know how to extract the *.dtb information or know what's required to patch it.
The command to flash it is
fastboot flash DTB tegra210-darcy-p2894-0050-a08-00.dtb
Can someone else help provide what's required to extract, modify, etc... in order to flash and gain full root access?
Mogster2K said:
Zulu99 mentioned something similar - that dm-verity was enabled in darcy's DTB file, preventing any custom firmwares from executing. Foster does not seem to have this problem.
He's provided a patched DTB here - use at your own risk: http://bit.ly/2CxB1hS (WARNING! ONLY FOR 2017 DARCY MODEL!)
Original post here.
Click to expand...
Click to collapse
It's my understanding that this is required to allow TWRP 3.2.3.0 foster to work properly. If not can someone please clarify this for us beginner users?
NOTE: The patched DTB file above is not for the same version as the one I have.
nanerasingh said:
As my test on 2017 16gb 7.2.2 official TWRP patched the boot img i got root access but not fully write.
I used the DTB and flashed from fastboot and reboot without any reset -w command.
No issue of unresponsiveness and boots up normal.I tried edit build.prop in system via ES explorer and reboot the see the persistent and rw works.
So system dm-verity patch by DTB works.
Click to expand...
Click to collapse
Noting this too...
Thanks for the confirmation!
The fastboot -w should only be required if the forced cyption was already in use on the device.
But if I am not mistaken than on the developer version only the data prtition is encrypted, which is no issue.
nadia p. said:
It's my understanding that this is required to allow TWRP 3.2.3.0 foster to work properly. If not can someone please clarify this for us beginner users?
NOTE: The patched DTB file above is not for the same version as the one I have.
Click to expand...
Click to collapse
AFAIK the patched DTB is for booting custom ROMs. More work still needs to be done to get TWRP working again.
---------- Post added at 09:45 PM ---------- Previous post was at 09:42 PM ----------
nadia p. said:
I own a Shield TV 2017 (16GB) remote only (P2894, Darcy) which currently has Nvidia 7.1.0 developer OS, unlocked bootloader and the boot.img was patched using Magisk Manager 6.2.1/Magisk 18.0.
It has been noted patching boot.img using Magisk Manager 6.2.1/Magisk 18.0 only performs a partial root and that something else in the "DTB" information needs to be modified in order to allow full root access to read/write.
I'm new to this so please forgive me if I ask something obvious.
I've connected my Shield TV to my PC via ADB and executed
fastboot oem dtbname
...
(bootloader) tegra210-darcy-p2894-0050-a08-00.dtb
OKAY [ -0.000s]
finished. total time: -0.000s
I don't know how to extract the *.dtb information or know what's required to patch it.
The command to flash it is
fastboot flash DTB tegra210-darcy-p2894-0050-a08-00.dtb
Can someone else help provide what's required to extract, modify, etc... in order to flash and gain full root access?
Click to expand...
Click to collapse
Is root not working for you now? If you have never upgraded the stock ROM past 7.1, then it should work without needing a patched DTB.
Mogster2K said:
AFAIK the patched DTB is for booting custom ROMs. More work still needs to be done to get TWRP working again.
---------- Post added at 09:45 PM ---------- Previous post was at 09:42 PM ----------
Is root not working for you now? If you have never upgraded the stock ROM past 7.1, then it should work without needing a patched DTB.
Click to expand...
Click to collapse
I'm quite the beginner at all of this Android stuff, although I have experience with several other software related things. I'm currently stuck trying to install TWRP 3.2.3.0 foster on my Shield TV 2017 (16GB, remote only + usb keyboard + usb mouse). I haven't been able to backup the entire device yet to use that to see if I can restore everything back to that exact state yet. I don't know how to tell how "rooted" I really am yet.
Steel01 says TWRP 3.2.3.0 fosters is working on Darcy. I'm still trying to confirm this. My main reason for TWRP is to complete a full backup which I can later restore back to that exact state if/when something should happen if accidentally updated and it breaks everything again.
nadia p. said:
I'm quite the beginner at all of this Android stuff, although I have experience with several other software related things. I'm currently stuck trying to install TWRP 3.2.3.0 foster on my Shield TV 2017 (16GB, remote only + usb keyboard + usb mouse). I haven't been able to backup the entire device yet to use that to see if I can restore everything back to that exact state yet. I don't know how to tell how "rooted" I really am yet.
Steel01 says TWRP 3.2.3.0 fosters is working on Darcy. I'm still trying to confirm this. My main reason for TWRP is to complete a full backup which I can later restore back to that exact state if/when something should happen if accidentally updated and it breaks everything again.
Click to expand...
Click to collapse
TWRP works for darcy IF AND ONLY IF it has never been upgraded to stock rom 7.2 or higher. 7.2 majorly broke a lot of things, including TWRP, which is why this thread has so much traffic lately and I why asked whether you had upgraded past 7.1. Please confirm whether you have or not.
Mogster2K said:
TWRP works for darcy IF AND ONLY IF it has never been upgraded to stock rom 7.2 or higher. 7.2 majorly broke a lot of things, including TWRP, which is why this thread has so much traffic lately and I why asked whether you had upgraded past 7.1. Please confirm whether you have or not.
Click to expand...
Click to collapse
Hello Mogster2K, Originally without any modifications the factory installed Nvidia software upgraded itself through on-line updates to 7.2.1 which then broke other 3rd party Apps for me. I then attempted to downgrade to 6.3.0 developer OS, however because it was my first time unlocking the bootloader it wiped everything so once it 6.3.0 was successfully flashed, I had to connect to the internet, sign-in again to Google Play and meanwhile it forced itself to update back to 7.2.1 again. Later by following ACiDxCHRiST's guide HERE, I was able to successfully downgrade to 7.1.0 developer by patching the 7.1.0 boot.img then manually flashed each line item in flash-all.bat.
Later I tried to install TWRP 3.2.3.0 so I could backup the device, however I've not been successful with that since I have a Shield TV 2017 (16GB) remote only model so I must use a USB keyboard and USB mouse to do it. I was reading these other posts here about what the issues might be preventing me from installing TWRP and using it to back everything up. Does this help answer your question?
So I'm currently on 7.1.0 developer OS, patched boot.img using Magisk Manager 6.2.1/Magisk 18.0. So far the Apps that were broken by 7.2.0 "factory" are again working fine in 7.1.0. I don't game, I mainly watch movies and tv series with my device so I don't have many requirements other than I'd like to back everything up so in case it accidentally gets updated somehow I can revert back to a working archive and continue from there.
Mogster2K said:
TWRP works for darcy IF AND ONLY IF it has never been upgraded to stock rom 7.2 or higher.
Click to expand...
Click to collapse
I realized I wasn't sure if by upgrading the "stock" rom this included updating the device to 7.2.0 (or later) via on-line updates or just flashing the rom itself to 7.2.0 (or later).
Does anyone know how to test for certain criteria to help determine if:
A) anything needs to be modified in regards to DTB
B) if their device has been updated in such a way that it currently breaks TWRP (or other things) in such a way there is no fix as of today
This should prove quite useful to help us understand if/anything needs to be done or where the device resides at any given moment.
nadia p. said:
I realized I wasn't sure if by upgrading the "stock" rom this included updating the device to 7.2.0 (or later) via on-line updates or just flashing the rom itself to 7.2.0 (or later).
Click to expand...
Click to collapse
Both. Anyway, I did not realize at the time that darcy could be fully downgraded to 7.1, sorry. It doesn't work on my foster, so I can't use TWRP at all. Also, to the best of my knowledge, TWRP requires at least a USB mouse to function regardless of which ShieldTV model you have. And the modified DTB is just for booting modified images on darcy 7.2+. You're fine without it on 7.1.
Stuck... post backup TWRP 3.2.3.0, now corrupt w/black screen
I'm not sure if this had anything to do with it but I'm suck at a black screen after backing up TWRP.
More information can be found at this POST.
Already this 7.2 update is creating topics all over the place
Anyway, let me try to at least some light on things.
My latest findings:
1. The bootloader does not downgrade to 7.1 once you had at least the 7.2.x installed, not sure about 7.2 as it is too late for me to test this.
I did not check with the 6.3 either but maybe someone who did is able to state what bootloader is working then.
2. The DTB is not included in the firmware images at all but it seems it was included in some pre 7.1 to include the "updates" for the Darcy models.
What makes the Zulu one tick is the simple fact that it is patched to disable DM-Verity completely.
Hence the requirement for the fastboot -w or a factory reset.
TWRP and such....
This might get quite long, so anyone without half decent knowledge about rooting, firmwares and recoveries can just skip it
First thing I learned from 7.2 was: Do not mess with your bootloader!!!
Second thing I learned is that Linus was right with his statement about NVidia and their open source suppport.
So what actually changed?
For starters the NVidia statement of the developer firmware being rootable is not true the same way it was before.
Google latest kernel fixes and changes have been implemented - look it up yourself please to spare me thausand of lines of typing!
In short it means that all backdoors or such that Magisk or SU have used are unavailabe now.
Rooting still works but with the limit of write access.
And that is the important factor one for TWRP, the second is "routing".
Let me try to word it as simple as I can...
We can not modify the system to ignore the stock recovery or related security features.
We can not write to required areas of the system required to boot into TWRP through the recovery.
If you somehow manage to get into TWRP, like when I still had a working mod, there again is no write access to system available and the internal memory will be corrupted if you write a backup.
The DTB Zulu provided gives us system wide write rights again by disabling DM-Verity but this only goes for the system!!
The recovery does not use the DTB in this way.
Best thing you end up with is a dark screen where ADB seems to be working.
It actually works with full root access for me in several cases LOL
So if that really is TWRP then why can't we see it?
My TV is great as it allows multi input formats.
So a 1080P signal will be accepted as such.
And every time this screen format changes I see a little pop up with the new resolutions on the screen.
Since 7.2 this popup no longer shows up....
TWRP might actually be there and working but we can not see or use it.
The strange thing however is that at least on the 7.2.2 I had the strange problem that just trying to boot into tWRP through fastboot resulted in a corrupt system.
The bootloader realises the recovery written into the temp area has no NVidia signature or hash code to match.
This means for the bootloader a possible attack on the system happened and it is "secured", resulting in a soft brick.
My plans to fix all this crap for good:
The DTB is a partial solution at best as we
a) don't really know how compatible it is with future updates.
b) we still fail to properly use TWRP again.
All up a total nighmare for any modder or person with a lot of data and apps to backup and restore.
My first attempt was to build the 7.2 from the sources, thinking at least here the NVidia statements are correct that their installer takes care of everything.
Lol! It did take of about 120GB in downloads but did not give me any of require software suites actually required to even load a build tree.
Would need far more time than I have to mae complete and work with registrations, accounts and all this.
So I decided to go back to my roots before Magisk was a thing.
Dissecting the firmware, disabling all new "safety" features and not required encryptions and hash checks.
That bit I think I finnished to my satisfaction.
On the packing to make it work to be installed under 7.2.X I am still working.
Biggest drawback for me is that I lost TWRP and that the TWRP builder does not even let me log in on my Shield.
So even if a more offical way or porting or building could be a way out I can not access it.
Means I can neither try to install my modded firmware nor test it.
So if anyone reading here has a confirmed way to downgrade to something that brings TWRP back to live with working write access and working backup functions:
Don't be shy, we don''t bite (much)!
Share your way, give us the links and if my magic still works a bit this nightmare shall soon be over for good
7.2 sources still have not been released yet, anyway. I found a reference to a new branch "rel-30-r2-partner-o" but that's all.
Downunder35m said:
Already this 7.2 update is creating topics all over the place
Anyway, let me try to at least some light on things.
My latest findings:
1. The bootloader does not downgrade to 7.1 once you had at least the 7.2.x installed, not sure about 7.2 as it is too late for me to test this.
I did not check with the 6.3 either but maybe someone who did is able to state what bootloader is working then.
2. The DTB is not included in the firmware images at all but it seems it was included in some pre 7.1 to include the "updates" for the Darcy models.
What makes the Zulu one tick is the simple fact that it is patched to disable DM-Verity completely.
Hence the requirement for the fastboot -w or a factory reset.
TWRP and such....
This might get quite long, so anyone without half decent knowledge about rooting, firmwares and recoveries can just skip it
First thing I learned from 7.2 was: Do not mess with your bootloader!!!
Second thing I learned is that Linus was right with his statement about NVidia and their open source suppport.
So what actually changed?
For starters the NVidia statement of the developer firmware being rootable is not true the same way it was before.
Google latest kernel fixes and changes have been implemented - look it up yourself please to spare me thausand of lines of typing!
In short it means that all backdoors or such that Magisk or SU have used are unavailabe now.
Rooting still works but with the limit of write access.
And that is the important factor one for TWRP, the second is "routing".
Let me try to word it as simple as I can...
We can not modify the system to ignore the stock recovery or related security features.
We can not write to required areas of the system required to boot into TWRP through the recovery.
If you somehow manage to get into TWRP, like when I still had a working mod, there again is no write access to system available and the internal memory will be corrupted if you write a backup.
The DTB Zulu provided gives us system wide write rights again by disabling DM-Verity but this only goes for the system!!
The recovery does not use the DTB in this way.
Best thing you end up with is a dark screen where ADB seems to be working.
It actually works with full root access for me in several cases LOL
So if that really is TWRP then why can't we see it?
My TV is great as it allows multi input formats.
So a 1080P signal will be accepted as such.
And every time this screen format changes I see a little pop up with the new resolutions on the screen.
Since 7.2 this popup no longer shows up....
TWRP might actually be there and working but we can not see or use it.
The strange thing however is that at least on the 7.2.2 I had the strange problem that just trying to boot into tWRP through fastboot resulted in a corrupt system.
The bootloader realises the recovery written into the temp area has no NVidia signature or hash code to match.
This means for the bootloader a possible attack on the system happened and it is "secured", resulting in a soft brick.
My plans to fix all this crap for good:
The DTB is a partial solution at best as we
a) don't really know how compatible it is with future updates.
b) we still fail to properly use TWRP again.
All up a total nighmare for any modder or person with a lot of data and apps to backup and restore.
My first attempt was to build the 7.2 from the sources, thinking at least here the NVidia statements are correct that their installer takes care of everything.
Lol! It did take of about 120GB in downloads but did not give me any of require software suites actually required to even load a build tree.
Would need far more time than I have to mae complete and work with registrations, accounts and all this.
So I decided to go back to my roots before Magisk was a thing.
Dissecting the firmware, disabling all new "safety" features and not required encryptions and hash checks.
That bit I think I finnished to my satisfaction.
On the packing to make it work to be installed under 7.2.X I am still working.
Biggest drawback for me is that I lost TWRP and that the TWRP builder does not even let me log in on my Shield.
So even if a more offical way or porting or building could be a way out I can not access it.
Means I can neither try to install my modded firmware nor test it.
So if anyone reading here has a confirmed way to downgrade to something that brings TWRP back to live with working write access and working backup functions:
Don't be shy, we don''t bite (much)!
Share your way, give us the links and if my magic still works a bit this nightmare shall soon be over for good
Click to expand...
Click to collapse
First of all thank you so much for putting all this in layman's terms so someone like me can understand it. Total respect!
Since my device is useless if there is some way I can offer you remote access to a PC, the device and anything else I can assist you with please don't hesitate to let me know.
If you need me to send you my device with remote that you can use to complete these things and get everyone unstuck from this dreadful situation I'm all for that too.
I wish there were a means, like with computers, that we can purchase a band new device, fully back it up before even connecting it to the internet and being forced to sign-in to Google Play before we even have access to the device. We'd also need a way to wipe, format and reinstall this backup without any issues. Is this too much to ask for in an Android world?
EDIT: I have time, access to certain hardware PCs, Macs and Linux, and have some basic skills with computers, phones, etc... If I can assist you or anyone with certain time consuming things let me know. The only Android device I currently own now is the Shield TV.
Would it Work to just flash the system/vendor files without updating the Bootloader?
nadia p. said:
Since my device is useless if there is some way I can offer you remote access to a PC, the device and anything else I can assist you with please don't hesitate to let me know.
Click to expand...
Click to collapse
Sorry, I've lost track of your particular situation. Are you unable to reflash Stock 7.2 or 7.2.1? I realize it's hardly ideal, but it would at least make the ShieldTV usable.
From what I understand the dtb file is in the blob file, so simply flashing back a blob file would put back the stock dtb file. The only issue with flashing blob files is if you tried flashing back a Nougat blob file if you were already on a Oreo Firmware, as long as you only try flashing a Oreo Firmware blob file you shouldn't run into any problems, I would have to go back and have a read, but I'm sure I read that you may have done this and if you had tried to flash a Nougat blob file when you were already on an Oreo Firmware, that could be where you first ran into problems. But I'm not too sure if you are asking where to get the modified dtb file or not, I'm not sure if you have already flashed the modified dtb file or you are asking where to get the modified dtb file. I checked the dtb version on my 2017 Darcy Shield and it came up with a different number version than yours, mine came back with: tegra210-darcy-p2894-0050-a04-00.dtb whereas you have posted you have the tegra210-darcy-p2894-0050-a08-00.dtb. I done the check on what version of the dtb I had before and after using the modified dtb and also after when I flashed back a Oreo blob file and back to a Full Stock Oreo firmware and they both came back as the a04 version.
I would try and flash back to the latest Stock 7.2.1 image released on Nvidia's site: https://developer.nvidia.com/gameworksdownload
If successful then I would look at downgrading back to 7.1 Stock Firmware. I'm still a bit confused if this is what you have done or you only have a black screen when trying to boot to system?
The Fifth and Sixth version on the downloads screen are the versions for the 2017 model, one being the Developer version and the one below being the Stock version of 7.2.1. I would try flashing the Stock Version first and see if that gets you back up and running again. If it does, I would again check the dtb version as I am sure the 2017 Darcy model should be showing the a04 version and not a08.
---------- Post added at 01:06 PM ---------- Previous post was at 12:55 PM ----------
I just had a quick read back, you have said you have flashed the Developer image and then also flashed a patched boot.img. I have not done this combo as it is not the way I would do things. I would use just the Stock Firmware and not the Developer image with a patched boot.img. I do not know 100% for sure if the only difference between the Developer version and the stock version is the boot.img but if you are going to use a patched boot.img anyway, this is the reason why I say there is no need to flash the Developer version as you are going to use a Patched boot.img anyway, I would just stick with the Stock version.
Mogster2K said:
Sorry, I've lost track of your particular situation. Are you unable to reflash Stock 7.2 or 7.2.1? I realize it's hardly ideal, but it would at least make the ShieldTV usable.
Click to expand...
Click to collapse
Hello Mogster2K, from the factory install which was updated OTA to 7.2.1 I was able to 1st unlock the bootloader and flash 6.3.0 developer OS to my device successfully, or so I thought so. What I mean by this is based on what Downunder35m said once the device has been updated to 7.2.0 regardless of how when flashing previous versions of OS (developer or recovery) it may not revert the bootloader to 6.3.0. This we still have to see and test to confirm, unfortunately he nor I have any way to test things right now. That being said because I unlocked the bootloader (forced wipe) then flashed 6.3.0 that all went fine accept when booting to the Nvidia home screen it required me to connect to the internet and then sign-in to Google Play. Doing this the OS forces it to update itself again back to 7.2.1 (at that time).
So now that the previous steps were useless I then discovered ACiDxCHRiST's guide HERE and followed that since the bootloader was already unlocked I could modify the boot.img form 7.1.0 then flash that. Well two things happened, it worked perfectly however it's most likely Magisk didn't truly root the device 100%, it only rooted it partially. So now the device worked fine on 7.1.0 and everything was going well UNTIL I decided to install TWRP and backup my device. Doing so totally screwed it, now I have a black screen.... Read THIS.
So one of the reasons I started this thread was to find out more about DTB and how do we start to first test a devices current state, perhaps patch it to what we need to recover from the 7.2.0 changes and restrictions. The benefit of all of this is we should be able, with expertise, be able to climb our way out of this hole and get back to a working device.
whiteak said:
From what I understand the dtb file is in the blob file, so simply flashing back a blob file would put back the stock dtb file. The only issue with flashing blob files is if you tried flashing back a Nougat blob file if you were already on a Oreo Firmware, as long as you only try flashing a Oreo Firmware blob file you shouldn't run into any problems, I would have to go back and have a read, but I'm sure I read that you may have done this and if you had tried to flash a Nougat blob file when you were already on an Oreo Firmware, that could be where you first ran into problems. But I'm not too sure if you are asking where to get the modified dtb file or not, I'm not sure if you have already flashed the modified dtb file or you are asking where to get the modified dtb file. I checked the dtb version on my 2017 Darcy Shield and it came up with a different number version than yours, mine came back with: tegra210-darcy-p2894-0050-a04-00.dtb whereas you have posted you have the tegra210-darcy-p2894-0050-a08-00.dtb. I done the check on what version of the dtb I had before and after using the modified dtb and also after when I flashed back a Oreo blob file and back to a Full Stock Oreo firmware and they both came back as the a04 version.
I would try and flash back to the latest Stock 7.2.1 image released on Nvidia's site: https://developer.nvidia.com/gameworksdownload
If successful then I would look at downgrading back to 7.1 Stock Firmware. I'm still a bit confused if this is what you have done or you only have a black screen when trying to boot to system?
The Fifth and Sixth version on the downloads screen are the versions for the 2017 model, one being the Developer version and the one below being the Stock version of 7.2.1. I would try flashing the Stock Version first and see if that gets you back up and running again. If it does, I would again check the dtb version as I am sure the 2017 Darcy model should be showing the a04 version and not a08.
---------- Post added at 01:06 PM ---------- Previous post was at 12:55 PM ----------
I just had a quick read back, you have said you have flashed the Developer image and then also flashed a patched boot.img. I have not done this combo as it is not the way I would do things. I would use just the Stock Firmware and not the Developer image with a patched boot.img. I do not know 100% for sure if the only difference between the Developer version and the stock version is the boot.img but if you are going to use a patched boot.img anyway, this is the reason why I say there is no need to flash the Developer version as you are going to use a Patched boot.img anyway, I would just stick with the Stock version.
Click to expand...
Click to collapse
In short the 7.2.1 update broke the factory install by affecting other apps I use and that were working perfectly fine in 7.1.0 before the update occurred. This was the sole reason I attempted to revert back to a previous OS.
Just flashing 6.3.0 didn't work as it updated itself back to 7.2.1 forcibly. I then had to work around that issue and the only way I found was to download 7.1.0, patch it's boot.img file, flash 7.1.0 developer to keep the bootloader uplocked so it wouldn't wipe the system whereby deleting the user info, apps, etc..., make sense? The only issue is that Magisk didn't fully root the device properly and with the new OS verification added to 7.2.0 it created all sorts of other protections where we're not able to fully wipe everything and flash back normally. These protections kick in and prevent it. This is why we're trying to see how to undo the protection settings so we can actually do what we need to do. DTB is part of this.

[ABANDONED] TWRP Dirty Port for Moto E6

https://www.getdroidtips.com/twrp-recovery-motorola-moto-e6/
None of my recoveries have worked for the E6, but I'm being linked as a developer for a working TWRP recovery. if you came from this link, DO NOT use my builds. I've deleted the links to my builds anyway. Someone else got OrangeFox working on the forums. Go check it out and use that one instead.
I tried it but sadly it didn't work - I tried to use it as a temporary boot but it simply booted into the the normal E6 OS
TristianX said:
I tried it but sadly it didn't work - I tried to use it as a temporary boot but it simply booted into the the normal E6 OS
Click to expand...
Click to collapse
Crap, I gotta see if there's a way I can get logs then. But you usually can't get logs unless you can boot into a custom recovery...
Gimme a bit to think about this
I tried this image;
https://unofficialtwrp.com/twrp-3-3-1-root-moto-e6/
This process too
https://forum.xda-developers.com/moto-e6/how-to/rooting-e6-surfna-t3965659
and then of course your image from this post.
They all indicate they flash ok from the fastboot status but when it should boot/temp boot/or replace recovery it simply puts me back into normal boot up. I'm using the t-mobile variant with firmware PCB29.73-65-3
Ohhhh I'm excited to see where this can go!
My buddy just sent me a PM and brought up a good point. When dirty porting, I didn't even think to check if the recoveries were both 64 bit. This could be the reason why it's not booting. I'm gonna have another go at this later today and post up another test image for you all if I can figure something out.
Also, just as a heads up, this is for the QUALCOMM MODEL E6. Not sure if there's a MediaTek international model, but this isn't for that.
Well when you post back I'll deff give it a try.
I'm gonna try porting from a different phone, some kind of Aquarius model. It has the same chipset and is 64 bit too.
Also, to those that werent able to flash/boot from it, you unlocked your bootloader right? Forgot to mention that it needs to be unlocked for this to work
I haven't had a chance to give this a go. I'm making sure I understand everything and the risks. More than willing to give it a shot tho
In the process of dirty porting TWRP again to the E6. The only issue is I now have Windows on my PC (for very important personal reasons) and Carliv Image Kitchen is only available on Linux. Here's the steps I need to take to get you guys the 2nd "alpha" of TWRP:
1) Beat Broken Arrow in Payday 2 so I can go back to Linux
2) Download the recoveries/image kitchens for everything again to do the port
3) Do the dirty port and upload it
Currently I'm working on step 1, but it should be done by the end of this night.
NEW RECOVERY IS UP!!! Go download Attempt 2 and see if it gets you any further. If that breaks, try Attempt 3.
Got a moto e6 recently just as an Android device to experiment/mess around with (Mostly been into iOS and Jailbreaking) and stumbled across this thread. Whats the current situation with this? Is the TWRP port working?
Tim0xff7 said:
Got a moto e6 recently just as an Android device to experiment/mess around with (Mostly been into iOS and Jailbreaking) and stumbled across this thread. Whats the current situation with this? Is the TWRP port working?
Click to expand...
Click to collapse
Attempt 1 didn't work, waiting on someone to try Attempt 2, and if that doesn't work then 3. If you want to help (I'd really appreciate it) unlock your bootloader and try to boot/flash into one of the images I gave
I'd love to help! Bootloader is already unlocked so I'll try flashing and then get back to you with results
Some observations so far:
-Using fastboot to boot an image flat-out doesn't work. I'd hazard a guess and say it's due to Pie requiring system-as-root and the boot image not utilizing a ramdisk, but honestly I don't really know.
-The init executable from the stock recovery is 32-bit, and everything I've seen so far indicates an entirely 32-bit build for the E6. Using 64-bit TWRP bases probably won't work; the second and third attempts linked in the first post do not boot, and attempts to boot to recovery with them flashed will fail, with the phone continuing on to boot the system regularly, which in turn restores the stock recovery image.
-On the other hand, with what I believe is your first build, and my own test using the standard E5 TWRP as a base, I can get as far as the TWRP splash screen, where it locks up indefinitely.
-I've also tried creating my own device tree based on the E5 tree and building from scratch without any further success, although in fairness I've only been at it for a couple of hours.
FEGuy said:
Some observations so far:
-Using fastboot to boot an image flat-out doesn't work. I'd hazard a guess and say it's due to Pie requiring system-as-root and the boot image not utilizing a ramdisk, but honestly I don't really know.
-The init executable from the stock recovery is 32-bit, and everything I've seen so far indicates an entirely 32-bit build for the E6. Using 64-bit TWRP bases probably won't work; the second and third attempts linked in the first post do not boot, and attempts to boot to recovery with them flashed will fail, with the phone continuing on to boot the system regularly, which in turn restores the stock recovery image.
-On the other hand, with what I believe is your first build, and my own test using the standard E5 TWRP as a base, I can get as far as the TWRP splash screen, where it locks up indefinitely.
-I've also tried creating my own device tree based on the E5 tree and building from scratch without any further success, although in fairness I've only been at it for a couple of hours.
Click to expand...
Click to collapse
PM me. I've got a buddy who's more into kernels and things like that that can probably help us. I'd like to help too, but I can't promise much as I've never done kernel development before
Any headway on this front?
Hey OP, I got it to boot to the TWRP logo, but it won't fully boot into recovery. is there something I'm missing? sorry, I sorely want to install liveboot again on my device, and I feel like I'm being an idiot with some huge oversight on my part haha. is it functional?
---------- Post added at 08:56 PM ---------- Previous post was at 08:55 PM ----------
I'm only asking because I've sat at the TWRP logo for more than half an hour sorry to bug you
Daltonyx said:
Hey OP, I got it to boot to the TWRP logo, but it won't fully boot into recovery. is there something I'm missing? sorry, I sorely want to install liveboot again on my device, and I feel like I'm being an idiot with some huge oversight on my part haha. is it functional?
---------- Post added at 08:56 PM ---------- Previous post was at 08:55 PM ----------
I'm only asking because I've sat at the TWRP logo for more than half an hour sorry to bug you
Click to expand...
Click to collapse
The TWRP is not working. None of them are. The original poster has said in some recent comments that they plan on buying the E6, so maybe in the future we may get a fully working TWRP. I sure hope so, because my E6 has been collecting dust in my drawer for about a month now. I've been content with my G6 and G7 Power but I can't stand such a nice but unused phone.
Since Visible is pretty much giving away the e6 with any old trade in maybe the op will finally get one.

Question Grateful for root and bootloader unlockables but ..

I am grateful and I bought this because next tk Samsung s22 yktra this phone is definitely #2 in my opinion, which is saying a lot.
However the root process is tedious because I am not around a computer I am just lazy to get ito do flashing etc.
My question is, why do. We not have a a real recovery and ability to back up and restore various roms we or flash zips senselessly.
So my question is (since I just bought this) do you guys rhibj we will have to dastboir flash everything or at least much harder then with cwmod or twrp recovery. Is it not possible to have a recovery like those on t his phone?
Is there a better phone in the us that is unlockaable but has the quality like this phone and screen or the Samsung s22 yktra phone?
Thanks
Without a PC you can't run fastboot commands to unlock bootloader and root it. Twrp isn't available for stock a12, let alone the upcoming release of a13
Yes I know that is what I am saying. Is twrp or some recovery similar ever going to be compatible? If not I may be returning but I really don't want to. It's a great phone but I love playing with tweaks and mods. This is my not my main phone. My pixel is on a line I only use very seldomly
jgrimberg1979 said:
Yes I know that is what I am saying. Is twrp or some recovery similar ever going to be compatible? If not I may be returning but I really don't want to. It's a great phone but I love playing with tweaks and mods. This is my not my main phone. My pixel is on a line I only use very seldomly
Click to expand...
Click to collapse
I don't think that you will find too many phones from the primary companies (Google, Samsung, etc) nowadays that will have TWRP builds. As time progresses, the technology (and what is available) progresses as well.
jgrimberg1979 said:
Yes I know that is what I am saying. Is twrp or some recovery similar ever going to be compatible? If not I may be returning but I really don't want to. It's a great phone but I love playing with tweaks and mods. This is my not my main phone. My pixel is on a line I only use very seldomly
Click to expand...
Click to collapse
This is the most recent news about Android 12 compatibility for TWRP:
TWRP 3.6.2 Released
TWRP 3.6.2 is out now for most currently supported devices.
twrp.me
We are continuing work on Android 12. There is no ETA currently. You can follow our status on Zulip
Click to expand...
Click to collapse
Disclaimer: I am not advocating signing up for "Zulip", and I won't be doing so myself. When/if TWRP for Android 12 becomes available, I'll hear about it whether I sign up on there or not. It's also likely Android 13 will be stable by then.
Supposedly, the Official TWRP App (not itself updated since 2020) will notify when there's a new version - but I don't know if that applies to when there's no current version of TWRP Recovery already installed.
The reality is that for any device that actually has full working FASTBOOT, there is really no need for these types of recovery systems (i.e. twrp).
Screwing around with different OS builds while out and about is ill-advised no matter what. Leads you to the likely situation of getting yourself unbootable, which is bad. Its really not that big of a burden to plug in a wire when doing radical changes like that.
96carboard said:
The reality is that for any device that actually has full working FASTBOOT, there is really no need for these types of recovery systems (i.e. twrp).
Screwing around with different OS builds while out and about is ill-advised no matter what. Leads you to the likely situation of getting yourself unbootable, which is bad. Its really not that big of a burden to plug in a wire when doing radical changes like that.
Click to expand...
Click to collapse
It's not that much of a burden. You got to understand. It's been several years to a decade since I had a android and what I was used to was much different than now. I was used to always having a recovery that backs everything up and could swap roms if I wanted to if I flashed something wrong I could easily get into recovery and reflash the rom or just restore to another one. It's just different but I am grateful for what I have now but was hoping maybe there would be a recovery like twrp or cm recovery etc. Either way still happy for what we have
Pixel devices do not have a recovery partition; recovery lives in /boot with the kernel, as well as whatever patches you've applied. Currently, TWRP and Magisk cannot coincide for whatever reason. You can patch a boot image with TWRP, and it'll work AFAIK....but if you try to patch it with Magisk too, you'll get a boot loop.
Because we have full fastboot access, there's not really any need for TWRP. You can dump and backup partition contents using fastboot, but it's tedious.
jgrimberg1979 said:
It's not that much of a burden. You got to understand. It's been several years to a decade since I had a android and what I was used to was much different than now. I was used to always having a recovery that backs everything up and could swap roms if I wanted to if I flashed something wrong I could easily get into recovery and reflash the rom or just restore to another one. It's just different but I am grateful for what I have now but was hoping maybe there would be a recovery like twrp or cm recovery etc. Either way still happy for what we have.
Click to expand...
Click to collapse
ADP, Nexus, and Pixel devices have NEVER needed a recovery to function fully. This goes right back to the first Android phone in 2008. So nothing really has changed in this respect. Its mostly the "other" brands that need a recovery to work around various restrictions.
Backups can be taken from within the main OS, and restored similarly, and this is actually much preferred since the backup can be stored to a remote location such as a self-hosted Nextcloud server. You can look into seedvault (integrated solution) and neobackup (root solution).
Since Android 11 you cannot have TWRP and Magisk installed at the same time or it will lead to a bootloop. However, you can fastboot boot TWRP (without installing it) and have Magisk installed without getting into a bootloop. At least this is the way it was on Android 11 with the Pixel 2 XL.
Haven't used TWRP in a long time and don't miss it at all, to be honest.

Categories

Resources