Development - [RECOVERY] [3.7.0-12.1] [UNOFFICIAL] [UNIFIED] TWRP with A12/A13 e...

[RECOVERY] [11] [OFFICIAL] TeamWin Recovery Project

Introduction: Team Win Recovery Project or...

forum.xda-developers.com

1. Download the twrp-installer zip
2. Flash it with magisk manager or some other kernel flash utility
3. Reflash your custom kernel and magisk if previously installed

1. Download the twrp-installer zip
2. Flash it with "adb sideload twrp-installer*.zip"
3. Reboot to recovery
4. Reflash your custom kernel and magisk if previously installed

1. Backup your ROM vendor_boot image. For most custom ROMs this can usually be downloaded. If you can't find a download, you can get it for example by extracting it from the payload.bin inside a full update zip with payload-dumper-go.
2. Download TWRP boot.img and vendor_boot.img
3. Reboot to bootloader
4. Run "fastboot flash vendor_boot vendor_boot.img" with the TWRP vendor_boot image
5. Run "fastboot boot boot.img" with the TWRP boot image
6. Go to Advanced > Flash Current TWRP
7. Reflash your custom kernel and magisk if previously installed
8. Reboot to bootloader
9. Run "fastboot flash vendor_boot vendor_boot.img" with the ROM vendor_boot image from step one

1. Download and flash the twrp-installer zip
2. After that reflash your custom kernel and magisk if previously installed

• Vibration is not working
• Screen does not turn off when pressing power button
• vendor_dlkm mount error on OOS, but doesn't affect functionality
• ADB doesn't work in fastbootd mode
• In case you notice anything else please let me know.

• @Nebrassy for the original device tree
• @osm0sis for the installer zip
• TWRP team
• LineageOS

der_akinator said:

Update

Hi everyone,
I just uploaded a new build. It fixes some missing firmware files and kernel module loading.
USB OTG, vibration and battery status is now working.

Download:

29.11.22 - Google Drive

drive.google.com

Click to expand...

osm0sis said:

Does the A/B flashable zip with the TWRP ramdisk in it work to install it? Might be able to skip the vendor_boot steps that way.

GitHub - osm0sis/twrp_abtemplate: TWRP A/B Installer Zip Template

TWRP A/B Installer Zip Template. Contribute to...

github.com

der_akinator said:

I will try it. Thanks for your tip.

I tried it out over latest Lineage and it does seem to work! I even then re-rooted with Magisk and re-flashed blu_spark from within TWRP.

