Yes on other devices with android-11 branch both work.
For encryption: GitHub - TeamWin/android_device_qcom_twrp-common: TWRP standard device files for Qualcomm SoCs
Haptic is the driver for the vibrator, correct? Looking up for “aw8695_haptic” I found your description here when you added it to the linux kernel 
:
Indeed looking at the dmesg (and logcat) some errors are correlated to this:
[ 6.368098] aw8695_ram_work_routine enter
[ 6.368195] aw8695_haptic 2-005a: Falling back to syfs fallback for: aw8695_haptic.bin
[ 6.371161] aw8695_ram_loaded enter
[ 6.371167] aw8695_ram_loaded: failed to read aw8695_haptic.bin
[ 6.371172] aw8695_ram_loaded:start hrtimer:load_cont1
[ 7.366073] init: starting service 'adbd'...
[ 7.366551] init: Created socket '/dev/socket/adbd', mode 660, user 1000, group 1000
[ 7.368607] init: starting service 'recovery'...
[ 7.368953] init: Created socket '/dev/socket/recovery', mode 422, user 1000, group 1000
[ 7.390804] read descriptors
[ 7.390876] read strings
[ 7.391470] init: processing action (sys.usb.config=adb && sys.usb.configfs=1 && sys.usb.ffs.ready=1) from (/system/etc/init/hw/init.rc:199)
[ 7.392070] aw8695_ram_work_routine enter
[ 7.392124] aw8695_haptic 2-005a: Falling back to syfs fallback for: aw8695_haptic.bin
[ 7.394792] ueventd: firmware: loading 'aw8695_haptic.bin' for '/devices/platform/soc/990000.i2c/i2c-2/2-005a/firmware/aw8695_haptic.bin'
[ 7.395047] ueventd: firmware: could not find firmware for aw8695_haptic.bin
[ 7.395061] ueventd: firmware: attempted /etc/firmware/aw8695_haptic.bin, open failed: No such file or directory
[ 7.395073] ueventd: firmware: attempted /odm/firmware/aw8695_haptic.bin, open failed: No such file or directory
[ 7.395084] ueventd: firmware: attempted /vendor/firmware/aw8695_haptic.bin, open failed: No such file or directory
[ 7.395095] ueventd: firmware: attempted /firmware/image/aw8695_haptic.bin, open failed: No such file or directory
[ 7.395164] ueventd: loading /devices/platform/soc/990000.i2c/i2c-2/2-005a/firmware/aw8695_haptic.bin took 0ms
[ 7.395213] aw8695_ram_loaded enter
[ 7.395218] aw8695_ram_loaded: failed to read aw8695_haptic.bin
[ 7.395223] aw8695_ram_loaded:start hrtimer:load_cont2
Is this blob have to be manually extracted and added somewhere inside TWRP build folder?
Looking inside the /vendor/firmware/ directory on my FP4 phone, those two files are present:
aw8695_haptic.bin
aw8695_osc_rtp_24K_5s.bin
The kernel driver (probably) works in TWRP but it exposes a non-standard sysfs interface so the HAL from Android needs to be used that works with that one.
Trying to add vendor.qti.hardware.vibrator.service my notes say “Locks up the UI, no adb available”, so sounds relatively similar to the behavior with the userdata decryption libraries present. If someone wants to try further this is what I had last time: [WIP] FP4 vibrator · z3ntu/android_device_fairphone_FP4@091badc · GitHub
edit: once the HAL is working, the aw8695 “firmware” (it’s defining the waveform used for haptics so it’s more data than firmware) is very likely needed,
Is this non-standard syfs interface for aw8695_haptic related to the hardware, or specific to FP4?
In other words, if I take another device using AW8695 (just as an example Motorola Nio ), is the TWRP port for this device likely suffering from the same issue? 
Looking for “syfs fallback” in the dmesg I found two other similar lines to the aw8695_haptic one:
[ 2.411813] msm-dsi-display soc:qcom,dsi-display-primary: Falling back to syfs fallback for: iris6.fw
[...]
[ 3.712157] himax_tp 1-0048: Falling back to syfs fallback for: Himax_firmware.bin
Are those two firmware to be fixed as well?
@oli.sax I believe the modifications to the HAL is only for the aw8695 driver, so specific to that, not to FP4. What might be different to the Motorola device that the HAL is now AIDL and not HIDL, which changed with recent Android versions, but it might be possible that the Motorola HAL also works on FP4.
I haven’t looked too much into Himax_firmware.bin and iris6.fw but I’m quite certain they’re not needed for normal operation.
1 Like
Do you have a clear idea of where/which decryption library is failing?
Looking up for “decrypt” in dmesg/logcat I see nothing, and in recovery.log there is this part:
part of recovery.log when TW_INCLUDE_CRYPTO := true
I:Unable to mount '/data'
I:Actual block device: '/dev/block/sda11', current file system: 'f2fs'
I:Backup folder set to '/data/media/TWRP/BACKUPS/ef69ff96'
I:Settings storage is '/data/media'
DEBUG:prepdecrypt::Running prepdecrypt script for TWRP...
I:prepdecrypt::File Based Encryption (FBE) is present.
DEBUG:prepdecrypt::SDK version: 30
DEBUG:prepdecrypt::DEFAULTPROP variable set to prop.default.
DEBUG:prepdecrypt::A/B device detected! Finding current boot slot...
DEBUG:prepdecrypt::Current boot slot: _b
DEBUG:prepdecrypt::SETPATCH Override flag found.
DEBUG:prepdecrypt::Device has recovery partition!
DEBUG:prepdecrypt::Resetprop binary not found. Falling back to setprop.
DEBUG:prepdecrypt::Recovery/Fastbootd mode boot detected.
DEBUG:prepdecrypt::SETPATCH Override flag found.
I:prepdecrypt::SETPATCH=true
DEBUG:prepdecrypt::Build tree is Oreo or above. Proceed with setting props...
DEBUG:prepdecrypt::Temporary vendor folder created at /v.
DEBUG:prepdecrypt::vendor mounted at /v.
DEBUG:prepdecrypt::prepdecrypt.vendor_mounted=1
DEBUG:prepdecrypt::Vendor Build.prop exists! Reading vendor properties from build.prop...
DEBUG:prepdecrypt::Current vendor Android SDK version: 30
DEBUG:prepdecrypt::Current vendor is Oreo or above. Proceed with setting vendor security patch level...
DEBUG:prepdecrypt::Current Vendor Security Patch Level: 2127-12-31
E:prepdecrypt::setprop failed. Vendor Security Patch Level unchanged.
DEBUG:prepdecrypt::prop.default update successful! ro.vendor.build.security_patch=2021-12-05
DEBUG:prepdecrypt::System-as-Root device detected! Updating build.prop path variable...
DEBUG:prepdecrypt::Build.prop location set to system/build.prop.
DEBUG:prepdecrypt::Temporary system folder created at /s.
DEBUG:prepdecrypt::system mounted at /s.
DEBUG:prepdecrypt::prepdecrypt.system_mounted=1
DEBUG:prepdecrypt::Build.prop exists! Reading system properties from build.prop...
DEBUG:prepdecrypt::Current system Android SDK version: 30
DEBUG:prepdecrypt::Current system is Oreo or above. Proceed with setting OS Version & Security Patch Level...
DEBUG:prepdecrypt::Current OS Version: 11
DEBUG:prepdecrypt::setprop successful! New OS Version: 11
DEBUG:prepdecrypt::prop.default update successful! ro.build.version.release=11
DEBUG:prepdecrypt::Current Security Patch Level: 2127-12-31
E:prepdecrypt::setprop failed. Security Patch Level unchanged.
DEBUG:prepdecrypt::prop.default update successful! ro.build.version.security_patch=2021-12-05
I:prepdecrypt::crypto.ready=1
I:prepdecrypt::Script complete. Device ready for decryption.
Starting TWRP 3.6.0_11-0-bee26852 on Sat Feb 19 19:58:49 2022
(pid 638)
I:Lun file '/sys/class/android_usb/android0/f_mass_storage/lun0/file' does not exist, USB storage mode disabled
PRODUCT_USE_DYNAMIC_PARTITIONS := true
TW_INCLUDE_CRYPTO := true
The only error I see here is linked to the patch level (I guess?)
DEBUG:prepdecrypt::Resetprop binary not found. Falling back to setprop.
E:prepdecrypt::setprop failed. Vendor Security Patch Level unchanged.
E:prepdecrypt::setprop failed. Security Patch Level unchanged.
Then the prepdecrypt says it succeeded, but just after the device automatically reboot - and continue rebooting every 10 seconds. So strange
I:prepdecrypt::crypto.ready=1
I:prepdecrypt::Script complete. Device ready for decryption.
Starting TWRP 3.6.0_11-0-bee26852 on Sat Feb 19 19:58:49 2022
(pid 638)
Booting the twrp image in the description causes me the phone stuck at the logo in boot up. FP4 Iode os. Any idea? Thanks
Strange, for me it works correctly (on stock OS)
Are you doing fastboot boot twrp.img or fastboot flash recovery twrp.img ? (I do the first one)
The first one too. fastboot boot twrp.img
Kurze Frage mal meinerseits
Um ein Backup der system PArtiotion zu machen, nützt mir TWRP nun nichts, da diese mit in der super PArtion abliegt und diese super verschlüsselt ist. Richtig?
Heißt für Backups auf dem FP4 ist TWRP ungeeignet.
Da muss ich anders ran.
Hallo @AlphaElwedritsch !
Ich antworte deine Frage in Englisch 
Ich hoffe das is OK fur dich.
Indeed, in its current state of development TWRP is useless for doing backups, as system and userdata partitions are not successfully decrypted.
TWRP without decryption ability has few use, for example:
- back-up of the Boot partition (for rooting it with Magisk)
- flashing the Ubuntu Touch system image (instructions are to erase the userdata partition so that is doesn’t have encryption)
But in my opinion the full potential of TWRP could only be with decryption, that’s why I made some trials to include it (unfortunately without success)
6 Likes
Have somebody tried to decrypt the FP4 successfully ? With dynDFE.zip?
@Aaanze , @hirnsushi for example…
What is it? Could you explain a little? I searched it up and only found some direct download links (on androidfilehost or sourceforge). Is it an opensource tool or closed-source?
Nope, this stuff is out of my league 
I had to google it as well and couldn’t find sources either, not that uncommon with tools like that, but still… 
I’ve seen it’s used in LeOS, does @harvey186 know where it’s from?
It’s 32°C at my desk right now so I’m not gonna test something that might make me stay here longer getting my phone back to a working state, sorry 
2 Likes
it’s a script for removing force encryption setup from device fstab. Nothing more. You can do it also by hand if your vendor image is writeable. The zip is for using with TWRP
It is from a developer in PHH treble telegram group / xda member. there are 2 versions. DisableForceEncryption.zip for devices without super partition and dynDFE.zip for devices with super partition.
And on my desk where I’m just building GSIs are around 40 degrees. In normal room 28 and outside 34 degrees. Welcome summer :))
2 Likes
So this tool is not really about decrypting anything right ?
You basically flash that to disable force encryption, wiping everything in the process, thus allowing full TWRP features to work.
Assuming the said zip works
I remember back in the days - I’m talking Samsung Galaxy S2/3 days - it was common to disable forced encryption as it would notably speed up the device. I’m not sure what would be the point of disabling encryption nowadays (well except when you need to use a TWRP that cannot decrypt your device ofc )
1 Like
yes, format data, reboot to twrp, flash right version of dfe.zip, reboot and be happy :))
2 Likes
So if I understand well, this process will wipe all data and disable encryption, then you’ll be able to fresh install StockOS/CustomOS on it without encryption, thus being able of doing TWRP backups??