TWRP 3.7.0-12 for Sunfish[Testing] - Google Pixel 4a ROMs, Kernels, Recoveries, & Other

[RECOVERY] TWRP 3.7.0-12 - TeamWin Recovery Project
Introduction:
Team Win Recovery Project or TWRP for short, is a custom recovery built with ease of use and customization in mind. We started from the ground up by taking AOSP recovery and loading it with the standard recovery options, then added a lot of our own features. It's a fully touch driven user interface , no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
Key Features:
Touchscreen driven with real buttons and drag-to-scroll
XML-based GUI that allows full customization of the layout true theming!
Settings are saved to the sdcard and persist through reboots
Ability to choose which partitions to back up and which to restore
Ability to choose to compress backups now with pigz (multi-core processor support for faster compression times)
Onscreen keyboard
Easy selection of internal/external storage
In addition to the above new features, TWRP features a scripting engine that allows an app to send commands to the recovery for the recovery to perform during startup. We call this scripting engine OpenRecoveryScript. This engine will be put to use immediately in the GooManager app. GooManager will be able to install recoveries automatically for most supported devices. The app will also let you choose to install multiple zips from within Android, wipe, and run a backup.
We are looking for other talented developers, themers, and device maintainers if they are interested in helping with a free, open source project.
Source Code:
sunfish Device Config: https://github.com/tnakamur/android_device_google_sunfish
DOWNLOAD:
Hello, this is a test build for sunfish users.
It has decryption working, touch, adb and backup and restore seems to work. Super partition volumes can be mounted, and the super partition can be backed up.
Android12 FW
TWRP3.7.0-12
https://github.com/tnakamur/Action-Recovery-Builder/releases/tag/3485414024
I built it with TWRP3.7.0 source code.
It needs custom kernel with LZMA ramdisk support.
Android11 FW
TWRP3.6.1-11
https://drive.google.com/file/d/1lmz3rvegCcGif-jFck7tfH7tT-RzcFWa/view?usp=sharing
I built it with TWRP3.6.1 source code.
Fix time stamp problem.
It needs custom kernel with LZMA ramdisk support.
test10
https://drive.google.com/file/d/16aTC8w0YUYBS_lqcA3KL0kz5mq7NsxxG/view?usp=sharing
I rebuilt it base Pixel4.
I tested it with October firmware.
It needs custom kernel with LZMA ramdisk support.
test6
https://drive.google.com/file/d/1mB73pX_0UQQA4PNPvqBBWqSZ6TixZfho/view?usp=sharing
I built it with September firmware.
I tested it with September firmware.
It needs custom kernel with LZMA ramdisk support.
test5
https://drive.google.com/file/d/1dabH0e0xkgZOldmnoWD8ZrvPV-IXGUf-/view?usp=sharing
I built it with August firmware.
I tested it with August firmware.
It needs custom kernel with LZMA ramdisk support.
test3
https://drive.google.com/file/d/1xhyIrLohcVY3xKHCeBoFAUzCmfBupibk/view?usp=sharing
I built it with June firmware.
I tested it with June firmware.
It needs custom kernel with LZMA ramdisk support.
I built my custom kernel, and link is below.
https://drive.google.com/file/d/1e8xFI5SuR8ty5X6R8WXVqrKLDOxprJcF/view?usp=sharing
Maybe, some other custom kernel works fine.
test2
https://drive.google.com/file/d/1t0VOZK2XlyxvC8a_o9XWI7ETy6XMS6bT/view?usp=sharing
I fix repack ramdisk problem.
It works 'Install Recovery Ramdisk'.
It needs custom kernel with LZMA ramdisk support.
I built my custom kernel, and link is below.
https://drive.google.com/file/d/1e8xFI5SuR8ty5X6R8WXVqrKLDOxprJcF/view?usp=sharing
Maybe, some other custom kernel works fine.
test1
https://drive.google.com/file/d/1EJhdSTbstkjVqx3YaowC-glWD6kJCN9Q/view?usp=sharing
It's tested FW version RQ1A.RQ1A.210205.004(Feb FW).
I don't test any other FW version.
It doesn't work 'Install Recovery Ramdisk'. It's only for fastboot mode.
I'm working fixing it and build TWRP with June FW.
Andriod10 FW https://drive.google.com/file/d/1PZaU9PpYmdcAHlyi0zhNwEGnBsAHDW_E/view?usp=sharing
It's tested both FW version QD4A.200805.001 and QD4A.200805.003.
And my custom kernel is OK too.
What to backup
* super
* data
* boot
What to restore
* super
* data
* boot
Repacking TWRP into Boot partition
To repack TWRP into the boot partition to override stock recovery when rebooting to recovery, perform the following steps
1. adb push <latest_twrp_boot.img> /sdcard/
2. reboot to bootloader and fastboot latest boot.img of TWRP
3. Go to Install
4. Touch Install Image
5. Select your TWRP boot.img from /sdcard
6. Install recovery ramdisk
7. Swipe to confirm flash
8. Reboot to recovery and android to verify installation
9. Reinstall magisk, if you want
Credit and Thanks
@bigbiff - his big work for TWRP
@HolyAngel - I refer his kernel commit
@wrongway213 - I refer his kernel commit, too
If you like my work, donations are always welcome.
Don't forget to hit thanks and rate the thread nicely, it's free

To install TWRP, you need LZMA support kernel.
My custom kernel is here
https://drive.google.com/file/d/1nuXc88t0Iokc0ha-AicOtZEUeGCGwQ-R/view?usp=sharing

Why is there a custom kernel needed?

Taobaibai said:
Why is there a custom kernel needed?
Click to expand...
Click to collapse
Because stock kernel doesn't support LZMA ramdisk.
It's needed to install TWRP.
https://forum.xda-developers.com/showpost.php?p=83255125&postcount=207

Taobaibai said:
Why is there a custom kernel needed?
Click to expand...
Click to collapse
nikamura said:
Because stock kernel doesn't support LZMA ramdisk.
It's needed to install TWRP.
https://forum.xda-developers.com/showpost.php?p=83255125&postcount=207
Click to expand...
Click to collapse
Better to boot vs install until build is proven. Yep, a bit annoying but keeps options open while allowing fluid OTA updates if that's your preference. In boot scenario custom kernel should not be needed.

This is big news and so awesome!

Nice!! Congrats on getting it built and posted! Thank you for the mention

The kernel gived me a bootloop

Theodor0504 said:
The kernel gived me a bootloop
Click to expand...
Click to collapse
Witch FW version you use?

Has anyone used this to create a back up and then restore it properly without problems?