Only issue (but it's pretty big) is that vibration is broken and it seems to hang the UI hard any time it tries to vibe, so my workaround is to hit Cancel at the Decrypt page, go to Settings and turn all the vibration down to 0, then go back to Mount and Decrypt Data from there. (You can also just be verrrrrry patient when doing pattern.)

Not sure if this is because I installed the whole ramdisk directly like that or because it's over Lineage. I'm guessing the latter, with some kind of modules mismatch?

Any ideas how to resolve that? Disabling vibration entirely might be needed, since I recall @Nebrassy never got it working across all ROMs.

Either way, being able to use the TWRP zips will save a lot of headaches for rooted users.

P.S. Also great that vendor_boot is only need for fastboot tempboot, since that means my twrp_ab addon.d-v2 script should work for us already!

P.P.S. We need to get you in the TWRP Development Zulip if you're not lurking there already: https://rebrand.ly/teamwin-recovery-zulip-community

Edit: twrp-installer-3-7-0_12-0-20221129-lemonadep-zip attachment removed since a newer build exists.

TheSayaMan said:

You flash the twrp one in order to boot twrp, then after permanent install, you flash yours or it won't boot to os

Now that there's a TWRP zip you could skip vendor_boot shenanigans altogether by, a) flash from Magisk app, or even b) flash from custom ROM recovery like Lineage Recovery.

Flecto said:

Thank you so much @der_akinator! I have tested your build on my OnePlus 9 Pro with stock OxygenOS 12 (C.48) and stock OxygenOS 13 (F.17).

Decryption works in both cases (I only have one default user, user 0, and I use a numeric PIN). I do get the error message "Failed to mount '/vendor_dlkm' (Block device required" (rest is cut off) a few times at the beginning and also when starting a backup. But I think that has already been discussed in earlier messages and can safely be ignored, as I understand.

With OOS 12 I was able to do a backup successfully. But with OOS 13 I ran into the "createTarFork() process ended with ERROR: 255" issue that others have seen as well. As with the others who encountered it, I hit it when backing up /data/fonts/files. While TWRP recovery was open, I opened a shell with adb to figure out what is going on. The /data/fonts/files folder looked like this for me:

Code:

OnePlus9Pro:/data/fonts/files # ls -lah
total 27K
drwxrwx--x 9 system system 3.3K 2022-12-03 13:16 .
drwxrwx--x 4 root   root   3.3K 1970-12-21 00:39 ..
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~Dq2S8kVqf-Dc6LKcUPIxAg==
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~MH9JbGNsVi5FNqTFxYOkzw==
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~PDIpcvjXWCGB0L9vu4bRVQ==
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~i9uxPse9gJwQHVMzvWO_ew==
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~ifyxiQTJ82tMnh85d-S_oQ==
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~vVr66c0Pht6y0-g70ZEL1A==
drwx--x--x 2 system system 3.3K 2022-12-03 13:16 ~~zZmOMCJqZPx76zYvxoauLA==

Inside each directory is a font file and those files cannot be read:

Code:

OnePlus9Pro:/data/fonts/files # cat */*
cat: ~~Dq2S8kVqf-Dc6LKcUPIxAg==/GoogleSansText-Medium.ttf: Required key not available
cat: ~~MH9JbGNsVi5FNqTFxYOkzw==/NotoColorEmoji.ttf: Required key not available
cat: ~~PDIpcvjXWCGB0L9vu4bRVQ==/GoogleSans-Regular.ttf: Required key not available
cat: ~~i9uxPse9gJwQHVMzvWO_ew==/GoogleSansText-Bold.ttf: Required key not available
cat: ~~ifyxiQTJ82tMnh85d-S_oQ==/GoogleSans-Medium.ttf: Required key not available
cat: ~~vVr66c0Pht6y0-g70ZEL1A==/GoogleSans-Bold.ttf: Required key not available
cat: ~~zZmOMCJqZPx76zYvxoauLA==/GoogleSansText-Regular.ttf: Required key not available

So these fonts just cannot be read and that's why the backup failed. It failed exactly when it tried to read the first of those files (which happened to be /data/fonts/files/~~MH9JbGNsVi5FNqTFxYOkzw==/NotoColorEmoji.ttf. Here is the relevant entry from recovery.log:

Code:

...
I:addFile '/data/fonts' including root: 1
  ==> set selinux context: u:object_r:system_data_file:s0
found fscrypt policy '/data/fonts' - '2DK' - '2312b5d79eb868cb6ff02d908d0fe1a7'
I:addFile '/data/fonts/files' including root: 1
  ==> set selinux context: u:object_r:font_data_file:s0
found fscrypt policy '/data/fonts/files' - '2DK' - '2312b5d79eb868cb6ff02d908d0fe1a7'
I:addFile '/data/fonts/files/~~MH9JbGNsVi5FNqTFxYOkzw==' including root: 1
  ==> set selinux context: u:object_r:font_data_file:s0
found fscrypt policy '/data/fonts/files/~~MH9JbGNsVi5FNqTFxYOkzw==' - '2DK' - '2312b5d79eb868cb6ff02d908d0fe1a7'
I:addFile '/data/fonts/files/~~MH9JbGNsVi5FNqTFxYOkzw==/NotoColorEmoji.ttf' including root: 1
  ==> set selinux context: u:object_r:font_data_file:s0
I:Error adding file '/data/fonts/files/~~MH9JbGNsVi5FNqTFxYOkzw==/NotoColorEmoji.ttf' to '/data/media/0/TWRP/BACKUPS/fd144c5b/2022-12-03--12-20-33/data.f2fs.win019'
Error creating backup.
I:ERROR tarList for thread ID 0
Error creating backup.
I:InfoManager saving '/data/media/0/TWRP/BACKUPS/fd144c5b/2022-12-03--12-20-33/data.info'
createTarFork() process ended with ERROR: 255
Backup Failed. Cleaning Backup Folder.
...

After deleting the entire folder /data/fonts/files, the backup worked. It would probably be great if the TWRP backup code would be able to catch this error and continue with just throwing a warning instead of crashing. But I expect that might be something that needs to be fixed in the common TWRP source since it may not be specific to the OnePlus 9 Pro device.

By the way, there are plenty of files listed in the recovery.log that have "found fscrypt policy" and they all seem to be backed up without issue. Some of those files are even within a folder with a scrambled name (starting with ~~ and ending with ==). So there is something special about these font files.

For those interested, here is how I performed the upgrade. I started on OxygenOS 11.

1) Install the system update from the settings (it showed the update was about 4 GB large and called C.48)
2) BEFORE rebooting after the upgrade: use Magisk app to flash the twrp-installer zip from this thread (will flash to slot A and B)
3) BEFORE rebooting using the Magisk app reinstall Magisk; I did BOTH direct install (will flash to active slot) and install after OTA (will flash to inactive slot)
4) NOW reboot and verify everything works
5) Then the system upgrade showed me the update to OOS 13 (F.17) but it showed it was only 1-poin-something GB in size. So I decided to use the Oxygen Updater app, which downloaded the full F.17 upgrade (over 4 GB). I followed the instructions in Oxygen Updater to apply the update (had to install OPLocalUpgrade)
6) Repeat steps 2 and 3 above.
7) Now reboot, verify everything works and do another backup in TWRP

Click to expand...

First of all thanks for your extensive test and documentation.

About vendor_dlkm:
The current solution isn't very nice, but I have to specify vendor_dlkm in fstab to mount it on device with LOS based ROMs because that's the partition containing necessary kernel modules for USB OTG, battery status etc. Unfortunately OOS isn't using a separate partition for that and stores modules directly on the vendor partition. Luckily this only throws an error but doesn't crash. To fix this I would have to build two versions with and without the vendor_dlkm entry in recovery.fstab.

About failing backups:
I have read a bit about fscrypt which is used for android's encryption. The "fscrypt policy" lines in recovery.log only give information about which policy and key is used to encrypt a directory and all subdirectories or single files. Whats interesting is the 32 character string at the end of each line that is an ID of the key used for encryption. "2DK" just means FBEv2 encryption method is used. I think /data/fonts/* is encrypted with a different key than the one derived by your initial password/pattern input. You can check that by comparing the ID of /data/fonts/* with an ID of any other directory under /data.
Reading directories that can't be decrypted by TWRP doesn't seem to be problematic but accessing one of those files is. A possible fix for this could be to store key IDs that TWRP has access to and compare them with the key ID of the currently accessed directory. If it's a match continue else backoff and try next node.
I will try to apply this idea to TWRP's tar wrapper next week.