You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many users, generally users with little knowledge and no experience, asked me which correct files should be placed in the device
tree1 for Custom Recovery to generally work.
But of course most of these users want to know the files that control the encryption, that is, they want to know the correct files so that the encryption/decryption can work.
In this sense, as there is not much information about this on the internet, I decided to put some words and some experience that I have had over a few years with Mediatek devices.
Although most of the information has programming, even though I am an Engineer and Teacher, I always wanted the language to understand to be as simple and easy as possible. Even so, you really need to understand some parts of Linux, Android and programming code. Don't read all of this without prior knowledge2 of the subject.
The idea about this Info Guide
This "guide" interacts/complements with some important information from other guides:
There is no Android version limit to start follow this guide. Understanding how you will have files from Android 4.4 to Android 13 (new information on how to decrypt userdata must be understood and make correct changes depending on each encryption mode), is something individual and each user must know which tool/software to use.
Device Tree using a Minimal Manifest repository is an informative data structure used to describe the hardware parts of the devices in a platform-independent manner. It provides a way to describe hardware info and or firmware version (if want) of the device without the need for board-specific source code. The objective is compile a Custom Recovery with special options like backup, instalation and modify files. ↩
Many times in the past I have encountered people who are truly knowledgeable in creating Custom Recovery. But most of them kept the information to themselves. I cannot judge such a choice. It's quite possible that I didn't intend to save my knowledge until I became a worthless carcass, but I also didn't pass on all the knowledge I have when I helped some people. Well, learn that I don't have ALL the knowledge about Custom Recovery and I'm not going to write everything I know either. Most of what you learn from this is definitely reading and doing, making mistakes and learning to correct until you find the perfect skill for you. ↩
Depending on what you know and what you want, tools/software and knowledge are important. Knowing whether the files are in the EROFS, sparse or ext4 extension is relatively easy. So understand that the tool must have the ability to work with the file extensions you will need.
1.1.1 Firmware img files
There are many tools/software in different ways for Linux, Win8.1~11 and even for Android (need ROOT).
The particularity at this point is not to highlight how these tools/software are used. But you can have a direction for them:
These tools are for unpacking files like super.img and/or vendor_dlkm.img. Some can unpack files like recovery.img, boot.img and vendor_boot.img.
1.1.2 Recovery ramdisk img files
To unpack files like recovery.img, boot.img and vendor_boot.img in particular and save time to have files and information, we can use the most updated tool that exists for WinNN and Linux. Generally the tools/software highlighted above also use the same tool/software as this one: AIK Linux -- AIK WinNN -- AIK-mobile
1.1.3 Editing text files
There are many of them. But I can point out some that do something better and really highlight usability.
WinNN
To edit text files like *.rc, *.prop, *.default, *.fstab, fstab.* and other files that have no extension but can be opened through the text editor, you can use the tool /software Notepad++.
To compare text files, you can use the tool /software Beyond Compare.
Tip
Depending on what you want to use, these tools/software can start on Linux with Wine.
Linux
To edit text files like *.rc, *.prop, *.default, *.fstab, fstab.* and other files that have no extension but can be opened through the text editor, you can use the tool /software Vi/Vim or kate.
To compare text files, you can use the tool /software Meld or Diffchecker.
Tip
Depending on what you want to use, these tools/software can start in the WinNN too.
Note
These are just as references. Use the tool/software that you know is best and works.
1.2 Unpacking img files
We start by understanding that you already know how to unpack the img files from the device's firmware.
So you must have enough space and time to wait for the process. In this sense, you will have the files as a basis for this piece of information: Android - Some information about firmware files
The main files to unpack are:
super.img 🔛 this generates the system.img files; vendor.img; product.img which must be unpacked as well,
Depending on the OEM, some extra files may be contained in super.img as partitions of system_ext.img; my_preload.img; mi_ext.img; among other img files;
recovery.img or boot.img or vendor_boot.img 🔛 thi's a base the files for recovery_ramdisk;
vendor_dlkm.img 🔛 starting from A13+, here we have *.ko files which are the hardware driver modules.
1.3 Which img file is best to start with?
By objective and experience, the best file will be the one with the ramdisk part. Therefore, depending on the kernel version, the recovery ramdisk may be inside the recovery.img or boot.img or vendor_boot.img file.
For Android with kernel version 4.nn and earlier, you must use recovery.img and boot.img files as recovery ramdisk. This also depends on the Android version and to know what to use, just look at the firmware files which img file exists in it.
For Android with kernel version 5.nn and later, you must use the vendor_boot.img file as recovery ramdisk.
2. The recovery ramdisk
We start with the recovery.img or boot.img or vendor_boot.img files to understand the information that is written in **.so files and text files.
2.1 Parts of recovery ramdisk
When you unpack the img file, there are generally two parts/folders:
Split or files_info => Structure and informations by kernel files;
Click to open
Ramdisk or cpio => Folder structure and informations with very different files;
Click to open
2.2 What informations does Device Tree need?
I highlighted in the image above some information that will be necessary to place in the Device Tree.
Then consider the Split or files_info information for the Device Tree 1️⃣BoardConfig.mk; 2️⃣device.mk
2.2.1 Split or files_info
Click to open
You can have this information on the unpacking screen or just click on each file to open and see the information given.
For better visualization and understanding:
Supplied image: recovery-MT6761.img
It is important to understand and know the correct recovery ramdisk partition. This gives us information about what exists in a given img file with its structure and files. Furthermore, install the Custom recovery img file on the correct partition. Understand that I already wrote about this and there are three partitions where the recovery ramdisk part can remain.
1️⃣
Click to open
Information
Value
BoardConfig.mk
BOARD_KERNEL_CMDLINE
bootopt=64S3,32N2,64N2 buildvariant=user
BOARD_KERNEL_CMDLINE :=
BOARD_KERNEL_BASE
0x40078000
BOARD_KERNEL_BASE :=
BOARD_NAME
BOARD_KERNEL_NAME :=
BOARD_PAGE_SIZE
2048
BOARD_KERNEL_PAGESIZE :=
BOARD_HASH_TYPE
sha1
BOARD_HASH_TYPE :=
BOARD_KERNEL_OFFSET
0x00008000
BOARD_KERNEL_OFFSET :=
BOARD_RAMDISK_OFFSET
0x11a88000
BOARD_RAMDISK_OFFSET :=
BOARD_SECOND_OFFSET
0xbff88000
BOARD_KERNEL_SECOND_OFFSET :=
BOARD_TAGS_OFFSET
0x07808000
BOARD_KERNEL_TAGS_OFFSET :=
BOARD_OS_VERSION
11.0.0
PLATFORM_VERSION :=
BOARD_OS_PATCH_LEVEL
2022-02
PLATFORM_SECURITY_PATCH :=
BOARD_HEADER_VERSION
2
BOARD_BOOT_HEADER_VERSION :=
BOARD_RECOVERY_DTBO_SIZE
35345
BOARD_DTBOIMG_PARTITION_SIZE :=
BOARD_RECOVERY_DTBO_OFFSET
19097600
BOARD_HEADER_SIZE
1660
BOARD_DTB_SIZE
102314
BOARD_DTB_SIZE :=
BOARD_DTB_OFFSET
0x07808000
BOARD_DTB_OFFSET :=
In summary, the information will look like this in BoardConfig.mk
Each part of BOARD_KERNEL_* needs BOARD_MKBOOTIMG_ARGS for the source code to create a file with the size value property defined.
For 32-bits devices the BOARD_KERNEL_CMDLINE has bootopt=64S3,32S1,32S1.
Some information may be empty like BOARD_NAME. It usually appears on devices from the following brands: Realme; Infinix; Tecno; Cubot; Sansumg.
Other information such as BOARD_RECOVERY_DTBO_OFFSET; BOARD_RECOVERY_DTBO_SIZE is not priority/necessary.
Only include information that is relevant and can be considered absolutely safe/correct. Therefore, do not take risks due to excessive doubts. This may cause errors in compiling the Custom Recovery img file.
Tip
If your device tree need BOARD_NAME so you need BOARD_MKBOOTIMG_ARGS += --board $(BOARD_NAME)
Before approaching the following continuation, it is important to highlight that some basic knowledge is necessary.
Understanding that we must know what the device has in terms of hardware and software information will be important to avoid having doubts or confusing information.
In this context, follow this step to obtain all possible information: II. Get some informations from device using adb-fastboot platform-tool
As the main approach is for Mediatek devices, even these have some different peculiarities. Some information should initially be understood as:
Platform
Display
Memory
Chipset
Resolution
Internal
CPU
Type
GPU
Camera cutout
Type
In this matter, many Mediatek chipsets exist and are also built with 32bits or 64bits; with Quadcore or Octacore and finally the Kernel Version and the Android OS Version.
Some Mediatek chipsets/Processor Name to know: Model number - PLATFORM - Chipsets MediaTek
As there are three types of partitions that can contain the recovery ramdisk - recovery.img or boot.img or vendor_boot.img file - there are also particularities when entering configuration information about these partitions. This part must be understood so that we do not include extra and wrong information.
Partition
dependency
kernel
dtb
dtbo
recovery
boot.img
yes
yes
yes
boot
first_stage_ramdisk folder
yes
yes
no
vendor_boot
first_stage_ramdisk folder
no
yes
no
How do we know if such files are on the partition?
See the unpacked parts of Split or files_info.
Caution
As a general rule, I will just interact between some basic settings and flags, indicating which file the information should come from. So keep in mind that Device Tree files only serve as a way of learning where information is and where to put it. The Device Tree files below are not intended to serve as an example or copy for a given Chipset. There are many repositories on github that may be good for your device/Chipset and therefore you can use them.
2.2.2 Ramdisk or cpio
Click to open
I highlighted in the image above some information that will be necessary to place in the Device Tree.
Then consider the Recovery Ramdisk information for the Device Tree 1️⃣BoardConfig.mk; 2️⃣device.mk; 3️⃣twrp_devicename.mk; 4️⃣Android.mk; 5️⃣AndroidProducts.mk
The important information and files from the Stock img file will be in ramdisk\ prop.default & init.recovery.mtNNNN.rc; ramdisk\first_stage_ramdisk\fstab.mtNNNN & fstab.emmc ; ramdisk\lib\modules/*.ko; ramdisk\system\bin\mtk_plpath_utils; ramdisk\system\lib64\hw\android.hardware.boot@'N.n-impl-N.n-mtkimpl.so and ramdisk\system\etc\recovery.fstab
Warning
Settings are understood as information given from Android source code and flags coming from the TWRP source code that are highlighted with TW_ and that can help with Custom Recovery processes and features.
There are many settings and flags that depend on what the device can have. You can read more in the InfoGuide understand about some flags - setup & configurations. You can compare TW_ flags for each Custom Recovery version if you want need know more so look TWRP-10; TWRP-11; TWRP-12.1.
Be careful when using any flag from a certain TWRP version to another TWRP version. As well as the Android version Variable /Settings for another Android version from the AOSP base. Each version of TWRP may have new flags introduced and may also have Deprecated flags.
Therefore, the approach below only serves as an information base for a given device, but obviously it can have many characteristics that are the same or different from other devices.
Architecture 🔀 But for the sake of knowledge, just understand that there are devices with 32-bits (arm) and 64-bits (arm64).
TARGET_ARCH ➡️ Comes from prop.default file by any ro.bionic.arch= or/and ro.bionic.2nd_arch= line.
TARGET_ARCH_VARIANT ➡️ The Variant comes from the Architecture and depends on each device. Usually armv8-a or armv8-2a for 64-bits devices & armeabi-v7a for 32-bits devices. More details, check the links I left above.
TARGET_CPU_ABI ➡️ Comes from prop.default file by any ro.product.cpu.abi= or/and ro.product.cpu.abilist64= or/and ro.product.cpu.abilist= or/and ro.product.cpu.abilist32= line.
TARGET_CPU_ABI2 ➡️ Usually with nothing.
Target information variables 🔀 This will indicate which processor will be in the device with generic efficiency. The CPU will determine this part.
TARGET_CPU_VARIANT ➡️ Comes from prop.default file by any ro.bionic.cpu_variant= or/and ro.bionic.2nd_cpu_variant= or/and dalvik.vm.isa.arm64.variant= or/and ro.bionic.2nd_arch= or/and dalvik.vm.isa.arm.variant= line.
TARGET_BOOTLOADER_BOARD_NAME ➡️ Comes from prop.default file by any ro.product.board=.
TARGET_NO_BOOTLOADER ➡️ true means that we're not building the bootloader...
TARGET_USES_UEFI ➡️ If it's set to "true" or any non-empty value, it means that the target platform supports UEFI and the software should be designed and built with UEFI support. If it is set to "false" or an empty value, it means that the target platform does not use UEFI and the software can be built without UEFI support. You can find out if this exists if you get information with logcat, getprop, dmesg on the device. If in doubt, delete TARGET_USES_UEFI of this part.
The information in this part comes from Split or files_info.
BOARD_HAS_LARGE_FILESYSTEM ➡️ Use this flag if the board has a partition larger than 2GB.
BOARD_BOOTIMAGE_PARTITION_SIZE ➡️ The real size of boot.img file. You can put Hexadecimal or Decimal value.
BOARD_RECOVERYIMAGE_PARTITION_SIZE ➡️ The real size of recovery.img file. You can put Hexadecimal or Decimal value.
*** See the figure below [fastboot getvar all example] which allows you to have the correct sizes.
BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE & BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE & BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE & BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE ➡️ Comes from stock /ramdisk/system/etc/recovery.fstab file by fstype.
Click to open recovery.fstab example
BOARD_CACHEIMAGE_PARTITION_SIZE & BOARD_SYSTEMIMAGE_PARTITION_SIZE & BOARD_USERDATAIMAGE_PARTITION_SIZE & BOARD_VENDORIMAGE_PARTITION_SIZE ➡️ Comes from fastboot and fastbootd comand with fastboot getvar all.
BOARD_SUPER_PARTITION_SIZE ➡️ Comes from fastboot and fastbootd comand with fastboot getvar all.
Click to open `fastboot getvar all` example
In general, it is not necessary to write the size values for the System; Product; Vendor; Userdata; System_Ext; others; partitions because the code-tools of Custom Recovery find this part. So this becomes optional.
Use any online site that converts Hexadecimal to Decimal if you want to use Bytes.
Example: `boot:0x2000000` has 0x2000000 Hexadecimal and converted to Decimal has 33554432.
BOARD_KERNEL_IMAGE_NAME ➡️ This is name of kernel to source code put in the correct path. You can use zImage or Image.gz for 32-bits devices. If you have doubts so put kernel.
In some case the kernel and dtb is unique one file. So for that you can read the part of prebuilt. Therefore when you use that so the TARGET_PREBUILT_KERNEL have name and Image.gz-dtb file.
TARGET_PREBUILT_KERNEL ➡️ The source code include the kernel file within \Split folder of recovery_ramdisk.
TARGET_PREBUILT_DTB ➡️ The source code include the dtb file within \Split folder of recovery_ramdisk.
In some case the dtb file is unpacked detailed - you can read the part of prebuilt - In addition, - and that need a special folder/directory BOARD_PREBUILT_DTBIMAGE_DIR := prebuilt/dtb/mt6xxx.dtb and the file will be build and copied by the source code to the correct path. Therefore when you use that so not write the BOARD_INCLUDE_DTB_IN_BOOTIMG variable.
BOARD_PREBUILT_DTBOIMAGE ➡️ The source code include the dtbo file within \Split folder of recovery_ramdisk.
In case the dt file is unpacked - you can read the part of prebuilt - In addition, - and that need a special folder/directory BOARD_PREBUILT_DTBIMAGE_DIR := prebuilt/dtb/mt6xxx.dtb and the file will be build and copied by the source code to the correct path. Therefore when you use that so not write the BOARD_INCLUDE_DTB_IN_BOOTIMG variable.
BOARD_INCLUDE_DTB_IN_BOOTIMG ➡️ This allows for the inclusion of Device Tree Blob (DTB) files during the build process in the bootimage or recoveryimage or vendorbootimage.
BOARD_INCLUDE_RECOVERY_DTBO ➡️ This allows for the inclusion of Device Tree Blob Overlay (DTBO) files during the build process in the recoveryimage.
BOARD_FLASH_BLOCK_SIZE ➡️ Typically refers to the size of the flash memory block on the development board. The value of this variable depend of BOARD_KERNEL_PAGESIZE value and if the device have 32-bits or 64-bits.
TARGET_KERNEL_ARCH & TARGET_KERNEL_HEADER_ARCH ➡️ Specific part of # Architecture similar to TARGET_ARCH. It determines the system-specific features, instructions and optimizations.
# Workaround for error copying vendor files to recovery ramdiskTARGET_COPY_OUT_VENDOR :=vendor
This will create a folder for certain required partition. But to avoid errors, it is necessary to have this partition specified in File systems and partitions part.
Example:
# File systems and partitionsBOARD_SYSTEM_EXTIMAGE_FILE_SYSTEM_TYPE :=ext4# Workaround for error copying vendor files to recovery ramdiskTARGET_COPY_OUT_SYSTEM_EXT :=system_ext
TARGET_USERIMAGES_USE_EXT4 ➡️ This configuration setting specifies the system for managger userimages partition should formatted and build using the EXT4 fstype.
TARGET_USERIMAGES_USE_F2FS ➡️ This configuration setting specifies the system for managger userimages partition should formatted and build using the F2FS fstype.
# System as rootBOARD_BUILD_SYSTEM_ROOT_IMAGE :=falseBOARD_SUPPRESS_SECURE_ERASE :=true
BOARD_BUILD_SYSTEM_ROOT_IMAGE ➡️ For the A10+ the AOSP source code limited the use of SAR (System As ROOT = /system_root/system/). The Custom Recovery mount the system image as /. Therefore it must be set to false.
BOARD_SUPPRESS_SECURE_ERASE ➡️ Secure erase is a security feature that permanently deletes all data from a device to prevent unauthorized access or data recovery..
The most important thing in this part is to know the value of BOARD_KERNEL_PAGESIZE. If you are unsure if you want to use this or how to use this, then you can copy from any device tree that have img file compiled successfully.
PLATFORM_SECURITY_PATCH ➡️ Comes from prop.default file by ro.build.version.security_patch= line.
VENDOR_SECURITY_PATCH ➡️ Comes from prop.default file by ro.vendor.build.security_patch= line.
Resuming, with a future date means there are no problems with Rollback. But on some devices, depending on the encryption setting, the VENDOR_SECURITY_PATCH variable must have the same date.
BOOT_SECURITY_PATCH ➡️ Comes from BOARD_OS_PATCH_LEVEL of Split or files_info file line.
PLATFORM_VERSION ➡️ Comes from prop.default file by ro.build.version.release= line.
PLATFORM_VERSION_LAST_STABLE ➡️ Maybe comes from prop.default file by ro.build.version.release_or_codename= line.
If there is a line with the word stable or last, great. But usually there isn't. On newer devices with kernel version 5.xx usually with Android 12, the system version is updated and its differ, written as Android 13. Then you must confirm ro.build.version.release_or_codename= in the build.prop file of system.img file.
If you are unsure if you want to use this or how to use this, then you can copy from any device tree that have img file compiled successfully.
BOARD_USES_METADATA_PARTITION ➡️ Comes from /ramdisk/system/etc/recovery.fstab stock recovery_ramdisk file by mountpoint. You must look if a \metadata partition exists.
BOARD_ROOT_EXTRA_FOLDERS ➡️ This variable is used to create folders within of \ramdisk\ when compiling the Custom recovery with cases where there are no files inside them. With device tree in the device_brand_devicename/recovery/root/, the source code cannot create folders if not have files inside them.
You can write more folders if need. Example: BOARD_ROOT_EXTRA_FOLDERS += metadata transf
Just pay attention to what the variable or flag is for. For encryption and decryption files and processes, there is another document for us to understand about how it works.
TW_INCLUDE_CRYPTO ➡️ It will enable encryption and decryption related processes and files.
If you not know about that so change trueto false.
TW_INCLUDE_CRYPTO_FBE ➡️ It will enable encryption and decryption related processes and files for FBE option.
Resuming, the source code will compile and copy the files into the Custom Recovery \ramdisk\system\bin and \ramdisk\system\lib_lib64 folders.
TW_INCLUDE_FBE_METADATA_DECRYPT ➡️ It will enable encryption and decryption related processes and files if Metadata has encryption mode.
TW_USE_FSCRYPT_POLICY ➡️ This will be different for devices coming with version 1 (v1) or version 2 (v2) options related to encryption and decryption. The source code will compile files and include information relating to each version. We usually know about this by looking at the \data partition in the /ramdisk/system/etc/recovery.fstab stock recovery_ramdisk file by flags. Note that only version 2 will be written v2 and therefore if this is not available, the option is version 1.
Click to open recovery.fstab example
TW_PREPARE_DATA_MEDIA_EARLY ➡️ Maybe this variable should relink /data/media/0 to /data. Solve specific decryption problems on some devices.
TARGET_RECOVERY_DEVICE_MODULES & TW_RECOVERY_ADDITIONAL_RELINK_LIBRARY_FILES ➡️ This variable tells you to compile a specific or necessary file that the Custom Recovery source code does not create. For convenience, a few years ago, the code was not yet updated and so the device tree needed extra files for the encryption/decryption process. This variable is not just for encryption/decryption and therefore you can "call" any file for compilation as long as it is in the Android source code and its specific version according to the Custom Recovery repository (minimal manifest).
TARGET_RECOVERY_DEVICE_MODULES & TW_RECOVERY_ADDITIONAL_RELINK_LIBRARY_FILES ➡️ This variable tells you to compile a specific or necessary file that the Custom Recovery source code does not create. The ashmemd module files are required to start fastbootd when the device has the recovery.img partition active and starting with Android 10+.
Ashmemd is a tool in Android that manages shared memory between processes. It stands for "Anonymous Shared Memory Device". It allows processes to allocate and share memory without the need for file-backed memory mappings. This can be useful for inter-process communication and sharing data efficiently between processes.
TARGET_RECOVERY_PIXEL_FORMAT ➡️ This variable depends on how your device was configured to show certain colors in the screen. So there are some options like: RGB_565; RGB_888;RGBA_8888; RGBX_8888; BGRA_8888; BGRX_8888; ABGR_8888; RGBA_5551; RGBA_4444.
TARGET_RECOVERY_FSTAB ➡️ This variable is used to indicate the folder that the recovery.fstab file is in and is necessary when Custom Recovery starts, so it must mount main partitions. You can leave the recovery.fstab file anywhere, as long as you write the local in the variable. Even so, it will be automatically copied to the \recovery_ramdisk\system\etc folder in compiled Custom Recovery file.
BOARD_HAS_NO_SELECT_BUTTON ➡️ In short, most Custom Recoveries do not use physical buttons to select and confirm options on their interface. Even if your device has the three lower buttons, they will only serve the same Custom Recovery option (if any) such as Back, Menu and Show Processin the Screen.
I only know of some like the current LOS Recovery and other old ones like CWM, Carliv, Philz and Dingdoing that need to use buttons like Power, Vol - and Vol + for certain actions.
RECOVERY_SDCARD_ON_DATA ➡️ This enables proper handling of /data/media on devices that have this folder for storage.
TARGET_SYSTEM_PROP ➡️ This variable is used to copy property lines coming from the system.img\build.prop part that are relevant for certain functions to work. With the device tree in device_brand_devicename/system.prop, the text inside the system.prop file will be copied in the Custom Recovery compiled file to the folder with the \recovery_ramdisk\prop.default file.
TARGET_VENDOR_PROP ➡️ This variable is used to copy property lines coming from the vendor.img\build.prop part that are relevant for certain functions to work. With the device tree in device_brand_devicename/vendor.prop, the text inside the vendor.prop file will be copied in the Custom Recovery compiled file to the folder with the \recovery_ramdisk\prop.default file.
TARGET_RECOVERY_INITRC ➡️ Use a custom init.rc file in the Custom Recovery to start necessary and/or special services and processes.
The init.recovery.{hardware}.rc file can also be seen as init.recovery.{platform}.rc and will serve to indicate the file paths, as well as to start the encryption/decryption mode process.
This part will define some hardware parts related to the screen configuration that your device has so that Custom Recovery informs and displays the information correctly. This can be used to set a nicer graphics mode and or fix presentation issues.
TW_BRIGHTNESS_PATH ➡️ Comes from /sys/class/leds/* for brightness works correctlly in the screen.
TARGET_RECOVERY_LCD_BACKLIGHT_PATH ➡️ Comes from /sys/class/leds/* for LCD works correctlly in the screen.
TW_CUSTOM_CPU_TEMP_PATH ➡️ Comes from /sys/devices/virtual/thermal* for show the CPU Temperature (thermal) ºC info in the screen.
TW_SCREEN_BLANK_ON_BOOT ➡️ It will jolt the screen/touch driver. If on the default settings the screen will only kick in to action/start AFTER it has gone to sleep once and has been woken up again with a key press, this will be needed to set to true. There is still a screen touch issue if this option is set to true.
On some legacy devices, the Custom Recovery will not boot without this flag.
TW_INPUT_BLACKLIST ➡️ It is used to indicate that a particular function is prohibited from access or use something because interfere with other anything. That allows users to blacklist certain input values or characters. When this setting is enabled, reject any input that contains blacklisted values or characters, preventing them from being processed further.
TW_MAX_BRIGHTNESS ➡️ Used to set the maximum brightness level to be displayed in the screen.
TW_DEFAULT_BRIGHTNESS ➡️ Sets the default brightness level to be used when Custom Recovery starts.
If you don't know the correct path, then remove any variables so there are no errors. In this sense, the Custom Recovery code itself tries to find the correct path directly on the device. There are some flags written with _CUSTOM_ and this serves to quickly indicate a path where the Custom Recovery code was unable to obtain information. Therefore, defining it exclusively serves to confirm the correct path. Some informations about \sys.
There are flags (TW_NO_*) that disable the source code from finding some functions. Example: TW_NO_BATT_PERCENT := true Disables the display of the battery percentage for devices that don't support it properly.
Use the adb tool for have informations from your device. Use this command: adb shell su -c "ls -R" > info.txt if you want. But look for have root priviledges or Root acess whit any apk process.
This part will define how the upper part (Battery Level, Clockstamp and CPU:Temperature °C) with information will be shown, and can be customized due to user choice or particularities, such as the location (POSition) of the camera cutout.
TW_STATUS_ICONS_ALIGN ➡️ Option to align information, therefore how it will be displayed on the screen.
TW_CUSTOM_CPU_POS ➡️ Option to align CPU:Temperature °C information according to the location value on the screen.
TW_CUSTOM_CLOCK_POS ➡️ Option to align Clockstamp information according to the location value on the screen.
TW_CUSTOM_BATTERY_POS ➡️ Option to align Battery Level % information according to the location value on the screen.
Click to open - Some Examples
Has other flags. This is optional and depends on each case. Maybe it's deprecated?!
TW_USE_MODEL_HARDWARE_ID_FOR_DEVICE_ID ➡️ On some devices, the TWRP backup folder name will show 0000000000 because the CPU information has no serial number or 123456789ABCDEF if lost/erased. Using this flag it will use ro.product.model as the TWRP backup folder name.
TW_USE_TOOLBOX ➡️ Choose to compile and use ToyBox instead of Busybox.
TW_EXTRA_LANGUAGES ➡️ Add translated files for languages generally from the Asian region {Japanese, Chinese (Simplified), Chinese (Traditional) and Sinhala (Sri Lanka)}.
TW_DEFAULT_LANGUAGE ➡️ Sets the language when Custom Recovery starts on the device.
TW_EXCLUDE_DEFAULT_USB_INIT ➡️ Choose it not include the default init.recovery.usb.rc file (from source code), so need must provide your own (from device tree) or use the required definitions within the init.recovery.{hardware}.rc file.
TW_INCLUDE_NTFS_3G ➡️ It's include a NTFS driver file in the Custom Recovery. NTFS-3G allows for read and write access to NTFS partitions, commonly used by Windows OS.
TARGET_USES_MKE2FS ➡️ It will compile the files needed to use the "mke2fs" command to create an ext2, ext3 or ext4 filesystem.
TARGET_DISABLE_TRIPLE_BUFFERING ➡️ Set true to disable and false to not disable. Triple buffering is a technique used in computer graphics to reduce screen tearing and improve overall performance by using three buffers instead of two.
TW_NO_USB_STORAGE ➡️ Removes the USB storage button on devices that don't support USB storage.
TW_INTERNAL_STORAGE_PATH & TW_INTERNAL_STORAGE_MOUNT_POINT & TW_EXTERNAL_STORAGE_PATH & TW_EXTERNAL_STORAGE_MOUNT_POINT ➡️ Specify the dual storage partition (internal and external) for devices that have it. The mount point must match something in the files \ramdisk\system\etc\recovery.fstab or \device_brand_devicename\recovery\root\system\etc\twrp.fstab_flag or any correct storage mount point information.
TW_HAS_MTP ➡️ Indicates that Custom Recovery will support Media Transfer Protocol (MTP) for transferring files between the device and a computer. Make sure the device offers MTP. Check the stock init.{hardware}.usb file.
TARGET_USE_CUSTOM_LUN_FILE_PATH ➡️ Specify a custom path to the lun file on device that directing to internal storage.
TWRP_INCLUDE_LOGCAT ➡️ The source code of Custom Recovery include logcat output. It's useful for debugging and troubleshooting issues in the recovery image. This allows developers to access the logcat logs from within Custom Recovery, providing additional information about device system events, errors, and crashes.
Including logcat output in the recovery image can make the image larger, so it is recommended to only enable this option for debugging purposes and disable it for release builds.
TARGET_USES_LOGD ➡️ Uses the logd log buffer for logging messages which can be accessed using the "logcat" command.
Any TW_EXCLUDE_* flag ➡️ It serves to avoid adding certain functions and thus the processes & files resulting from them. Remove/Exclude anything no need and or to have minimal img file size.
TW_DEFAULT_DEVICE_NAME ➡️ Represents the default name assigned to a device when it is built with TWRP source code. The value of this variable is typically set to the device code name or model name or custom name to provide an identifiable name for the recovery image.
TW_DEVICE_VERSION ➡️ Used to show the author/developer name or custom name value for a specific device version, or to specify compatibility requirements for a specific firmware version. The value will localized below the Custom Recovery name in the main page's action bar and also on the splashscreen below of Custom Recovery version.
Click to open the Example
For some custom recoveries, this flag does not work because it depends of maintainer's choice on the Custom Recovery source code. Other cases depend on the custom theme used and the value cannot be shown.
1️⃣ BoardConfig.mk for Recovery_ramdisk in the boot.img
This is a separate part for a special reason and will not be the only one.
In the firmware file, the recovery.img file does not exist, just look for the boot.img file. So Recovery_ramdisk is inside boot.img file and the filesystem mountpoint certainly does not contain the \recovery1 partition. So the Split or files_info part will not have the dtbo2 file.
androidboot.force_normal_boot=1 ➡️ Added for Android 10+ Boot Reason or System-as-root changes.
Resuming, when you choose Reboot to System option, then bootloader can skip recovery and boot normal Android.
BOARD_BOOT_HEADER_VERSION ➡️ Note that it is with version 2. I am repeating it just to make it clear that there is no version 1 currently for recovery_ramdisk for the boot.img file.
Note that there is no reference to RECOVERY related to the partition and its size. Understand that's the part that will tell the Custom Recovery source code about the location of the recovery_ramdisk. Therefore, use the previous settings and flags, but without RECOVERY to uses to build the recovery.img file.
BOARD_USES_RECOVERY_AS_BOOT ➡️ This variable indicates whether the device uses the recovery_ramdisk part in the boot image.
Setup instructions differ between devices launching with Android 12 or 13 and legacy devices.
Not use BOARD_RECOVERYIMAGE_PARTITION_SIZE variable!
TARGET_NO_RECOVERY ➡️ No build the recovery.img file. Strongly recommended for A/B target devices.
TW_HAS_NO_RECOVERY_PARTITION ➡️ To avoid the error about /boot partition not found. Required on devices without /recovery partition.
BOOT/RAMDISK also exists and contains the first stage ramdisk if not using BOARD_BUILD_SYSTEM_ROOT_IMAGE.
# Tools - magiskbootTW_INCLUDE_REPACKTOOLS :=true
TW_INCLUDE_REPACKTOOLS ➡️ Compiles and creates the magiskboot file so that Custom Recovery has the Install Recovery Ramdisk option in the Advanced tab to install recovery.lz4.cpio on the recovery ramdisk part in the boot_$slot partition.
Click to open the Example
1️⃣ BoardConfig.mk for Recovery_ramdisk in the vendor_boot.img
This is a separate part for a special reason and will not be the only one.
In the firmware file, the recovery.img file does not exist. But like every Android, the boot.img file will be on it. The big difference is that if you find the vendor_boot.img file in the firmware file, then you have the Recovery_ramdisk in the \vendor_boot partition. The filesystem mount point certainly does not contain the \recovery partition. Therefore, the Split or files_info part will not have the kernel3 files and also the dtbo.
Click to open
# ArchitectureTARGET_2ND_ARCH_VARIANT :=armv8-2a
TARGET_2ND_ARCH_VARIANT ➡️ It's implemented just the ARMv8 ABI saying update Architecture CPU.
TARGET_NO_KERNEL ➡️ This variable indicates if the build uses a prebuilt boot image. Setting true indicates that the kernel file is not needed.
BOARD_VENDOR_CMDLINE ➡️ Just a name change for correct partition identification.
BOARD_PAGE_SIZE ➡️ Change made for devices that have [only 64-bits] according to the new flash memory block.
BOARD_BOOT_HEADER_VERSION ➡️ Updated header for vendor_boot, perhaps related to kernel 5.1.xxx
BOARD_HEADER_SIZE ➡️ It comes from the unpacked img file information.
BOARD_FLASH_BLOCK_SIZE ➡️ According the part II of III table.
TARGET_PREBUILT_DTB ➡️ According the part II of III in the # Kernel setting because the vendor_boot partition contains only dtb file.
BOARD_DTB_SIZE & BOARD_DTB_OFFSET ➡️ It comes from the unpacked img file information.
BOARD_KERNEL_SEPARATED_DTBO ➡️ You can see in the firmware file the dtbo.img file. In the unpacked vendor_boot.img you can see only the dtb file. So need inform the source code to not compile dtbo file.
BOARD_RAMDISK_USE_LZ4 ➡️ Better compression of the img file where the kernel has this capability.
BOARD_MKBOOTIMG_ARGS ➡️ Each part of BOARD_* needs BOARD_MKBOOTIMG_ARGS for the source code to create a file with the size value property defined.
BOARD_AVB_RECOVERY_ALGORITHM & BOARD_AVB_RECOVERY_KEY_PATH ➡️ According to the BOARD_PAGE_SIZE value and the reference of AVB source code configuration.
# File systems and partitionsBOARD_VENDOR_BOOTIMAGE_PARTITION_SIZE :=67108864# Build a separate vendor_dlkm partitionBOARD_USES_VENDOR_DLKMIMAGE :=trueBOARD_VENDOR_DLKMIMAGE_FILE_SYSTEM_TYPE :=ext4TARGET_COPY_OUT_VENDOR_DLKM :=vendor_dlkm# Build a separate odm_dlkm partitionBOARD_USES_ODM_DLKMIMAGE :=trueBOARD_ODM_DLKMIMAGE_FILE_SYSTEM_TYPE :=ext4TARGET_COPY_OUT_ODM_DLKM :=odm_dlkm
BOARD_VENDOR_BOOTIMAGE_PARTITION_SIZE ➡️ The real size of vendor_boot.img file. You can put Hexadecimal or Decimal value.
TARGET_COPY_OUT_VENDOR_DLKM & TARGET_COPY_OUT_ODM_DLKM ➡️ For copying partition files to recovery ramdisk of Custom Recovery. Same process of TARGET_COPY_OUT_VENDOR in the part II of III.
Pay attention here to the fstype (ext4 or erofs) of the system, system_ext, product, vendor, vendor_dlkm, odm_dlkm partitions. Same as fstype of userdata partition (ext4 or f2fs).
Example: BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := erofs and BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE := f2fs
Note that there is no reference to RECOVERY related to the partition and its size. Understand that's the part that will tell the Custom Recovery source code about the location of the recovery_ramdisk. Therefore, use the previous settings and flags, but without the BOARD_USES_RECOVERY_AS_BOOT variable as it is not necessary to compile the boot.img file.
TW_CUSTOM_CPU_TEMP_PATH ➡️ You should be careful with this, as the Custom Recovery source code was recently updated to automatically search for the path. So you can remove or just put # in front of the path to know that it depends on the addressing, as the thermal_zoneNN (NN is a number) folder is managed on the device.
TW_LOAD_VENDOR_MODULES ➡️ The Android source code already has others variables so that it can compile module *.ko files inside boot.img, recovery.img, vendor.img, vendor_boot.img and or vendor_dlkm.img. But we have the module files located in \vendor_boot\lib\modules` and so the TW_ flag only directs the path to use one or more module files. It appears that the Custom Recovery source code has some attempt to target this automatically, since we all know the location. In this sense, for Android 12+, the modules *.ko files are located inside the vendor_dlkm.img file.
TW_SUPPORT_INPUT_AIDL_HAPTICS ➡️ Set true to enable makefile building for certain hardware.
TW_SUPPORT_INPUT_AIDL_HAPTICS_FQNAME ➡️ Enter the correct path for a given hardware and this will compile the necessary files. In that's case, files for haptics vibrators.
Depending of hardware type the option can have support in AIDL (hal format=" aidl ") mode or support in HIDL mode (hal format="hidl").
Example: TW_SUPPORT_INPUT_1_2_HAPTICS := true
Perhaps Custom Recovery's source code may have updated to find automatically the vibration support. But I haven't really confirmed that. Anyway, personally I don't see this part as a priority and if there is no solution there is the TW_NO_HAPTICS := true flag to disable the vibration.
Footnotes
Generally the \cache partition is inserted in the mountpoint filesystem in many cases related to the recovery.img file. But it's just a partition like any other and there are no dependencies. It can be relinked with other names like *\by-name\rescue. ↩
But there are some special cases that depend on the kernel version with parts of a legacy device. It is something that depends on the choice of the company that builds the partition structure - mount point and in this case Custom Recovery will only work if you insert the dtbo.img file that is in the firmware file. ↩
For ramdisk recovery with recovery.img file, it is generally not necessary to have device.mk file. But for convenience and custom with the new way of having the device tree, we just reference something simple.
Click to open
LOCAL_PATH :=device/fplus/H166
LOCAL_PATH ➡️ This variable indicates the location of the source files in the development tree. Here, the macro function my-dir, provided by the build system, returns the path of the current directory (the directory containing the Android.mk file itself). Note that it is the same path as DEVICE_PATH.
PRODUCT_TARGET_VNDK_VERSION ➡️ The VNDK requires several changes to a codebase to separate concerns between vendor and system. The binaries files in each partition must be able to work with each other.
PRODUCT_SHIPPING_API_LEVEL ➡️ Since the kernel interface has changed, you need to ensure you set the correct value for this and it must contain the correct Android version if your device starts with Android 11+.
PRODUCT_PLATFORM ➡️ To define a hardware platform that configures the processes and routes necessary to assemble a specific Product-Chipset. Copy the same value from TARGET_BOARD_PLATFORM.
PRODUCT_BOARD ➡️ Same idea as above. Copy the same value from TARGET_BOOTLOADER_BOARD_NAME.
PRODUCT_PACKAGES ➡️ List of the modules to build. In this case, the device needs fastbootd binary files.
fastbootd ➡️ An optional module is installed only if it's required by the product configuration with PRODUCT_PACKAGES. The Custom Recovery need the fastboot & fastbootd for manage and flash files in the super.img partition.
# health HalPRODUCT_PACKAGES += \
android.hardware.health@2.1-impl \
android.hardware.health@2.1-service \
health ➡️ The files are compiled to manage the health part. There are requirements depending on each Android version.
2️⃣ device.mk for Recovery_ramdisk in the boot.img
ENABLE_VIRTUAL_AB ➡️ Comes from prop.default file by ro.virtual_ab.enabled=true line. This variable Implement A/B updates.
AB_OTA_UPDATER ➡️ Comes from prop.default file by ro.build.ab_update=true line. Set true to enable updating partitions through update_engine.
AB_OTA_PARTITIONS ➡️ Comes from prop.default file by ro.product.ab_ota_partitions=boot,system,vendor,product line. Configured by the the payload generator defines an update for list of any pair of A/B partitions defined in the same disk.
PRODUCT_PACKAGES ➡️ List of the modules to build. In this case, a set of path-related utility that manage MTK storage.
If your device has A12+ with emulated storage without sdcardfs, add the same variable as vendor_boot is defined.
2️⃣ device.mk for Recovery_ramdisk in the vendor_boot.img
For ramdisk recovery with vendor_boot.img file, the boot.img file is called Generic Boot Partition because contains the generic ramdisk and the GKI kernel.
Click to open
# Enable project quotas and casefolding for emulated storage without sdcardfs - # SDCard replacement functionality
$(callinherit-product, $(SRC_TARGET_DIR)/product/emulated_storage.mk)
emulated_storage.mk ➡️ Comes from prop.default file by external_storage.projid.enabled=1, external_storage.casefold.enabled=1 and external_storage.sdcardfs.enabled=0 lines that enable FUSE passthrough with A12+ and update Emulate Storage.
# Inherit from those products. Most specific first.
$(callinherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
$(callinherit-product, $(SRC_TARGET_DIR)/product/aosp_base.mk)#$(call inherit-product, $(SRC_TARGET_DIR)/product/base.mk)
core_64_bit.mk ➡️ It is determined by the AOSP source code. Always use for 64-bit devices, to compile binary files and leave the structure in accordance with the Architecture.
For 32-bit devices, remove the above 64-bit part and use:
# Inherit from those products. Most specific first.
$(callinherit-product, $(SRC_TARGET_DIR)/product/core_minimal.mk)
aosp_base.mk ➡️ It is determined by the AOSP source code. You can use this or base.mk if you want.
# Inherit from star device
$(callinherit-product,device/brand/devicename/device.mk)
device.mk ➡️ Comes from android_device_brand_devicename/device.mk file. This call all variables and flags in the device.mk file to build all necesssary.
# Inherit some common recovery stuff.
$(callinherit-product,vendor/twrp/config/common.mk)
# Device identifier. This must come after all inclusionsPRODUCT_DEVICE :=H166PRODUCT_NAME :=twrp_H166PRODUCT_BRAND :=FplusPRODUCT_MODEL :=H166PRODUCT_MANUFACTURER :=Fplus
PRODUCT_DEVICE ➡️ Comes from prop.default file by any *.device=.
PRODUCT_NAME ➡️ Comes from prop.default file by any *.device=.
It should actually come from prop.default file by any *.name=. But by Custom Recovery or AOSP source code rules, it must be the same as PRODUCT_DEVICE after twrp_.
PRODUCT_BRAND ➡️ Comes from prop.default file by any *.brand=.
PRODUCT_MODEL ➡️ Comes from prop.default file by any *.model=.
PRODUCT_MANUFACTURER ➡️ Comes from prop.default file by any *.manufacture=.
Some of the variables maintained in a PRODUCT_ definition file have a table.
3️⃣ twrp_devicename.mk for Recovery_ramdisk in the boot.img
Click to open
# Installs gsi keys into ramdisk, to boot a developer GSI with verified boot.
$(callinherit-product, $(SRC_TARGET_DIR)/product/gsi_keys.mk)
gsi_keys.mk ➡️ It is determined by the AOSP source code. Installs gsi keys into ramdisk, to boot a developer GSI with verified boot.
# Virtual A/B OTA
$(callinherit-product, $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)
virtual_ab_ota.mk ➡️ It is determined by the AOSP source code. It is determined by the AOSP source code. Install some files in \system\bin and \system\lib64 to correctly start updating the A/B structure and thus the OTA files.
Look, this mode is with boot_ramdisk and therefore, many files and processes change, specially in the device.mk file because of the Android11+ structure, so they need to be updated and redone. This line can inside in the device.mk file and if you choose that, so remove line from twrp_devicename.mk file.
3️⃣ twrp_devicename.mk for Recovery_ramdisk in the vendor_boot.img
launch_with_vendor_ramdisk.mk ➡️ It is determined by the AOSP source code. Devices launching with Virtual A/B and has a vendor_boot partition is preferred to inherit from this makefile.
Look, this mode is with vendor_boot_ramdisk and therefore, many files and processes change, specially in the device.mk file because of the Android12+ structure, so they need to be updated and redone. This line can inside in the device.mk file and if you choose that, so remove line from twrp_devicename.mk file.
Note
Understand that you must change some parts and know the difference to compile Custom Recovery with omni_ for A9 and earlier versions, as well as with twrp_ for A10 and later versions.
For A9 and earlier use the minimal manifest platform_manifest_twrp_omni. I think you understand why there is omni at the end of the word.
For A10 and later use the minimal manifest platform_manifest_twrp_aosp.
There are many different files that depend on what the device can have. You can read more about these files in the InfoGuide recovery.
Therefore, the approach below only serves as an information base for a given device, but obviously it can have many characteristics that are the same or different from other devices.
2.3 The folders /recovery/root/
Click to open
The Device Tree has these folders containing files that will be inserted directly into ramdisk. The structure of this part is the same as any stock ramdisk recovery and therefore must also follow the structure of the img stock file.
In this mode we can copy the folders with the files we need and want directly to the device tree. So pay close attention to the img stock file and its folders and files so that anything that needs to be copied is actually inserted into the Device Tree.
Important
By way of understanding, this part does not involve the inclusion of encryption/decryption files. This part is in item 3. Crypt-Decrypt and if you want a device tree with that part so can put everything together in one if that is your choice.
We start by understanding the need to check the folder and file structure of stock the recovery ramdisk so that if there are any folders and files to be included in the device tree, we should do that. But in most situations, we only interact with a maximum of 5 folders with files and some specific files directly in the \recovery\root\ folder. Don't be surprised if there is no folder or file on your stock recovery ramdisk like in the example below. Just copy what you need according to what exists on your recovery ramdisk!
In the root folder the device tree can have the correct file(s) mostly as the init.recovery.mtNNNN.rc; init.recovery.usb.rc and other init.*.rc or *.rc files for encrypt-decrypt process.
2.3.1 \recovery\root\
init.recovery.usb.rc
Inside this file, there are lines of programming that refer to information that might be important to start the addressing part of USB-related drivers like adb; fastboot; MTP; fastbootd and others you need. This file also contains permission lines, the references (letters and numbers) that will direct so that Custom Recovery can have access to the internal and external storage, in addition to being able to be seen by a file manager of a laptop, computer or even another smartphone. So the device with Custom Recovery can use too platform-tools (adb-fastboot-fastbootd) to access informations, folders, files, flash files, copying anything, etc.
There are many examples for many Mediatek devices. For this reason, the following example can be used, but you should be aware that it may not be good for your Chipset device. You should compare the examples with the stock file located at \vendor\etc\init\hw\init.mtNNNN.usb.rc for improvements and understanding.
Carry out tests and find the best file that can solve the case.
For knowledge, you can read and try something with the guide Troubleshooting or/and if device is using configfs, check Linux USB gadget instructions.
init.recovery.mtNNNN.rc
Comes from stock ramdisk_recovery by init.recovery.mtNNNN.rc file. For Custom Recovery builds without encryption/decryption, we just copy the stock init.recovery.mtNNNN.rc file and add some small extra parts.
Example - Click to open
oninitsetpropsys.usb.configfs1setpropsys.usb.ffs.aio_compat0onfs && property:ro.debuggable=0# distinguish USB shoulde connect or not, i.e. CDP vs SDPwrite/sys/class/udc/musb-hdrc/device/cmode2# set charging free due to it wait for USB activationstartadbdonpost-fs# Support A/B feature for EMMC and UFS boot regionsymlink/dev/block/sda /dev/block/mmcblk0boot0symlink/dev/block/sdb /dev/block/mmcblk0boot1symlink/dev/block/mmcblk0boot0 /dev/block/platform/bootdevice/by-name/preloader_asymlink/dev/block/mmcblk0boot1 /dev/block/platform/bootdevice/by-name/preloader_bsymlink/dev/block/mmcblk0boot0 /dev/block/by-name/preloader_asymlink/dev/block/mmcblk0boot1 /dev/block/by-name/preloader_bexecu:r:update_engine:s0rootroot -- /system/bin/mtk_plpath_utils
The above part should come from your stock init.recovery.mtNNNN.rc file. The part below has extra inclusions. Combine the two parts into a single init.recovery.mtNNNN.rc file.
Pay attention to the version of the stock files boot-hal-*N-*n; health-hal-*N-*n as they may be different due to the Android version.
2.3.2 \recovery\root\lib\modules\
As we know from the InfoGuide Touchscreen not working for Android 12+ version, the *.ko file folder with hardware modules is located in certain folders of the stock recovery_ramdisk and/or also in the stock vendor.img file. These *.ko module files will be useful for mainly enabling touch screen.
Either way, copy the entire stock folder and ALL files.
2.3.3 \recovery\root\first_stage_ramdisk
As we know by the partition dependency information Table, the first_stage_ramdisk folder is only needed if your ramdisk_recovery does not have the recovery.img file.
Inside these folder has files or a unique file like fstab.mtNNNN or and fstab.emmc. Copy only the file(s) from the same stock recovery_ramdisk\first_stage_ramdisk folder.
Some folders are mandatory because they contain important files that must be included in the device tree. But depending on each case, device-Chipset and Android version, we may include folders and files in the device tree that do not exist in the stock recovery ramdisk. These new folders and files can be used to try to solve something or just customize, as long as they are for really useful purposes. By adding irrelevant folders and files, you will be adding empty and useless parts to Custom Recovery.
2.3.4 \recovery\root\system\
bin\
mtk_plpath_utils
Copy the file from the same stock recovery_ramdisk\bin folder.
etc\
fstab.postinstall
task_profiles.json
Copy the files from the same stock system.img in the \system\etc folder.
recovery.fstab
Copy the fstab file from the same stock system.img in the \system\etc folder. But for quick and performance mounting important partition map, leave this file with only the some partitions.
The twrp.fstab or twrp.flags files must contain the necessary partitions for mounting, backup and also for the Custom Recovery to be able to make the MicroSD block partition (external_sd) and or OTG examine and mount (open) this in your internal filemanager or external filemanagers as well as give read and write capability.
The twrp.flags files must be edited according to your stock recovery.fstab file. But as a rule of Custom Recovery, the way it is written will be different and therefore must follow the following sequence:
| mount point | fstype | device | [device2] | [options - flags]
There are many Mediatek Chipset devices and for this reason, the following example can be used, but you should be aware that you MUST COMPARE the example with the stock recovery.fstab file and make all necessary changes in the twrp.flag file.
If the Custom Recovery not mount MicroSDCard and or OTG, you can get some informations from device using some tools like adb-fastboot, termux (need ROOT), ADB RUN or any other good tool. Insert MicroSDCard or and OTG of any size so that the external_sd / usb-otg address can look and later you should change correctlly in the twrp.flag file.
The example below show how have the correct sizes.
Copy the file from the same stock system.img in the \system\etc\vintf folder. You can add more files like compatibility_matrix.xml if you want.
lib64\
hw\
android.hardware.boot@1.0-impl-1.2-mtkimpl.so
Adding something in the lib64\ folder depends on each OEM firmware and the processes need to work. Copy the file from the same stock recovery_ramdisk\system\lib64\hw folder.
Tip
Pay attention to the version of the stock file android.hardware.boot@*N.*n-impl-*N.*n-mtkimpl.so as they may be different due to the Android version.
2.3.5 \recovery\root\vendor\
ueventd.rc
Copy the file from the same stock vendor.img in the \vendor folder if firmware file have recovery.img file.
etc\
vintf\
manifest.xml
Copy the file from the same stock vendor.img in the \vendor\etc\vintf folder. You can add more files like compatibility_matrix.xml if you want.
ueventd.rc
With firmware file have only boot.img file or have vendor_boot.img file, copy the stock \vendor\etc\ueventd.rc file from the stock vendor.img file to device tree vendor\etc folder.
firmware\
As we know from the InfoGuide Touchscreen not working for Android 10+ version, the firmware folder can have hardware binary files of the stock vendor.img file. These *.bin files will be useful for mainly enabling touch screen. But if the correct files are not in that folder, you should check the stock vendor.img file in the \vendor\lib\modules\ folder.
lib\
modules\
As we know from the InfoGuide Touchscreen not working for Android 10+ version, the *.ko files with hardware modules is located in certain folders of the stock vendor.img file in the \vendor\lib\modules\ folder. These *.ko files will be useful for mainly enabling touch screen.
If the correct files are not in that folder, you should check the firmware file if have vendor_dlkm.img file and so confirm in the \vendor_dlkm\lib\modules\ folder.
To better understand the organization of the structure with files, the example below is for an MT6833 device:
Click to open
Note
This InfoGuide is not intended to cover extra topics about folders and files beyond what is necessary or for extra customization. So understand that if your Custom Recovery has problems that cannot be easily resolved, then it is time to ask for help and find experts or experienced developers.
Many times, even with all the correct files and processes, there is a dependency on the Custom Recovery source code. Obviously, Custom Recovery being a type of OS, it needs to interact correctly and be updated in order to have functionality according to the Android version.
So being sure which files and how the encryption process works is important. Having confidence and conviction that everything is right makes you understand the limits on the Custom Recovery source code. Don't get frustrated if something doesn't work. Sometimes the Custom Recovery source code takes time to update, but in this case you must confirm who failed.
3.1 Process & Files
The way the encryption process occurs and how it can be decrypted is not the subject here! This requires a lot of programming knowledge and experience with firmware.
Note that depending on the Android version originally shipped to the device, encryption modes may have FDE (deprecated in Android 11+) and currently FBE. The files to enable these modes can have FDE binaries + gatekeeper or FBE binaries + gatekeeper.
Important
This InfoGuide is only intended to highlight FBE mode how BoardConfig.mk is set in the # Crypto item. It can serve as something similar for FDE mode, but the flags must be different.
The fact is that there can be many encryption types, some of which are obsolete, others continue in a different form and others are still in use, and may have updates depending on the kernel and Android version. But currently there are three types of encryption for most Mediatek devices. In this document there will be no guidance for any type of encryption for a specific manufacturing company, because many devices from the same company may have different types of encryption.
First we must know what type of encryption is applied to the device. There are a few ways to identify that.
Unpack the stock recovery ramdisk img file and open the prop.default file. Find the trust or trustkernel or tee or beanpod or trustonic line;
Unzip the stock super.img\vendor.img file and find the \bin\hw folder look if have is some file called *-service.beanpod or *-service.trustkernel or *-service.trustonic;
Unzip the stock super.img\vendor.img file and find the \etc\init folder look if have is some file called microtrust.rc or trustkernel.rc or trustonic.rc;
With ROOT you can use adb with the adb getprop command to obtain information from the prop.default file and thus search for the type of encryption.
Tip
How to know which binary files are dependent on other binary files?
Read and learn how to use ldcheck. Change the file reference in the vendor\bin\qseecomd folder to its reference in the vendor\bin\ folder of the file's encryption type.
If you want to read and understand about Actions and Services as a way of executing processes, then read Android Init Language.
3.2 Trustkernel
This type of encryption is not widely used. But when it exists on a device, it has been the most annoying and frustrating way to try to get it to work. Generally speaking, some developers with Android 9 devices were able to do something. But with the device shipping with Android 10, it didn't work the same way.
But a smart and hardy guy developer named @ADeadTrousers took a while for other users to have something actually working on Android 10 and Android 11.
Click to open
Understanding this, you should find some files related to trustkernel. These files come from the stock vendor.img file and must be located in:
Pay attention to file updates! Example: The above android.hardware.keymaster@4.0-service.trustkernel file can change to android.hardware.keymaster@4.1-service.trustkernel or android.hardware.security.keymint-service.trustkernel.rc. So you must modify every part of files where this *-service.trustkernel file is being referenced.
There are other files, but they are optional (maybe):
\vendor\bin
kph
pld
tee_check_keybox
\vendor\lib64
libkphhelper.so
libkphproxy.so
libpl.so
As a preference, get a device tree that actually works, even if it is to compile the recovery.img file. It has been tested by compiling the Custom Recovery in boot.img file and it works. So don't forget to thank and give credits to @ADeadTrousers.
android\brand\devicename\recovery\root
There may be differences between devices, so open the stock ramdisk\init.recovery.{hardware}.rc file and note the on post-fs line in the init.recovery.mtNNNN.rc file below.
This is the script file that performs the decryption and is referenced (import) line in the init.recovery.mtNNNN.rc file. Note that there are processes and phases of file targeting so that decryption can be done.
Some text files are important to know how they are written and to place inside the init.recovery.mtNNNN.rc file like android.hardware.gatekeeper@1.0-service.rc and android.hardware.keymaster@4.0-service.trustkernel.rc. You can choose to remove these files from the folder and place them inside the init.recovery.mtNNNN.rc file. This is optional. So if you do that, remove the reference (symlink) line from the same file in the init.recovery.mtNNNN.rc file. Remove the aforementioned files from the \vendor\etc\init folder so there is no confusion.
Add the line below so that Custom Recovery has permission over the process. This should happen for all *-service files.
seclabelu:r:recovery:s0
As we will copy what the script author did, it is necessary to compare the stock file vendor\etc\init\trustkernel.rc with the file below. If there are any modifications to be made, then do as the stock file has.
Click to open
onpost-fswrite/proc/bootprof"tkcore: prepare system ta path"restorecon/mnt/vendor/persistmkdir/mnt/vendor/persist/t6_twrpchownsystemsystem/mnt/vendor/persist/t6_twrprestorecon/mnt/vendor/persist/t6_twrprestorecon/mnt/vendor/protect_fmkdir/mnt/vendor/protect_f/tee_twrpchownsystemsystem/mnt/vendor/protect_f/tee_twrprestorecon/mnt/vendor/protect_f/tee_twrpstartteedonproperty:vendor.trustkernel.fs.state=preparewrite/proc/bootprof"tkcore: prepare basic"mkdir/data/vendor/t6chownsystemsystem/data/vendor/t6restorecon/data/vendor/t6write/proc/bootprof"tkcore: prepare sfs"mkdir/data/vendor/t6/fschownsystemsystem/data/vendor/t6/fsrestorecon/data/vendor/t6/fswrite/proc/bootprof"tkcore: prepare service provider ta path"mkdir/data/vendor/t6/appchownsystemsystem/data/vendor/t6/apprestorecon/data/vendor/t6/appsetpropvendor.trustkernel.fs.stateready# For non-encrypted caseonproperty:ro.crypto.state=unencryptedsetpropvendor.trustkernel.fs.mode1setpropvendor.trustkernel.fs.stateprepare# For FDE/encrypted successfullyonproperty:vold.decrypt=trigger_restart_frameworksetpropvendor.trustkernel.fs.mode2setpropvendor.trustkernel.fs.stateprepare# For FBE/encrypted successfullyonproperty:ro.crypto.type=file && property:ro.crypto.state=encryptedsetpropvendor.trustkernel.fs.mode3setpropvendor.trustkernel.fs.stateprepareonproperty:vendor.trustkernel.log.state=readywrite/proc/bootprof"tkcore: prepare log file"restorecon/data/vendor/t6/tkcore.logsetpropvendor.trustkernel.log.stateenableonproperty:vendor.trustkernel.ready=truestarttee_check_keyboxserviceteed/vendor/bin/teed \
--datapath /data/vendor/t6/fs \
--sptapath /data/vendor/t6/app \
--systapath /vendor/app/t6 \
--rpmbdev /dev/mmcblk0rpmb \
--rpmbdev /dev/rpmb0 \
--prot /mnt/vendor/persist/t6_twrp \
--prot /mnt/vendor/protect_f/tee_twrp \
--logpath /data/vendor/t6/tkcore.log \
--proprefixvendor.trustkernelcapabilitiesSYS_RAWIOusersystemgroupsystemclasscoreseclabelu:r:recovery:s0servicetee_check_keybox/vendor/bin/tee_check_keyboxusersystemgroupsystemclassmaindisabledoneshotseclabelu:r:recovery:s0
If everything is ok, then copy the above script with the name trustkernel.rc as it came from stock in the same folder in the device tree.
Again there is another script file that the author made, but we just copied it to the android\brand\devicename\recovery\root\vendor\bin\trustkernel.twrp.sh folder as you can see below.
Files come from the stock system.img file and must be located in:
\system\etc\vintf
manifest.xml
Copy all folders and all files within \vendor to the device tree under android\brand\devicename\recovery\root\vendor\ and all files within \system to the device tree under android\brand\devicename\recovery\root\system\. Remember that the files init.recovery.mtNNNN.rc and init.recovery.trustkernel.rc must be in android\brand\devicename\recovery\root.
To better understand the organization of the structure with encryption/decryption files, an example below for an MT6762 device:
Click to open
Currently I have seen two devices shipping with Android 12 - kernel 5.1.xxx which has trustkernel. But it hasn't worked yet (tests in one device MT6789 carried out until October 2023) as far as I know. Maybe someone sucessded.
This type of encryption is one of the smoothest types there is to run on a device. Not only because of the simplicity of just a few files, but because since before Android 9, it has always worked without difficulties and extra efforts. Well, for Android 11+ versions it all depends on the Custom Recovery source code.
Click to open
Understanding this, you should find some files related to beanpod. These files come from the stock vendor.img file and must be located in:
Pay attention to file updates! Example: The above android.hardware.keymaster@4.1-service.beanpod file can change to android.hardware.keymaster@4.0-service.beanpod or android.hardware.security.keymint-service.beanpod.rc. So you must modify every part of files where this *-service.beanpod file is being referenced.
In tests carried out with Custom Recoveries, they did not need to include files with vendor.mediatek.hardware.keymaster_attestation**, as decryption worked without them. So that's optional.
android\brand\devicename\recovery\root
There may be differences between devices, so open the stock ramdisk\init.recovery.{hardware}.rc file and note the line on post-fs through on post-fs in the init.recovery.mtNNNN.rc file below.
init.recovery.mtNNNN.rc
Click to open
import/init.recovery.microtrust.rc on init # Create a more standard /dev/blocklayoutforourscriptssymlink/dev/block/platform/bootdevice /dev/block/bootdeviceexportLD_LIBRARY_PATH/system/lib64:/vendor/lib64:/vendor/lib64/hw:/system/lib64/hwonfsmkdir/mnt/vendor/persist0771rootrootmountext4/dev/block/platform/bootdevice/by-name/persist /mnt/vendor/persistinstall_keyringsetpropcrypto.ready1servicekeystore_auth/system/bin/keystore_authoneshotusersystemgrouprootdisabledseclabelu:r:recovery:s0servicekeystore/system/bin/keystore /tmp/misc/keystoreuserrootgrouprootdrmrpcreadprocdisabledseclabelu:r:recovery:s0servicegatekeeper-1-0 /vendor/bin/hw/android.hardware.gatekeeper@1.0-serviceinterfaceandroid.hardware.gatekeeper@1.0::IGatekeeperdefaultclasshaluserrootgrouprootdisabledseclabelu:r:recovery:s0servicekeymaster-4-1 /vendor/bin/hw/android.hardware.keymaster@4.1-service.beanpodinterfaceandroid.hardware.keymaster@4.0::IKeymasterDevicedefaultinterfaceandroid.hardware.keymaster@4.1::IKeymasterDevicedefaultclassearly_haluserrootgrouprootdrmrpcdisabledseclabelu:r:recovery:s0onproperty:vendor.sys.listener.registered=truestartgatekeeper-1-0startkeymaster-4-1onproperty:crypto.ready=1startkeymaster-4-1onproperty:hwservicemanager.ready=truestartkeymaster-4-1startgatekeeper-1-0onproperty:ro.crypto.state=unsupportedstopteei_daemonstopkeymaster-4-1stopgatekeeper-1-0onproperty:ro.crypto.state=unencryptedstopteei_daemonstopkeymaster-4-1stopgatekeeper-1-0onproperty:twrp.decrypt.done=truestopteei_daemonstopkeymaster-4-1stopgatekeeper-1-0oninit# **COPY YOUR STOCK ramdisk\init.recovery.{hardware}.rc `oon init` FILE HERE!!**onfs && property:ro.debuggable=0# **COPY YOUR STOCK ramdisk\init.recovery.{hardware}.rc `on fs` FILE HERE!!**onpost-fs# Support A/B feature for EMMC and UFS boot region# **COPY YOUR STOCK ramdisk\init.recovery.{hardware}.rc `on post-fs` FILE HERE!!**startmtk.plpath.utils.linkservicemtk.plpath.utils.link/system/bin/mtk_plpath_utilsclassmainuserrootgrouprootsystemoneshotdisabledseclabelu:r:recovery:s0onbootstartboot-hal-1-2starthealth-hal-2-1
Some text files are important to know how they are written and place them inside the init.recovery.mtNNNN.rc file, such as android.hardware.gatekeeper@1.0-service.rc and android.hardware.keymaster@4.1-service.beanpod.rc. You can choose to remove these files from the folder and place them inside the init.recovery.mtNNNN.rc file. This is optional and please note this is what I did. Also note that there is no inclusion (import) line of the same file in init.recovery.mtNNNN.rc related to the files mentioned in the stock folder \vendor\etc\init.
init.recovery.microtrust.rc
This is the script file that performs the decryption and is referenced (import) line in the init.recovery.mtNNNN.rc file. Note that there are processes and phases of file targeting so that decryption can be done.
It is necessary to compare the stock file vendor\etc\init\microtrust.rc with the file below. If there are any modifications to be made, do so according to the stock file.
Click to open
# For MTK DRM integration:serviceteei_daemon/vendor/bin/teei_daemon \
-r020b0000000000000000000000000000 \
-r020f0000000000000000000000000000 \
-r06090000000000000000000000000000 \
-r05120000000000000000000000000000 \
-r40188311faf343488db888ad39496f9a \
-r07060000000000000000000000007169 \
-r4be4f7dc1f2c11e5b5f7727283247c7f \
-r9073f03a9618383bb1856eb3f990babd \
-r08050000000000000000000000003419 \
-r5020170115e016302017012521300000 \
-r0f5eed3c3b5a47afacca69a84bf0efad \
-r07407000000000000000000000000000 \
-r05160000000000000000000000000000 \
-r91dba524a6e24909acc48abd7163121a \
-r08070000000000000000000000008270 \
-r09080000000000000000000000009381 \
-t08030000000000000000000000000000 \
-t85f630e0f0964c5fa2cc268ce04e3da3 \
-t98fb95bcb4bf42d26473eae48690d7ea \
-t7b66512021214487ba710a51d7ea78fe \
-t09010000000000000000000000000000userrootgrouprootdisabledseclabelu:r:recovery:s0# oneshotonbootchownsystemsystem/sys/bus/platform/devices/utos/dcih_notify_testchownsystemsystem/sys/bus/platform/devices/utos/dcih_wait_notify_testchownsystemsystem/sys/bus/platform/devices/utos/load_ut_drvchownsystemsystem/sys/bus/platform/devices/utos/unload_ut_drvchownsystemsystem/sys/bus/platform/devices/utos/notify_ree_dci_handler#for All modeonload_persist_props_actionwrite/proc/bootprof"start teei cfg (on load_persist_props_action)"mkdir/data/vendor/thhmkdir/data/vendor/thh/systemmkdir/data/vendor/thh/tee_00mkdir/data/vendor/thh/tee_01mkdir/data/vendor/thh/tee_02mkdir/data/vendor/thh/tee_03mkdir/data/vendor/thh/tee_04mkdir/data/vendor/thh/tee_05mkdir/data/vendor/thh/tee_06mkdir/data/vendor/thh/tee_07mkdir/data/vendor/thh/teemkdir/data/vendor/thh/tee/tasmkdir/data/vendor/thh/tee_08mkdir/data/vendor/thh/tee_09mkdir/data/vendor/thh/tee_0Amkdir/data/vendor/thh/tee_0Bmkdir/data/vendor/thh/tee_0Cmkdir/data/vendor/thh/tee_0Dmkdir/data/vendor/thh/tee_0Emkdir/data/vendor/thh/tee_0Fmkdir/data/vendor/thh/tamkdir/data/vendor/thh/tee_logmkdir/data/vendor/key_provisioningchmod0755 /data/vendor/thhchownsystemsystem/data/vendor/thhchmod0755 /data/vendor/thh/tee_00chownsystemsystem/data/vendor/thh/tee_00chmod0755 /data/vendor/thh/tee_01chownsystemsystem/data/vendor/thh/tee_01chmod0755 /data/vendor/thh/tee_02chownsystemsystem/data/vendor/thh/tee_02chmod0755 /data/vendor/thh/tee_03chownsystemsystem/data/vendor/thh/tee_03chmod0755 /data/vendor/thh/tee_04chownsystemsystem/data/vendor/thh/tee_04chmod0755 /data/vendor/thh/tee_05chownsystemsystem/data/vendor/thh/tee_05chmod0755 /data/vendor/thh/tee_06chownsystemsystem/data/vendor/thh/tee_06chmod0755 /data/vendor/thh/tee_07chownsystemsystem/data/vendor/thh/tee_07chmod0755 /data/vendor/thh/teechownsystemsystem/data/vendor/thh/teechmod0755 /data/vendor/thh/tee/taschownsystemsystem/data/vendor/thh/tee/taschmod0755 /data/vendor/thh/tee_08chownsystemsystem/data/vendor/thh/tee_08chmod0755 /data/vendor/thh/tee_09chownsystemsystem/data/vendor/thh/tee_09chmod0755 /data/vendor/thh/tee_0Achownsystemsystem/data/vendor/thh/tee_0Achmod0755 /data/vendor/thh/tee_0Bchownsystemsystem/data/vendor/thh/tee_0Bchmod0755 /data/vendor/thh/tee_0Cchownsystemsystem/data/vendor/thh/tee_0Cchmod0755 /data/vendor/thh/tee_0Dchownsystemsystem/data/vendor/thh/tee_0Dchmod0755 /data/vendor/thh/tee_0Echownsystemsystem/data/vendor/thh/tee_0Echmod0755 /data/vendor/thh/tee_0Fchownsystemsystem/data/vendor/thh/tee_0Fchmod0755 /data/vendor/thh/tee_logchownsystemsystem/data/vendor/thh/tee_logchmod0755 /data/vendor/thh/tachownsystemsystem/data/vendor/thh/tachmod0755 /data/vendor/thh/systemchownsystemsystem/data/vendor/thh/systemrestorecon_recursive/data/vendor/thhchmod0771 /data/vendor/key_provisioningchownsystemsystem/data/vendor/key_provisioningwrite/proc/bootprof"start teei cfg end (on load_persist_props_action)"onproperty:vold.decrypt=trigger_restart_frameworkwrite/proc/bootprof"start teei cfg (on trigger_restart_framework)"mkdir/data/vendor/thhmkdir/data/vendor/thh/systemmkdir/data/vendor/thh/tee_00mkdir/data/vendor/thh/tee_01mkdir/data/vendor/thh/tee_02mkdir/data/vendor/thh/tee_03mkdir/data/vendor/thh/tee_04mkdir/data/vendor/thh/tee_05mkdir/data/vendor/thh/tee_06mkdir/data/vendor/thh/tee_07mkdir/data/vendor/thh/teemkdir/data/vendor/thh/tee/tasmkdir/data/vendor/thh/tee_08mkdir/data/vendor/thh/tee_09mkdir/data/vendor/thh/tee_0Amkdir/data/vendor/thh/tee_0Bmkdir/data/vendor/thh/tee_0Cmkdir/data/vendor/thh/tee_0Dmkdir/data/vendor/thh/tee_0Emkdir/data/vendor/thh/tee_0Fmkdir/data/vendor/thh/tamkdir/data/vendor/key_provisioningmkdir/data/vendor/thh/tee_logchmod0755 /data/vendor/thhchownsystemsystem/data/vendor/thhchmod0755 /data/vendor/thh/tee_00chownsystemsystem/data/vendor/thh/tee_00chmod0755 /data/vendor/thh/tee_01chownsystemsystem/data/vendor/thh/tee_01chmod0755 /data/vendor/thh/tee_02chownsystemsystem/data/vendor/thh/tee_02chmod0755 /data/vendor/thh/tee_03chownsystemsystem/data/vendor/thh/tee_03chmod0755 /data/vendor/thh/tee_04chownsystemsystem/data/vendor/thh/tee_04chmod0755 /data/vendor/thh/tee_05chownsystemsystem/data/vendor/thh/tee_05chmod0755 /data/vendor/thh/tee_06chownsystemsystem/data/vendor/thh/tee_06chmod0755 /data/vendor/thh/tee_07chownsystemsystem/data/vendor/thh/tee_07chmod0755 /data/vendor/thh/teechownsystemsystem/data/vendor/thh/teechmod0755 /data/vendor/thh/tee/taschownsystemsystem/data/vendor/thh/tee/taschmod0755 /data/vendor/thh/tee_08chownsystemsystem/data/vendor/thh/tee_08chmod0755 /data/vendor/thh/tee_09chownsystemsystem/data/vendor/thh/tee_09chmod0755 /data/vendor/thh/tee_0Achownsystemsystem/data/vendor/thh/tee_0Achmod0755 /data/vendor/thh/tee_0Bchownsystemsystem/data/vendor/thh/tee_0Bchmod0755 /data/vendor/thh/tee_0Cchownsystemsystem/data/vendor/thh/tee_0Cchmod0755 /data/vendor/thh/tee_0Dchownsystemsystem/data/vendor/thh/tee_0Dchmod0755 /data/vendor/thh/tee_0Echownsystemsystem/data/vendor/thh/tee_0Echmod0755 /data/vendor/thh/tee_0Fchownsystemsystem/data/vendor/thh/tee_0Fchmod0755 /data/vendor/thh/tee_logchownsystemsystem/data/vendor/thh/tee_logchmod0755 /data/vendor/thh/tachownsystemsystem/data/vendor/thh/tachmod0755 /data/vendor/thh/systemchownsystemsystem/data/vendor/thh/systemchmod0771 /data/vendor/key_provisioningchownsystemsystem/data/vendor/key_provisioningrestorecon_recursive/data/vendor/thhwrite/proc/bootprof"start teei cfg end (on trigger_restart_framework)"onpost-fs# Set /mnt/vendor/persist/rpmbchownsystemsystem/mnt/vendor/persistchmod0771 /mnt/vendor/persistrestorecon_recursive/mnt/vendor/persistmkdir/mnt/vendor/persist/rpmbchownsystemsystem/mnt/vendor/persist/rpmbchmod0771 /mnt/vendor/persist/rpmbrestorecon_recursive/mnt/vendor/persist/rpmb# Set other rpmbmkdir/persist/rpmbmkdir/vendor/persist/rpmbchmod0771 /persist/rpmbchmod0771 /vendor/persist/rpmbchownsystemsystem/persist/rpmbchownsystemsystem/vendor/persist/rpmbrestorecon_recursive/persist restorecon_recursive /vendor/persistonfschmod0660 /dev/teei_clientchownsystemsystem/dev/teei_clientchmod0660 /dev/teei_configchownsystemsystem/dev/teei_config# 666 for SVPchmod0666 /dev/isee_tee0chownsystemdrmrpc/dev/isee_tee0chmod0660 /dev/tz_vfschownsystemsystem/dev/tz_vfschmod0660 /dev/teei_fpchownsystem/dev/teei_fpchownsystemdrmrpc/dev/ut_keymasterchmod0660 /dev/ut_keymaster# rpmb devicechmod0660 /dev/rpmb0chownsystemsystem/dev/rpmb0chmod0660 /dev/mmcblk0rpmbchownrootsystem/dev/mmcblk0rpmb# legacy rpmb device for cross-platform compatibilitychmod0660 /dev/emmcrpmb0chownsystemsystem/dev/emmcrpmb0chownsystemsystem/dev/utr_tuichmod0660 /dev/utr_tuiwrite/proc/bootprof"start teei_daemon (on fs)"startteei_daemonwrite/proc/bootprof"start teei_daemon end (on fs)"onproperty:vendor.crypto.fake_encrypt=1 && property:vold.post_fs_data_done=1setpropvendor.soter.teei.crypto.stateunencrypted
Files come from the stock system.img file and must be located in:
\system\etc\vintf
manifest.xml
Copy all folders and all files within \vendor to the device tree under android\brand\devicename\recovery\root\vendor\ and all files within \system to the device tree under android\brand\devicename\recovery\root\system\. Remember that the files init.recovery.mtNNNN.rc and init.recovery.microtrust.rc must be in android\brand\devicename\recovery\root.
To better understand the organization of the structure with encryption/decryption files, an example below for an MT6877 device:
Click to open
From my experience, there are devices shipped with Android 11 with kernel 4.19, devices shipped with Android 12 with kernel 4.14 and with kernel 5.1.xxx that have beanpod with fully functional decryption.
This type of encryption is one of the most used in devices from the Infinix, Tecno, Realme and some Xiaomi-Poco brands. It has been used since before Android 9 and for the most part it has always worked well. So for Android 11+ versions, it all depends on the Custom Recovery source code.
Click to open
Understanding this, you should find some files related to trustonic. These files come from the stock vendor.img file and must be located in:
\vendor\app\mcRegistry
Get the entire \app folder and all the files.
\vendor\bin
mcDriverDaemon
\vendor\bin\hw
android.hardware.gatekeeper@1.0-service
android.hardware.keymaster@4.0-service.trustonic
vendor.trustonic.tee@1.1-service
\vendor\etc\vintf
manifest.xml
\vendor\lib64
libkmsetkey.so
libladder.so
libMcClient.so
libTEECommon.so
vendor.trustonic.tee.tui@1.0.so
vendor.trustonic.tee@1.0.so
vendor.trustonic.tee@1.1.so
\vendor\lib64\hw
android.hardware.gatekeeper@1.0-impl.so
gatekeeper.default.so
gatekeeper.trustonic.so
kmsetkey.default.so
kmsetkey.trustonic.so
libMcGatekeeper.so
libSoftGatekeeper.so
Depending on the Android and kernel version, your device has a few more dependent binary files. You can check the \vendor\ stock folders for the files in the:
bin\
paytrigger_test
bin\hw\
vendor.mediatek.hardware.paytrigger@1.0-service
lib64\
libmtk_bsg.so
liburee_meta_drmkeyinstall.so
vendor.mediatek.hardware.paytrigger@1.0.so
lib\hw\
paytrigger.trustonic.so
Pay attention to file updates! Example: The above android.hardware.keymaster@4.0-service.trustonic file can change to android.hardware.keymaster@4.1-service.trustonic or android.hardware.security.keymint-service.trustonic.rc. So you must modify every part of files where this *-service.trustonic file is being referenced.
android\brand\devicename\recovery\root
There may be differences between devices, so open the stock ramdisk\init.recovery.{hardware}.rc file and note the line on post-fs through on post-fs in the init.recovery.mtNNNN.rc file below.
Some text files are important to know how they are written and place them inside the init.recovery.mtNNNN.rc file, such as android.hardware.gatekeeper@1.0-service.rc and android.hardware.keymaster@4.0-service.trustonic.rc. You can choose to remove these files from the folder and place them inside the init.recovery.mtNNNN.rc file. This is optional and please note this is what I did. Also note that there is no inclusion (import) line of the same file in init.recovery.mtNNNN.rc related to the files mentioned in the stock folder \vendor\etc\init.
The files below are script files that perform decryption and are referenced in the (import) lines in the init.recovery.mtNNNN.rc file. Note that there are processes and phases of file targeting so that decryption can be done.
It is necessary to compare the stock files vendor\etc\init\tee.rc; vendor\etc\init\trustonic.rc and vendor\etc\init\vendor.trustonic.tee@1.1-service.rc with the file below. If there are any modifications to be made, do so according to the stock file.
tee.rc
Click to open
oninit#create mountpoint for /mnt/vendor/persist partitionmkdir/mnt/vendor/persist0771systemsystemonpost-fschownsystemsystem/mnt/vendor/persistchmod0771 /mnt/vendor/persist# We restorecon /mnt/vendor/persist to set SEPolicy label.restorecon/mnt/vendor/persist# Create mcRegistry to store failure recordmkdir/mnt/vendor/persist/mcRegistry0771systemsystemmkdir/mnt/vendor/persist/paytriggerchownsystemsystem/mnt/vendor/persist/paytriggerchmod0777 /mnt/vendor/persist/paytriggeronpost-fs-data# Create /data/vendor/key_provisioning dir and get proper encryption policy installed# Key Installationmkdir/data/vendor/key_provisioning0771systemsystem# For META/FACTORY modeonproperty:ro.crypto.state=unencryptedwrite/proc/bootprof"MOBICORE: create /data/vendor/mcRegistry ++ (unencrypted)"mkdir/data/vendor/mcRegistry0775systemsystemwrite/proc/bootprof"MOBICORE: create /data/vendor/mcRegistry -- (unencrypted)"# Normal mode, FBEonproperty:ro.crypto.type=file && property:ro.crypto.state=encryptedwrite/proc/bootprof"MOBICORE: create /data/vendor/mcRegistry ++ (FBE encrypted)"mkdir/data/vendor/mcRegistry0775systemsystemwrite/proc/bootprof"MOBICORE: create /data/vendor/mcRegistry -- (FBE encrypted)"# Normal mode, FDEonproperty:vold.decrypt=trigger_restart_frameworkwrite/proc/bootprof"MOBICORE: create /data/vendor/mcRegistry ++ (FDE encrypted)"mkdir/data/vendor/mcRegistry0775systemsystemwrite/proc/bootprof"MOBICORE: create /data/vendor/mcRegistry -- (FDE encrypted)"
Depending on the Android and kernel version, your device has a few more dependent binary files and need more services files. You can check the vendor\etc\init\vendor.mediatek.hardware.paytrigger@1.0-service.rc. Add the line below so that Custom Recovery has permission over the process. This should happen for all *-service files.
Files come from the stock system.img file and must be located in:
\system\etc\vintf
manifest.xml
\system\lib64
libTeeClient.so
vendor.trustonic.tee@1.0.so
vendor.trustonic.tee@1.1.so
Copy all folders and all files within \vendor to the device tree under android\brand\devicename\recovery\root\vendor\ and all files within \system to the device tree under android\brand\devicename\recovery\root\system\. Remember that the files init.recovery.mtNNNN.rc and init.recovery.trustonic.rc must be in android\brand\devicename\recovery\root.
To better understand the organization of the structure with encryption/decryption files, an example below for an MT6877 device:
Click to open
From my experience, there are devices shipped with Android 11 with kernel 4.19, devices shipped with Android 12-13 with kernel 4.14 and with kernel 5.1.xxx that have beanpod with fully functional decryption.
If you have time, so read more with the book Android System Programming - Porting, customizing, and debugging Android HAL by Roger Ye ---- First published: May 2017 - 464 pages
Thanks of the Android Source Code AOSP and to all developers ope source who help and update that.
Thanks to the 4pda forum and everyone on this forum who contribute to the development in general for Custom Recovery, Custom ROMs/GSI and tools to use with device development.
Thanks to Phil3759 because he did a CWM/PhilZ Touch Custom Recovery - very interesting and still needed today. I learned how to improve the PORT Custom Recovery process with this Custom Recovery.
Thanks to Carliv aka bluefirebird because I learned more from him about compiling CTR.img is better than exchanging files with PORT Custom Recovery process. Furthermore, this guy also developed CTR for Mediatek devices. Well, you might know him more because of CarlivImageKitchen that he developed.
Thanks of the Source Code Custom Recovery to @TeamWin and to all the people who help update that, as well as the people who help Mediatek devices to have a more functional Custom Recovery.
Thanks of the Source Code Custom Recovery to @OrangeFox and to all the people who help update that, as well as the people who help Mediatek devices to have a more functional Custom Recovery.
Thanks of the Source Code Custom Recovery to @PitchBlack and to all the people who help update that, as well as the people who help Mediatek devices to have a more functional Custom Recovery.
Thanks to @osm0sis for keeping AIK always up to date for use.
Thanks to all the people who left some Mediatek device tree repository available so that other users can fork and not waste too much time creating a device tree from nothing.
Last updated on 03/05/2024.