nikamura said:
Witch FW version you use?[/QUOTE
I don't remember actually
Click to expand...
Click to collapse

https://forum.xda-developers.com/pixel-4a/development/kernel-holydragon-kernel-t4155283
This kernel is good or no?

My apologies if this has been asked/answered before, but could someone ELI5 on why it's so difficult to get custom recoveries running on Pixel devices?

Lada333 said:
My apologies if this has been asked/answered before, but could someone ELI5 on why it's so difficult to get custom recoveries running on Pixel devices?
Click to expand...
Click to collapse
The short answer is - recovery is no longer its own independent partition. Instead it's embedded into boot.img which also contains the kernel for the OS itself.
Recovery used to be its own partition because OS updates looked like this:
- OS downloads new OTA file
- OS boots into recovery
- Recovery installs the OTA
- Reboots back to OS
Now on "A/B" devices OS updates look like this:
- OS boots from "partition A".
- OS downloads new OTA file.
- OS installs OTA on "partition B" which it's not currently booting from.
- OS switches the active partition to B and reboots from that.
No recovery needed anymore. So it's no longer a partition of its own. Which is great for Google but harder for Android do-it-yourselfers.

cmstlist said:
The short answer is - recovery is no longer its own independent partition. Instead it's embedded into boot.img which also contains the kernel for the OS itself.
Recovery used to be its own partition because OS updates looked like this:
- OS downloads new OTA file
- OS boots into recovery
- Recovery installs the OTA
- Reboots back to OS
Now on "A/B" devices OS updates look like this:
- OS boots from "partition A".
- OS downloads new OTA file.
- OS installs OTA on "partition B" which it's not currently booting from.
- OS switches the active partition to B and reboots from that.
No recovery needed anymore. So it's no longer a partition of its own. Which is great for Google but harder for Android do-it-yourselfers.
Click to expand...
Click to collapse
The only A/B phone I've ever worked on was my Dad's Mi A1, but that had TWRP running just fine.
I remember reading a few things about Project Treble back then, is that related to this?

Theodor0504 said:
nikamura said:
Witch FW version you use?[/QUOTE
I don't remember actually
Click to expand...
Click to collapse
It's for android 10 version.
I tested QD4A.200805.001 version.
It may work QD4A.200805.003 version(it used same boot.img), but I didn't test.
Click to expand...
Click to collapse

bursug said:
https://forum.xda-developers.com/pixel-4a/development/kernel-holydragon-kernel-t4155283
This kernel is good or no?
Click to expand...
Click to collapse
I used his kernel as a reference, and I added LZMA ramdisk support.
So, his kernel isn't fit TWRP install.

nikamura said:
Because stock kernel doesn't support LZMA ramdisk.
It's needed to install TWRP.
https://forum.xda-developers.com/showpost.php?p=83255125&postcount=207
Click to expand...
Click to collapse
Did you use LZMA compression because the partition where the ram disk is has very little room like the pixel 3A? The pixel 3A did not have enough room in the partition so TWRP was stripped down of features and compressed with LZMA to get it small enough to fit. I believe, but could be wrong, LZMA was used because it yielded the smallest image.
Does the Pixel 4A have the same space issues as the Pixel 3A?
I'm only asking because on the Pixel 3A TWRP never became functional enough to use much because of lack of partition space to reside even after uniquely compressed with LZMA. If the pixel 4A has more space maybe LZMA compression and a specific kernel that requires lcma might not be necessary?

I've never had an a/b phone before and am thinking of getting this one.
A couple of questions :
What is sunfish
Does anyone regret getting this phone
Is it a pain in the azz to deal with a/b

12paq said:
Did you use LZMA compression because the partition where the ram disk is has very little room like the pixel 3A? The pixel 3A did not have enough room in the partition so TWRP was stripped down of features and compressed with LZMA to get it small enough to fit. I believe, but could be wrong, LZMA was used because it yielded the smallest image.
Does the Pixel 4A have the same space issues as the Pixel 3A?
I'm only asking because on the Pixel 3A TWRP never became functional enough to use much because of lack of partition space to reside even after uniquely compressed with LZMA. If the pixel 4A has more space maybe LZMA compression and a specific kernel that requires lcma might not be necessary?
Click to expand...
Click to collapse
Sorry, I don't know it's needed LZMA compression.
I used pixel4 TWRP made by @bigbiff as a reference, and I used LZMA compression as he did.

Related

[RECOVERY][OFFICIAL] TWRP 3.0.0-0| 10/2/2016

Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
CHANGELOG for 3.0.0-0:
-Completely new theme - Much more modern and much nicer looking (by z31s1g)
-True Terminal Emulator - Includes arrow keys, tab and tab completion, etc. (by _that)
-Language translation - It won’t be perfect and especially some languages that require large font files like Chinese & Japanese won’t be availble on most devices. Also some languages may only be partially translated at this time. Feel free to submit more translations to OmniROM’s Gerrit. (mostly by Dees_Troy)
-Flashing of sparse images - On select devices you will be able to flash some parts of factory images via the TWRP GUI (by HashBang173)
-Adopted storage support for select devices - TWRP can now decrypt adopted storage partitions from Marshmallow
-Reworked graphics to bring us more up to date with AOSP - includes support for adf and drm graphics (by Dees_Troy)
-SuperSU prompt will no longer display if a Marshmallow ROM is installed
-Update exfat, exfat fuse, dosfstools (by mdmower)
-Update AOSP base to 6.0
-A huge laundry list of other minor fixes and tweaks
WARNING: This is our first release in a long time. We have a lot of new and somewhat aggressive changes in this new release. The changes to the graphics back-end may cause some devices to not boot up properly or have other display-related issues. If you are not in a position to reflash an older build of TWRP, then wait until you are or at least wait until others have tried the new version for your specific device. You don’t want to end up with a non-working recovery and have to wait several hours or days to get to a computer to be able to fix it.
Notes for themers: In addition to the udpated theme, we have introduced a theme version variable to the TWRP theme system. If the theme version does not match the version that TWRP expects, TWRP will reject the custom theme and load its stock theme. This change will ensure that people who update TWRP without updating their theme will still have a workable recovery. We have removed libjpeg support. The stock theme was only using a jpeg image for the splash / curtain. This change means that any custom themes will no longer be able to use jpeg images. It also means that tools used to repack recovery images with a different curtain / splash will need to be updated to use the new method.
Version number notes: For a while we’ve been using a 4 digit version number and reserved the 4th digit for device-specific updates. For instance, we find and fix a device-specific issue like decryption of data on Nexus 5, we would release that as a 2.8.7.1. After a while, some people would start asking where 2.8.7.1 was for other devices. So, going forward we have decided to change the numbering scheme to 3.0.0-2, etc. Our hope is that this version numbering scheme will more clearly identify that the 4th digit does not indicate a version change for the code base.
We need your help! The bulk of TWRP work is done by 3 people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance!
CHANGELOG for 2.8.7.0:
-Initial ground work for software drawn keyboard (_that)
-Fix handling of wiping internal storage on datamedia devices (xuefer)
-Allow DataManager to set and read values from the system properties (xuefer)
-Fix crash when taking screenshots on arm64 devices (xuefer)
-Fix error message after an ORS script completes (Dees_Troy)
-Fix crashes / error when creating encrypted backups (_that, Dees_Troy)
-Add system read only option – more details below (Dees_Troy)
-Add resize2fs and GUI option to run resize2fs (Dees_Troy)
-Fix crash loop caused by empty lines in AOSP recovery command file (_that)
-Prevent duplicate page overlays such as multiple lock screens (mdmower)
Note: As always, be sure your custom theme is up to date (or remove your custom theme) before updating TWRP.
System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
resize2fs feature: On some devices like the Nexus 6, the factory images include a userdata image that is the proper size only for the 32GB units. If you flash the factory image to a 64GB Nexus 6, the data partition will appear as if it only has the free space of a 32GB device. Using the resize2fs option, TWRP can resize your data partition to take up the full space available. The resize2fs may also be useful to resize system partitions on devices where custom ROM system images don’t take up the full partition space. Lastly, resize2fs may be useful in some cases to reserve the proper space at the end of a data partition for a full disk encryption key, should your partition be formatted incorrectly for some reason.
This new version also marks our first set of full builds using our new jenkins build server. You can track the progress of builds at https://jenkins.twrp.me and we have taken additional steps to make it easier for device maintainers to step up and submit patches to our gerrit server at https://gerrit.twrp.me to help us keep devices up to date and working.
DOWNLOAD:
You can find more information and download links on our NEW website! NOTE that the 2.8.6.0 version is ONLY available on our new site and is not available on our other, older mirrors!
BUGS:
If you have found a bug, please consider posting it to our github issues log. It's pretty much impossible for us to keep up with the more than 40 threads that we have for the devices that we "directly" support. If you have a significant problem that cannot be answered in this thread, your best bet is to PM Dees_Troy directly, contact us via our website, or find us in our IRC channel below. If you see someone that's struggling, feel free to point it out to us. We need your help to help us keep track of all of our devices! Thanks!
SUPPORT:
Live support is available via #twrp on Freenode with your IRC client or just click this link.
XDA:DevDB Information
TWRP Recovery, Tool/Utility for the Sony Xperia Z3 Compact
Contributors
someone755
Version Information
Status: Stable
Stable Release Date: 2015-08-18
Created 2015-08-18
Last Updated 2016-02-17
Device page on the TWRP website:
Mirror 1
There is no Mirror 2.
Due to the way Sony devices function, you will need to have an unlocked bootloader.
Your options, as far as ROMs go, are the following:
Any ROM with this commit
OR just use the new bootloader (with a proper recovery partition)
All credit goes to the TWRP team. I just annoyed the fools until they built the recovery.
Awesome! Very glad to see this.
After flashing through fastboot, its impossible for me to boot into recovery, my phone stays stuck on the Sony screen with the pink/orange led.
Running resurrection remix and m5 kernel, theme has been updated for 2.8.7, previously was on 2.6.0
Can this be install on LB?
rich2007 said:
Can this be install on LB?
Click to expand...
Click to collapse
it should work with andropluskernel, not with stock
omnomnomkimiiee said:
After flashing through fastboot, its impossible for me to boot into recovery, my phone stays stuck on the Sony screen with the pink/orange led.
Running resurrection remix and m5 kernel, theme has been updated for 2.8.7, previously was on 2.6.0
Click to expand...
Click to collapse
Works fine here. Did you check the md5 before installing? Does it work without the theme?
rich2007 said:
Can this be install on LB?
Click to expand...
Click to collapse
You need a custom boot image to boot into it (since our bootloaders don't really support a separate recovery partition, and we rely on a boot.img script to boot into one), which means you'd have to unlock the bootloader.
funiewski said:
it should work with andropluskernel, not with stock
Click to expand...
Click to collapse
On this note, if anyone can provide me with stock boot images, I'll try and keep them up-to-date with the extract_elf_ramdisk utility, so that users on stock may still boot into TWRP if they don't opt for the AndroPlus kernel.
Hello everyone,
Flashed this with "fastboot flash recovery", still getting the cm12.1 recovery.
BL unlocked, USB debugging enabled, CM 12.1 installed.
Anyone have a solution?
Thanks
Edit:
tried the twrp manager, no Z3C here, aswell the dd method, nothing changed.
pityu100 said:
Hello everyone,
Flashed this with "fastboot flash recovery", still getting the cm12.1 recovery.
BL unlocked, USB debugging enabled, CM 12.1 installed.
Anyone have a solution?
Thanks
Edit:
tried the twrp manager, no Z3C here, aswell the dd method, nothing changed.
Click to expand...
Click to collapse
Same here, there is no Z3C in the list on TWRP Manager, and the 'dd' method leaves an unusable recovery (stuck on orange led). I'm happy with official TWRP support, but do you guys even test your stuff before releasing it.....? The steps with TWRP manager app don't even exist (there is no 'advanced' to tap).
Flashed twrp.img as boot: fastboot flash boot twrp.img. -> TWRP starts every time i power on the phone. Flashed CM12.1 from this state, and TWRP got overwrited again with CM12.1 recovery. /sigh
Is the CM kernel counts as "Any custom kernel" ?
pityu100 said:
text
Click to expand...
Click to collapse
Menubalk said:
Same here, there is no Z3C in the list on TWRP Manager, and the 'dd' method leaves an unusable recovery (stuck on orange led). I'm happy with official TWRP support, but do you guys even test your stuff before releasing it.....? The steps with TWRP manager app don't even exist (there is no 'advanced' to tap).
Click to expand...
Click to collapse
Thanks both of you for reporting your issues. Your reports sparked an investigation, and we were able to identify several issues that have thus far been overlooked (for whatever reason).
The "stuff" was tested before it was released, yes, but we're now facing limitations in the form of unmerged patches to the CM device trees. The issues should have been resolved several years ago, but instead they are now wreaking havoc on Sony msm8974 recovery setups. I've gotten some of the elite TWRP and CM people on this, as well as smaller fellow rhine and shinano developers (though Myself5 and oshomun could hardly be classified as small nowadays).
I personally have already uploaded four changes to the CM gerrit (that should have been applied years ago); One of them got denied (though is now being discussed for the near future (possibly as soon as cm-13.0); the result of that discussion is, among others, that the Cyanogen Recovery is now available for download alongside the ROM zip over at https://download.cyanogenmod.org/?device=z3c ), two are still pending any input whatsoever, and the last one was promised a merge, but the device maintainers have gone quiet, at least on the outside.
(If you wish, you can view the patches and their progress at their links: patch1, patch2, patch3, patch4, patch5.)
However, both teams are also having issues with other matters (such as Z3 not building, or adding new features to TWRP), and there is also the fact that school starts around this time of year (which impacts both the younger developers as well as those who already have children).
To conclude, there really isn't a unified guide I can give you to get to TWRP. It works, and you can use it if you have the correct setup. However achieving that setup is not a simple walkthrough away, and it would differ ever so slightly for every person's preferences, not to mention it would be overwritten with each new ROM update.
Such is the state of affairs at this point in time. This may or may not change, but be assured that everything we can do about this, we will do.
EDIT: A quick note that some ROMs may already include fixes for these issues. I don't know which those ROMs could be, so I won't go into listing them, but the possibility exists.
someone755,
thanks for your quick reply and your investigation.
Hope for the best, but time will tell.
Thanks again
Someone, here is a build that actually works, maybe you guys can base on that?: http://forum.xda-developers.com/z3-compact/development/recovery-twrp-2-8-6-0-fota-recovery-t3093537
I'm on Cyanogen 12.1 nightlies with M5 (=Cyanogen-based) kernel btw.
Menubalk said:
Someone, here is a build that actually works, maybe you guys can base on that?: http://forum.xda-developers.com/z3-compact/development/recovery-twrp-2-8-6-0-fota-recovery-t3093537
I'm on Cyanogen 12.1 nightlies with M5 (=Cyanogen-based) kernel btw.
Click to expand...
Click to collapse
The thing is that if you flash a cm-12.1 boot image (completely stock, without kernel or ramdisk modifications that M5 or Kernel12 perform), it won't work. It works with some setups, but not with others, and is, for some reason, very specific -- to get rid of these errors, CyanogenMod would have to (at the very least) accept my changes.
If you feel like you have to try this for yourself, here's a link to the boot image: https://www.androidfilehost.com/?fid=24052804347797955 Getting out of the mess created once you flash this can be a pickle though, so unless you have a boot image on hand with which you know TWRP works, do not flash the file I linked.
I've had somebody say it started working for him after flashing r_02 of Kernel12, though sadly I'm not very sure that's a permanent solution (it is, however, a working temporary one).
Unfortunately the man who was supposed to review the changes is on leave from development, so waiting is the only option available right now (unless we come up with a zip file to flash after each nightly install, but that would only increase the chaos of this already-confusing situation).
someone755 said:
The thing is that if you flash a cm-12.1 boot image (completely stock, without kernel or ramdisk modifications that M5 or Kernel12 perform), it won't work. It works with some setups, but not with others, and is, for some reason, very specific -- to get rid of these errors, CyanogenMod would have to (at the very least) accept my changes.
If you feel like you have to try this for yourself, here's a link to the boot image: https://www.androidfilehost.com/?fid=24052804347797955 Getting out of the mess created once you flash this can be a pickle though, so unless you have a boot image on hand with which you know TWRP works, do not flash the file I linked.
I've had somebody say it started working for him after flashing r_02 of Kernel12, though sadly I'm not very sure that's a permanent solution (it is, however, a working temporary one).
Unfortunately the man who was supposed to review the changes is on leave from development, so waiting is the only option available right now (unless we come up with a zip file to flash after each nightly install, but that would only increase the chaos of this already-confusing situation).
Click to expand...
Click to collapse
Had no issues with my 2.8.7.0 twrp built into my ROMs boot.img been working with no issues so far
Sent from my Z3 Compact using Tapatalk
jenkins-84 said:
Had no issues with my 2.8.7.0 twrp built into my ROMs boot.img been working with no issues so far
Sent from my Z3 Compact using Tapatalk
Click to expand...
Click to collapse
The goal of FOTA recoveries was to let the user boot into a recovery regardless of what recovery is in the boot image. If you flash a CM nightly over your setup, you won't be able to get to TWRP again unless you perform various modifications to the CM boot image.
Packing recovery inside boot is what's causing all these issues in the first place, so doing what you suggest would be a step forward, but two steps back as well.
someone755 said:
The goal of FOTA recoveries was to let the user boot into a recovery regardless of what recovery is in the boot image. If you flash a CM nightly over your setup, you won't be able to get to TWRP again unless you perform various modifications to the CM boot image.
Packing recovery inside boot is what's causing all these issues in the first place, so doing what you suggest would be a step forward, but two steps back as well.
Click to expand...
Click to collapse
Yeah maybe but I don't care to much for CM based ROMs was for people using slimlp based mainly
Sent from my Z3 Compact using Tapatalk
jenkins-84 said:
Yeah maybe but I don't care to much for CM based ROMs was for people using slimlp based mainly
Sent from my Z3 Compact using Tapatalk
Click to expand...
Click to collapse
That's all fine and dandy until you realize most people are sticking with CM (for some unexplainable reason). Other ROM gerrits are much more likely to have already merged the needed changes (and are much more lenient and open when it comes to accepting new changes in general, and all this is the only reason this waiting game is now on).
someone755 said:
That's all fine and dandy until you realize most people are sticking with CM (for some unexplainable reason). Other ROM gerrits are much more likely to have already merged the needed changes (and are much more lenient and open when it comes to accepting new changes in general, and all this is the only reason this waiting game is now on).
Click to expand...
Click to collapse
Yeah but I don't wait on slim or use its device trees etc I build for my own and use commits I want, I don't really care what people use or do. I build ROMs for myself and a friend. I just happened to share a ROM that I don't care if people use or not. If I'm happy with what I build and use then that's all I care about
Sent from my Z3 Compact using Tapatalk
jenkins-84 said:
Yeah but I don't wait on slim or use its device trees etc I build for my own and use commits I want, I don't really care what people use or do. I build ROMs for myself and a friend. I just happened to share a ROM that I don't care if people use or not. If I'm happy with what I build and use then that's all I care about
Sent from my Z3 Compact using Tapatalk
Click to expand...
Click to collapse
You do realize TWRP is meant to work for everyone, not just for 'me and my bros'?
On topic:
Someone, that FOTA TWRP I linked does (or at the very least did, I've been on M5 Kernel for a few weeks now) work with a stock Cyanogenmod boot image. Before M5 kernel I could already reach TWRP. I really think it worth a closer look to see what that guy did because it works/worked for some reason..
My full sequence (the first time anyway):
Unlock Bootloader
Unpack boot.img from Cyanogenmod nightly zip
Flash boot.img in fastboot
Boot to Cyanogenrecovery
Wipe
Flash Cyanogenmod in recovery
Boot Cyanogenmod, Setup Wizard yadda yadda
Shut down and go to fastboot
Flash FOTA TWRP from said link
Test FOTA TWRP, Be happy
----Few days later----
Flash M5 through FOTA TWRP

[RECOVERY] [20.11.2016] Unofficial TWRP for Ulefone Metal - 3.0.2-0

Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. Its a fully touch driven user interface no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
CHANGELOG for 3.0.2-0:
-Fix a bug with the input box that affected masked inputs (passwords). This fixes decrypt of full device encryption on devices that support decrypt. This bug also impacts encrypted backups. Users are highly encouraged to stop using 3.0.1 if you use encrypted backups or if you need decrypt of data in TWRP.
-Add Greek translation to some builds.
CHANGELOG for 3.0.1-0:
-support new CM 13.0 pattern encryption (sultanqasim)
-fix slow flashing issue due to modprobe (present on only some devices) (#twrp)
-libtar updated to latest upstream and fixes (jcadduono)
-fixes for loading custom themes (_that)
-TWRP will now detect and install TWRP themes automatically through the normal zip install process (Dees_Troy)
-translation updates - added Italian, Czech and Polish and significant updates to Dutch
-progress bar improvements - progress bar updates during image flashing and better tracks progress during file system backups (tar) (Dees_Troy)
-fix input box text display (Dees_Troy)
-reboot option after zip install complete (bigbiff)
-other mostly invisible bug fixes and improvements
CHANGELOG for 3.0.0-0:
-Completely new theme - Much more modern and much nicer looking (by z31s1g)
-True Terminal Emulator - Includes arrow keys, tab and tab completion, etc. (by _that)
-Language translation - It won’t be perfect and especially some languages that require large font files like Chinese & Japanese won’t be availble on most devices. Also some languages may only be partially translated at this time. Feel free to submit more translations to OmniROM’s Gerrit. (mostly by Dees_Troy)
-Flashing of sparse images - On select devices you will be able to flash some parts of factory images via the TWRP GUI (by HashBang173)
-Adopted storage support for select devices - TWRP can now decrypt adopted storage partitions from Marshmallow
-Reworked graphics to bring us more up to date with AOSP - includes support for adf and drm graphics (by Dees_Troy)
-SuperSU prompt will no longer display if a Marshmallow ROM is installed
-Update exfat, exfat fuse, dosfstools (by mdmower)
-Update AOSP base to 6.0
-A huge laundry list of other minor fixes and tweaks
WARNING: This is our first release in a long time. We have a lot of new and somewhat aggressive changes in this new release. The changes to the graphics back-end may cause some devices to not boot up properly or have other display-related issues. If you are not in a position to reflash an older build of TWRP, then wait until you are or at least wait until others have tried the new version for your specific device. You don’t want to end up with a non-working recovery and have to wait several hours or days to get to a computer to be able to fix it.
Notes for themers: In addition to the udpated theme, we have introduced a theme version variable to the TWRP theme system. If the theme version does not match the version that TWRP expects, TWRP will reject the custom theme and load its stock theme. This change will ensure that people who update TWRP without updating their theme will still have a workable recovery. We have removed libjpeg support. The stock theme was only using a jpeg image for the splash / curtain. This change means that any custom themes will no longer be able to use jpeg images. It also means that tools used to repack recovery images with a different curtain / splash will need to be updated to use the new method.
Version number notes: For a while we’ve been using a 4 digit version number and reserved the 4th digit for device-specific updates. For instance, we find and fix a device-specific issue like decryption of data on Nexus 5, we would release that as a 2.8.7.1. After a while, some people would start asking where 2.8.7.1 was for other devices. So, going forward we have decided to change the numbering scheme to 3.0.0-2, etc. Our hope is that this version numbering scheme will more clearly identify that the 4th digit does not indicate a version change for the code base.
We need your help! The bulk of TWRP work is done by 3 people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance!
CHANGELOG for 2.8.7.0:
-Initial ground work for software drawn keyboard (_that)
-Fix handling of wiping internal storage on datamedia devices (xuefer)
-Allow DataManager to set and read values from the system properties (xuefer)
-Fix crash when taking screenshots on arm64 devices (xuefer)
-Fix error message after an ORS script completes (Dees_Troy)
-Fix crashes / error when creating encrypted backups (_that, Dees_Troy)
-Add system read only option – more details below (Dees_Troy)
-Add resize2fs and GUI option to run resize2fs (Dees_Troy)
-Fix crash loop caused by empty lines in AOSP recovery command file (_that)
-Prevent duplicate page overlays such as multiple lock screens (mdmower)
Note: As always, be sure your custom theme is up to date (or remove your custom theme) before updating TWRP.
System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
resize2fs feature: On some devices like the Nexus 6, the factory images include a userdata image that is the proper size only for the 32GB units. If you flash the factory image to a 64GB Nexus 6, the data partition will appear as if it only has the free space of a 32GB device. Using the resize2fs option, TWRP can resize your data partition to take up the full space available. The resize2fs may also be useful to resize system partitions on devices where custom ROM system images don’t take up the full partition space. Lastly, resize2fs may be useful in some cases to reserve the proper space at the end of a data partition for a full disk encryption key, should your partition be formatted incorrectly for some reason.
This new version also marks our first set of full builds using our new jenkins build server. You can track the progress of builds at https://jenkins.twrp.me and we have taken additional steps to make it easier for device maintainers to step up and submit patches to our gerrit server at https://gerrit.twrp.me to help us keep devices up to date and working.
DOWNLOAD:
Unofficial TWRP 3.0.2-0 for Ulefone Metal
Mirror 1
MD5 - 10286EE1255C8371A2E5F720896D02C2
SHA-1 - E6C0875ADA34EB1CDE5D5A648D3F8B9AC883EFDA
INSTALLATION:
Most devices can be updated quickly and easily within TWRP if you already have version 2.8.4.0 or higher installed
1) Download the latest version above
2) Reboot to TWRP
3) Hit Install and tap the "Install Image" button in the lower right
4) Browse to the location of the TWRP image on your device and select it
5) Select recovery from the partition list and swipe to flash
To install from SP Flash Tools:
1) Download scatter file attached to this post
2) Load scatter file into SPFT
3) Plug USB cable into device and computer
4) Press download in SPFT
5) Reboot device
BUGS:
If you have an issue, the first step is to post a recovery log so we can determine the cause of the issue. This is done in recovery using Advanced -> Copy Log, or adb pull /tmp/recovery.log. Once a log is uploaded we can determine how best to proceed.
XDA:DevDB Information
RECOVERY] Unofficial TWRP for Ulefone Metal, Tool/Utility for the Android General
Contributors
Jonny
Source Code: https://github.com/JonnyXDA/android_device_ulefone_metal/tree/Omni
Version Information
Status: Stable
Current Stable Version: 3.0.2-0
Stable Release Date: 2016-11-20
Created 2016-10-31
Last Updated 2016-11-20
FAQ:
- None yet!
DEVICE-SPECIFIC CHANGELOGS:
3.0.2-0:
-Fully built from source for Ulefone Metal
Current TWRP "bugs" for Ulefone Metal:
NONE
Thanks for your work.
Recovery not mounting sd card.
Here is log:
Internal build from ulefone forum works.
Mounting sd card works.
Thanks.
here is log:
dropbear2 said:
Internal build from ulefone forum works.
Mounting sd card works.
Thanks.
here is log:
Click to expand...
Click to collapse
Internal? You mean the build I posted there this morning?
Jonny said:
Internal? You mean the build I posted there this morning?
Click to expand...
Click to collapse
Yes, build posted this morning.
dropbear2 said:
Yes, build posted this morning.
Click to expand...
Click to collapse
Cool, I'll update this thread with it in a bit.
This build twrp in downloads (2016-11-02 16:29) does not work.
Is not the same as the build in ulefone forum.
This twrp works: http://ota.cm.mkoas.de:8080/job/TWRP Ulefone Metal/ws/recovery.img
dropbear2 said:
This build twrp in downloads (2016-11-02 16:29) does not work.
Is not the same as the build in ulefone forum.
This twrp works: http://ota.cm.mkoas.de:8080/job/TWRP Ulefone Metal/ws/recovery.img
Click to expand...
Click to collapse
I know, I said I would get round to updating this post as well, I haven't been able to yet as I've been busy
Jonny said:
I know, I said I would get round to updating this post as well, I haven't been able to yet as I've been busy
Click to expand...
Click to collapse
sorry,
I thought that you replaced.
Thread updated with the new links (eventually!).
Apologies for the delay
Hey,
i've flashed TWRP and when i boot it, the phone just shows the ulefone logo and then restarts..
I tried to flash with flashtools and via fastboot flash recovery...
Its possible to flash custom rom, which works quite nice, but TWRP won't come up so i can't root phone or do nandroid backups.
Any help? Any idea how to get logs of what happening?
BTW: reflashed offical stock does the same, displays ulefone logo and reboots..
EDIT:
Flashed recover as boot, and boot as recovery:
Normal boot (should start TWRP now) reboots all the time.
Recovery boot (should boot normal boot.img now) works and boots the System..
So there has to be a problem with the downloaded TWRP/Recovery Image not working on my phone..
It's normal Ulefone Metal don't know why it doesn't work.. wpuld like so see some logs or something
Edit2:
Flashed twrp-3-0-2-4es-by-mdsdev from needrom,
which worked.. don't know why any other one didn't...
I can not find the scatter mentioned in the post. I tried to install it with another scatter or another TWRP, but when I try to run the recovery it simply restarts.
Regards, I inform you that I have been doing a series of tests on my mobile, to try to flash some existing roms. For now the following happens: The official firmware from the 20160912 and lower version do not work (I still have to try the 20161019 version), the 20161024 and 20161117 versions work correctly.
Another error, for now the one that has me more restless is the following: The only functional recovery is the TWRP of the user hanuma50 that has incompatibility with certain roms, the other versions of TWRP available do not work, when trying to install it using SPFT , Flashify or from the same TWRP are installed correctly, but at the time of running it simply restarts the mobile and starts the system normally.
I'm thinking because it is because there is surely a new batch of mobile with changes to the hardware, but I do not know, Do you know anything about it?
Another thing, if the darksense kernel flashed the mobile stops working (it enters an infinite loop with the Ulefone logo), it was tested in stock rom and in the Eragon rom.
sinrequilorios said:
Regards, I inform you that I have been doing a series of tests on my mobile, to try to flash some existing roms. For now the following happens: The official firmware from the 20160912 and lower version do not work (I still have to try the 20161019 version), the 20161024 and 20161117 versions work correctly.
Another error, for now the one that has me more restless is the following: The only functional recovery is the TWRP of the user hanuma50 that has incompatibility with certain roms, the other versions of TWRP available do not work, when trying to install it using SPFT , Flashify or from the same TWRP are installed correctly, but at the time of running it simply restarts the mobile and starts the system normally.
I'm thinking because it is because there is surely a new batch of mobile with changes to the hardware, but I do not know, Do you know anything about it?
Another thing, if the darksense kernel flashed the mobile stops working (it enters an infinite loop with the Ulefone logo), it was tested in stock rom and in the Eragon rom.
Click to expand...
Click to collapse
It is not my fault if existing ROM's don't flash properly, we faced this problem on Elephone P9000, it is because the people who develop the ROM's don't use the proper mount points, if they did, it would flash. Instead, they use the mount points for the ported recoveries which are not correct.
End of story, not my fault and I will not support the people that this happens to.
sinrequilorios said:
Regards, I inform you that I have been doing a series of tests on my mobile, to try to flash some existing roms. For now the following happens: The official firmware from the 20160912 and lower version do not work (I still have to try the 20161019 version), the 20161024 and 20161117 versions work correctly.
Another error, for now the one that has me more restless is the following: The only functional recovery is the TWRP of the user hanuma50 that has incompatibility with certain roms, the other versions of TWRP available do not work, when trying to install it using SPFT , Flashify or from the same TWRP are installed correctly, but at the time of running it simply restarts the mobile and starts the system normally.
I'm thinking because it is because there is surely a new batch of mobile with changes to the hardware, but I do not know, Do you know anything about it?
Another thing, if the darksense kernel flashed the mobile stops working (it enters an infinite loop with the Ulefone logo), it was tested in stock rom and in the Eragon rom.
Click to expand...
Click to collapse
Jonny said:
It is not my fault if existing ROM's don't flash properly, we faced this problem on Elephone P9000, it is because the people who develop the ROM's don't use the proper mount points, if they did, it would flash. Instead, they use the mount points for the ported recoveries which are not correct.
End of story, not my fault and I will not support the people that this happens to.
Click to expand...
Click to collapse
I think here's some confusion. As far as I understand it, it's not a problem of neither the recovery, nor wrong mount points.
There's just a newer revision of the model it seems. This newer models only work with recovery, built against stock pre-built kernel (aka ports).
Our rom is built for being flashed by this recovery, because this recovery is the only compiled one. Unfortunately, there's nothing which can be done without ulefone updating the kernel source code.
DerTeufel1980 said:
I think here's some confusion. As far as I understand it, it's not a problem of neither the recovery, nor wrong mount points.
There's just a newer revision of the model it seems. This newer models only work with recovery, built against stock pre-built kernel (aka ports).
Our rom is built for being flashed by this recovery, because this recovery is the only compiled one. Unfortunately, there's nothing which can be done without ulefone updating the kernel source code.
Click to expand...
Click to collapse
Provide me with the device source to build this recovery from then, instead of hiding your source in a private bit bucket repo. I'm Jonathon Fitch, the guy who's source you probably based yours on. The least you could do is share...
Jonny said:
Provide me with the device source to build this recovery from then, instead of hiding your source in a private bit bucket repo. I'm Jonathon Fitch, the guy who's source you probably based yours on. The least you could do is share...
Click to expand...
Click to collapse
Ug..
GPL source code is provided on our Metal thread...
https://github.com/MediatekAndroidDevelopers/android_kernel_ulefone_metal
Cheers
M.A.D. Team
Jonny said:
Provide me with the device source to build this recovery from then, instead of hiding your source in a private bit bucket repo. I'm Jonathon Fitch, the guy who's source you probably based yours on. The least you could do is share...
Click to expand...
Click to collapse
Of course we didn't build upon your kernel. Why should we have done this?
We are using your recovery, or more detailed, we are suggesting to use your recovery.
What's your problem? We did not disrespect you in any way.
Sent from my Thor using Tapatalk
DerTeufel1980 said:
Of course we didn't build upon your kernel. Why should we have done this?
We are using your recovery, or more detailed, we are suggesting to use your recovery.
What's your problem? We did not disrespect you in any way.
Sent from my Thor using Tapatalk
Click to expand...
Click to collapse
^^ THIS

Kernal Source Released

The Kernal Source has been released by Razer.
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
It has been talked about already but not in this section. This is where it belongs and nice job posting direct links to it.
https://forum.xda-developers.com/razer-phone/how-to/source-code-posted-t3719665
MedicStuder said:
Surprised no one else posted in the section with this. The Kernal Source has been released by Razer which means modding can start.
https://www.xda-developers.com/razer-phone-kernel-source-code/
http://www.androidpolice.com/2017/12/15/kernel-source-code-just-released-razer-phone/
https://www.gizchina.com/2017/12/16/razer-releases-kernel-source-files-razer-phone/
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
Click to expand...
Click to collapse
I mentioned it in the factory image thread 5 days ago
Mods, can we pin this in the dev section since it contains the links to the needed source code for development purposes. Seems appropriate to have it pinned in this thread. thanks.
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
MishaalRahman said:
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
Click to expand...
Click to collapse
No way! :victory:
That's the best news I've heard yet
---------- Post added at 04:44 AM ---------- Previous post was at 04:30 AM ----------
jcadduono said:
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Click to expand...
Click to collapse
I'm willing to temporarily sacarfic my device for this. I will message you tomorrow morning and we can give it a shot.
We have lift off! @jcadduono you were right :highfive:
Waiting on you for further instructions on how to proceed.
Even if this leads to no where it sure feels damn good to see the twrp logo.
Everything is going well, we're getting copies of each partition and I'm working on making factory restorable images right now.
I am fairly certain I can even support encryption on this device with no issues.
The device itself actually supports hardware Qualcomm full-disk encryption like most non-Google Qualcomm devices so it's nothing new!
However, the Razer Phone supports HW encrypted SDcards like LG does, so TWRP needs support in the actual crypto code used in the project to work with encryptable sdcards. Maybe Dees_Troy will be up to that task when he gets his phone.
TWRP images will be distributed like so:
- A twrp.img file that you flash to your active boot partition
- A zip file that copies the TWRP ramdisk from your active boot partition into your inactive boot partition, then copies your inactive boot partition to your active boot partition
The zip file will effectively install TWRP and the next time you boot TWRP it will be relying on your ROM's kernel instead of the TWRP kernel.
jcadduono said:
Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
Click to expand...
Click to collapse
@jcadduono Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
P.s I'll take a pop if you want a second test
thread stuck like Chuck for now, hopefully we can get some dev going for this device.
yeahh !!!!!!! wake up dev teams !!
Any information regarding Franco kernel?

[UNOFFICIAL][ENCRYPTION][wrappedkey] TWRP 3.3.1-6: proper system_as_root & decryption

[UNOFFICIAL][ENCRYPTION][wrappedkey] TWRP 3.3.1-6: proper system_as_root & decryption
Code:
/*
* I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed (like it did for me...).
* Please do some research if you have any concerns about features included in the products you find here before flashing it!
* YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
* Your warranty will be void if you tamper with any part of your device / software.
* Same statement for XDA.
*/
Introduction
This is an unofficial build of TWRP for Redmi Note 7 Pro (violet). Differences with the official one include:
- Supports CAF-based wrappedkey encryption (decryption) properly (tested with MIUI 10.3.5.0)
- Supports decrypting devices that have screen lock set up after Android 9 May update, which introduced a new key derivation function.
- Mounts the system partition at /system_root as per AOSP standards. This makes the auto-backup scripts (e.g. GApps / Magisk survival script) work properly during updates, and you no longer need any 'patch' to flash GApps / Magisk properly. However, this may break some existing ROMs. See below FAQ section for details.
- Appended DTBO to the recovery image so it doesn't depend on the dtbo partition. No standalone DTBO image required.
Flashing instructions
- Download and extract the img file
- Reboot to fastboot mode
- fastboot flash recovery whatever_img_file_you_extracted.img
- Reboot and press Volume + to enter recovery
- DO NOT try to run 'fastboot boot recovery.img', it won't work.
- DO NOT flash the fcrypt disabler if you use my recovery. There is no need to do so, and it is possible to mess stuff up if you don't know what you are doing.
- You have to format the data partition if and ONLY IF:
1) You were not encrypted, now going to an encrypted state, or vice-versa OR
2) You were on a ROM other than MIUI that does not support "wrappedkey" (ROMs would often state it supports wrappedkey if it does), now going to a ROM that supports it
Limitations
DO NOT boot this recovery with empty system and vendor partitions. It will fail to decrypt any data partition with empty /system and /vendor. DO NOT wipe system and vendor partitions without installing a new one before rebooting. I am working to remove this limitation.
Now works even with empty system and vendor partitions after 3.3.1-5. No need to worry about formatting system and vendor breaking TWRP any more.
The restore zip created by the Migrate app is NOT compatible with this recovery. It's a problem of the Migrate app, not this recovery. Please DO NOT try to flash the restore zip created by Migrate.
FAQ
- Q: Do I need any specific DTBO image to make this recovery working?
- A: Nope. It is appended to the recovery image so it will work with any DTBO.
- Q: What is wrappedkey?
- A: It's a different mode of FBE implemented in CAF, the Qualcomm branch of AOSP.
- Q: This cannot install ROM X, why?
- A: Because it mounts the system partition at /system_root, which is AOSP standard behavior for A-only system_as_root devices, but is broken in some custom ROMs currently (MIUI should work though). To make any ROM work again, they will need to include this commit from LineageOS Gerrit https://review.lineageos.org/c/LineageOS/android_build/+/247066
- Q: Decryption doesn't work with ROM X, why?
- A: Decryption should work for most ROMs based on the CAF branch (not AOSP). CAF ROMs (including official MIUI) use a different scheme for key storage, which is why TWRP hasn't supported it till now. I have ported the CAF encryption changes (wrappedkey) to TWRP, but unfortunately this will break ROMs that do not support the CAF wrappedkey mode of encryption. Here is a list of patches non-CAF ROMs need to support CAF-encrypted /data partitions https://mokeedev.review/q/topic:%22fbe-wrapped-key%22+(statuspen%20OR%20status:merged). If you confirm your ROM is CAF-based but the decryption still does not work, please open an issue on my GitHub repository which you could find below. (XDA threads are no good for issue tracking, sorry)
- Q: Why not contribute to the official TWRP?
- A: All the patches to the TWRP code base have been submitted to the official gerrit code review, though not merged yet, which you can see below.
Downloads
3.3.1-6: https://mega.nz/#!3QIRQYhK!Jq5QrGfJw5VCYZ8sq_BO1qNZecrFqlM9IB1IdSwogvI
changes: updated kernel to support pstore instead of /proc/last_kmsg. If you don't know what this is, it's probably not relevant to you.
Here you can find an unofficial LOS build with wrappedkey encryption and also proper system_as_root support for those survival scripts https://forum.xda-developers.com/redmi-note-7-pro/development/unofficial-lineageos-16-caf-encryption-t3933532. In addition, all official MIUI builds should flash just fine.
History versions:
3.3.1-5: https://mega.nz/#!nMowHKiL!zRvoTM0iIZKArmUDnZzaEFtXQv0_q7hIHUCmTHTOmOM
changes: 1) Now works even with empty /system and /vendor partition 2) Fixed brightness problem; 3) Enabled EDL Reboot
3.3.1-3: https://mega.nz/#!yAYXxAzZ!FNMYLzLphnSmJ-DbBx-OZUgxxYiftgn8e4Jn3kxiQik
Patches and sources
Patches for TWRP are available here:
https://gerrit.omnirom.org/#/c/34091/
https://gerrit.omnirom.org/#/c/34093/
https://gerrit.omnirom.org/#/c/34092/
https://gerrit.omnirom.org/#/c/android_bootable_recovery/+/34096/
Patches for ROMs to support wrapped key have been given in the above sections.
Source of the current device tree for TWRP: https://github.com/PeterCxy/android_device_xiaomi_violet-twrp
Kernel source: https://github.com/PeterCxy/android_kernel_xiaomi_sm6150, note that the device tree uses a prebuilt kernel image.
Contributors
PeterCxy, Dyneteve, merothh
Source Code: https://github.com/PeterCxy/android_device_xiaomi_violet-twrp
Now fixed and tested with MIUI.
PeterCxy said:
Now fixed and tested with MIUI.
Click to expand...
Click to collapse
Could you please tell us what is fixed and what is wrong with the previous one? Just out of curiosity.
I’m not new to installing custom recoveries and installing ROM, but I am new to Xiaomi devices.
In the simplest form possible,
With this I should be able to just run the ‘fastboot install recovery twrp.img’ and not have to run “fastboot erase userdata’?
also
Do I still need to flash the zip I have that disables forced encryption?
Could you provide instructions to flash this ?
Or is it just the same as the 'official one'?
Can confirm this successfully decrypts storage, running xiaomi.eu on my phone. Thanks for your work.
Dwughjsd said:
Could you please tell us what is fixed and what is wrong with the previous one? Just out of curiosity.
Click to expand...
Click to collapse
It did not decrypt MIUI 10.3.5.0 successfully due to magic (I missed some commits from qcom). It was fixed by pulling more commits in.
Jpwner said:
I’m not new to installing custom recoveries and installing ROM, but I am new to Xiaomi devices.
In the simplest form possible,
With this I should be able to just run the ‘fastboot install recovery twrp.img’ and not have to run “fastboot erase userdata’?
also
Do I still need to flash the zip I have that disables forced encryption?
Click to expand...
Click to collapse
You won't need to erase userdata or flash fcrypt disabler anymore, if all the ROMs will update to support the wrappedkey encryption
Naveenthemi said:
Could you provide instructions to flash this ?
Or is it just the same as the 'official one'?
Click to expand...
Click to collapse
just fastboot flash recovery whatever_you_downloaded_and_extracted.img
PeterCxy said:
just fastboot flash recovery whatever_you_downloaded_and_extracted.img
Click to expand...
Click to collapse
So it's possible for me to flash OTA Updates without encountering a bootloop and such?
Can someone please provide an alternate download link? The Mega link doesn't seem to work for me.
EDIT: Worked on a different device. Thanks.
Naveenthemi said:
So it's possible for me to flash OTA Updates without encountering a bootloop and such?
Click to expand...
Click to collapse
+1
Please answer
Good job! ?
I want you to know that your patch has been merged with the official one. I was away for a while so I hope you understand the little unfortunate delay.
In latest update can we flash any custom roms without any issue?
Yogendra Kher said:
In latest update can we flash any custom roms without any issue?
Click to expand...
Click to collapse
You have to wait until custom ROMs pull in necessary system_as_root changes. Currently it seems only my LOS build pulled that in
PeterCxy said:
You have to wait until custom ROMs pull in necessary system_as_root changes. Currently it seems only my LOS build pulled that in
Click to expand...
Click to collapse
Is it possible to flash OTA updates without encountering bootloops and such? (MIUI)
Naveenthemi said:
Is it possible to flash OTA updates without encountering bootloops and such? (MIUI)
Click to expand...
Click to collapse
Should work fine with MIUI. At least from what I have tested.
kushal.purkar said:
+1
Please answer
Click to expand...
Click to collapse
PeterCxy said it would as far as his testing had been done.
Gapps aroma not installing in this one as well. error 255
Can I flash Magisk and root my phone with this build.?
Do you have any Magisk zip file that will work.?
Thank you for your work

[RECOVERY][grus] KudProject's Unofficial TWRP 3.5.2_9-1 [16-05-2021]

This is basically a tl;dr thread.
I don't want to make a thread that everyone will lazy to read.​
Team Win Recovery Project 3.x, or twrp3 for short, is a custom recovery built with ease of use and customization in mind. It's a fully touch driven user interface; no more volume rocker or power buttons to mash. The GUI is also fully XML driven and completely theme-able. You can change just about every aspect of the look and feel.
Disclaimer​
Code:
/*
* Your warranty might not be void (thanks Xiaomi). However...
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this RECOVERY
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Requirements​
Xiaomi Mi 9 SE (of course)
Unlocked bootloader
Some knowledge on how to deal with your device... and patience.
Flashing Instructions​I assume you've done (very) basic steps on preparing to flash your device.
Reboot device to bootloader. If device is powered off, press and hold Power + Volume Down button until tinkering Mi Bunny with "FASTBOOT" text appears.
Optional: Flash stock vbmeta with the following command (attached if needed):
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
Under same directory as TWRP image and ADB/Fastboot executables (if ever required), type this command:
Code:
fastboot flash recovery twrp-3.x.x-y-KudProject-grus.img
Where x and y are version of TWRP you're going to flash.
IMPORTANT: After flashing, immediately press and hold Power + Volume Up for about 10 seconds to reboot to recovery.
Swipe the option to allow modifications. This will prevent stock ROM from replacing recovery, however be aware that you might need to reflash stock vbmeta with disabled verity after that to be able to boot stock ROM!
Downloads
Webserver | MEGA
Old releases only: OSDN | AndroidFileHost
Known Issues​
/dev/null
Special Thanks​
Dees_Troy and everyone behind TWRP
Everyone on Mi 9 SE community
Device Sources​
TWRP repository fork
Device tree
Kernel source
Changelogs​twrp-3.5.2_9-1-KudProject-grus
Merged TWRP source changes up to 25 April 2021 (UTC+8)
Updated kernel to MoeSyndrome kernel based on Android 10
Mount firmware partition as read-only
Added support for formatting Cust partition in GUI
twrp-3.4.0-0-KudProject-grus
Merged TWRP source changes up to 22 June 2020 (UTC+8)
Supports decryption of userdata on Android 10-based MIUI and custom ROMs using Android 10 crypto blobs (might not be backwards compatible)
Restored system and vendor (non-image) backup support
Added support for backing up persist (and the image)
Build some blobs from source
Updated remaining blobs from V11.0.2.0.QFBEUXM
Updated prebuilt kernel to latest Pie
twrp-3.3.1-3-grus-20190802
Switched to source-built kernel
Updated blobs from MIUI China developer 9.7.4
Added support for F2FS in kernel (tell me if decryption breaks on this file system though)
Added persist into fstab
Added vendor-side touch firmware
Get CPU temperature from proper thermal zone
Disabled vbmeta checks
Only allow image backups for system and vendor
Symlinked /system to /system_root/system for backward compatibility
Misc stuffs
TWRP and f2fs-tools upstream changes
twrp-3.3.1-2-grus-20190609
Fixed wrong USB-OTG mount point
twrp-3.3.1-1-grus-20190603
Updated prebuilt kernel and DTBO from MIUI China developer 9.5.30
Corrected vendor image flashing
Support for wiping /vendor
Support for flashing and backup up (as part of boot) DTBO
Defined TW_SCREEN_BLANK_ON_BOOT
(Properly) excluded TWRP app
Included private recovery configuration
twrp-3.3.1-0-grus-20190531
Initial build.
Notes​
Don't use fastboot boot to boot the recovery; it'll proceed to boot system instead using recovery's kernel. If this happens with your current kernel's boot image security patch being older than recovery one, you're basically busted as FBE keys are upgraded the time newer combination of system + vendor + boot image security patches are detected.
If you're out of luck in this situation, the only way to resolve is to format data (just backup your data to somewhere safe before doing so).
If you flash disabled vbmeta, you can't flash stock MIUI zips until the original vbmeta is restored.
Wrapped key support is added into recovery just for anticipation, although not defined by default in fstab.
I can't test it since EEA device so far is on March ASB as of V10.2.5.0 stable.
Otherwise, basic functionalities including decryption should work.
Edit: grus doesn't have anti rollback enabled at this moment, but Xiaomi may enable it in the future...
it is save changed from wzsx150 twrp ? or must on fastboot ?
bonbibonkers said:
it is save changed from wzsx150 twrp ? or must on fastboot ?
Click to expand...
Click to collapse
If already on any version of TWRP, just flash it using Flash Image option to recovery partition.
ok, gonna test it out , many thanks great work ??
Thanks! working so far so good
krasCGQ said:
If already on any version of TWRP, just flash it using Flash Image option to recovery partition.
Click to expand...
Click to collapse
Working fine when flashing from wzsx150 twrp version.
krasCGQ said:
If already on any version of TWRP, just flash it using Flash Image option to recovery partition.
Click to expand...
Click to collapse
i already flash it, worked good. but the CPU Temps is little misreading, i think.... it can go up to 80° C lol
rzki03 said:
i already flash it, worked good. but the CPU Temps is little misreading, i think.... it can go up to 80° C lol
Click to expand...
Click to collapse
Just ignore it. That same CPU temperature glitch also happens on sirius.
Wow, finally an *actual* twrp
Sent from my Mi 9 SE using Tapatalk
krasCGQ said:
Just ignore it. That same CPU temperature glitch also happens on sirius.
Click to expand...
Click to collapse
okay then. thank you!
@krasCGQ
Hey, in next release can you add the option to backup and recover dtbo partion/image like with this recovery https://forum.xda-developers.com/mi-9-se/how-to/recovery-twrp-lr-team-wzsx150-v3-3-0-t3926219 ?
Thanks
denzel09 said:
@krasCGQ
Hey, in next release can you add the option to backup and recover dtbo partion/image like with this recovery https://forum.xda-developers.com/mi-9-se/how-to/recovery-twrp-lr-team-wzsx150-v3-3-0-t3926219 ?
Thanks
Click to expand...
Click to collapse
So this release doesn't have Backup/Restore working?
luisbelmont said:
So this release doesn't have Backup/Restore working?
Click to expand...
Click to collapse
Yes, it has. My request was a bit different.
denzel09 said:
Yes, it has. My request was a bit different.
Click to expand...
Click to collapse
Oh, perfect! Thank you. What advantages does your request have?
luisbelmont said:
Oh, perfect! Thank you. What advantages does your request have?
Click to expand...
Click to collapse
To backup and recover dtbo image before and after flashed this custom kernel: https://forum.xda-developers.com/mi...nel-okitakernel-v1-0-mi-9-se-27-2019-t3934029
Thanks for the work! Great seeing you here after ZenFone 2 and Redmi Note 4. Hopefully a KudKernel will be in the works(if not already).
puppetminds said:
Thanks for the work! Great seeing you here after ZenFone 2 and Redmi Note 4. Hopefully a KudKernel will be in the works(if not already).
Click to expand...
Click to collapse
Kinda off-topic, but well rebasing over CAF is a tough job...
Sent from my Mi 9 SE using XDA Labs

Categories

Resources