lopestom/Custom Recovery for MediaTek devices-0.md

## Custom Recovery for MediaTek devices-0.md

      
    Raw
  

              Custom Recovery for MediaTek devices-0.md
            
          
    Preface

Before anything or any comments or ideas, this is a way I wanted to try to inform and update what a device tree is and what it has, and finally how Custom Recovery is created.
So this is not a complete guide and it won't be! I never intended to do that.
The original idea

Please take a look and may you take a few minutes to read the original guide. I had written myself that I intended to update the information. I hope that after reading the original guide you can go back and have a few minutes of reading and mainly practice to gain experience.

This guide comes to complement or update some important information. All thanks to @rokibhasansagar about first guide Make A TWRP Tree For Your Device & Build

Certainly, given the breadth of the subject, it should have many more parts. But understand about "Minimal" thinking and that I didn't intend to extend it any further than necessary.
So the guide has:


What you need? part 1 of 3


Understanding folders & files of the device tree. part 2 of 3


Understanding some important files of the Device Tree. part 3 of 3


............ Good reading ............

  
## Custom Recovery for MediaTek devices-I.md

      
    Raw
  

              Custom Recovery for MediaTek devices-I.md
            
          
    How to create a working device tree for compile Custom Recovery for Mediatek devices.

Before you start reading, I want to ask, understand, ask that you can donate money to the main developers. These guys, who aren't many, donate their time and also money so that the Custom Recovery code is working and updating every time. I make random donations of $10 to $50 myself to some developers or directly to the donation link that each Custom Recovery has the link to. Obviously if you don't want to donate, no one is forcing you, but try to write credits for them as well.
The idea about guide

Being able to start building them from Android 10 and Android 11 up to a possibility for Android 12 (new configuration information must be done depending on whether it is an update or if the device shipped with the Android version).

This guide comes to complement or update some important information since Android 10 was released from forked guide Make A TWRP Tree For Your Device & Build.


This Guide is tested on 64-bit MT6xxx chipset device. It will also work on any 64-bit and 32-bit devices [You should understand the way 32-bit should be configured]. I'ts a Minimal Guide for help users with start Custom Recovery knowledge!!

We assume that you know how to deal with adb - fastboot commands, bootloader, lock/unlock bootloader, ROOT, unpack/repack tools and know how github works! Obviously knowing something about Linux is part of this journey, and if you want to compile the recovery.img file yourself, you must have a Linux distro [Ubuntu; Debian; Arch - is prefered] on your computer with at least 6GB RAM and 256GB ROM - ideal is to have 16GB RAM and 1TB ROM.
You need read and learning about Android structure as Update or Basic.

This work for devices called Smartphone or Tablet but need more informations in the device tree. But it can be a good start for other devices with TV-Box, Android TV or Android System devices that have Mediatek Soc.

What you need?

Depending on what you know and what you want, a lot of files and knowledge are important. Especially if you want encryption/decryption because it takes more than you think. Let's focus on starting TWRP on the device but without going too far to try the encryption/decryption desire later. I will make it clear that this is not an easy task, mainly because it requires a lot of knowledge, patience with TeamWin's updated and functional code and obviously testing and more testing. Therefore, that is not the main objective here. If you want know more so read Encryption.
I. Get Your Official Stock ROM/Firmware with same Android version of your device;

If you don't have a Stock ROM so you can make a Read Back with SPFT Smart Phone Flash Tool. Not need unlock bootloader!
Some devices need mtkclient to have that.
At this point we need files like super.img and boot.img. With boot.img file many devices shipped with A11 have slot_a/slot_b and therefore use the Virtual A/B structure. But some devices that upgrade from A10 to A11 may still use recovery.img file and that should be the point of understanding that it usually uses A/B structure.
II. Get some informations from device using adb-fastboot platform-tool;

Some informations is easy and other no much. But depending what you have, all can do that. Here we not write how developer option is enable in the device. You should need know!!
If possible, insert MicroSD or and OTG of any size so that the external_sd / OTG address can have and later be placed in the fstab file so that the MicroSD can be recognized/mounted in Custom Recovery.
Click to open

adb shell
adb shell getprop

adb -s XXXXXXXXX shell cat /proc/partitions

adb -s XXXXXXXXX shell ls -l /dev/block

XXXXXXXXX - It's the device serial number.
fastboot devices
XXXXXXXXX

su

cat /proc/partitions

ls -l /dev/block

fdisk -l /dev/block/mmcblk0

fdisk -l /dev/block/mmcblk*

ls -al /dev/block/bootdevice/by-name

df

cat /proc/mounts

fdisk -l /dev/block/mmcblk0p*


cat /proc/mounts
For some informations in the fastboot mode:
fastboot getvar all
For some others informations in the fastbootd mode:
fastboot getvar all
Save all informations in the text file with proper name.


You can use this tool ADB RUN if you not know much.
You can use termux if you want.
III. Get the simple device tree automatically

Use for Linux the twrpdtgen or have onlyne using action_build_twrp_device_tree.
The simple example: android_device_wingtech_WTVIS01
Now we understand that you have the device tree made with your device information. So this will be done from folders and files like:
android_device_brand_devicename
Click to open


prebuilt
-- Image.gz
--  dtb.img


recovery


root
-- init.recovery.mt6xxx.rc


-- Android.mk
-- AndroidProducts.mk
-- BoardConfig.mk
-- device.mk
-- twrp_devicename.mk
-- recovery.fstab
-- vendorsetup.sh  ## deprecated if using A11+


Here you should understand the difference between Custom Recoveries. Some of them still use omni_ to build recovery.img or boot .img and TeamWin uses twrp_ to call the files needed to build recovery.img or boot.img from android 11 onwards. So if you want Custom Recovery on android 10 and under, use omni_ and everything will be fine. Read (specially wiki or development) what each Custom Recovery asks for in its configuration and know what to put.

TWRP A4.4 ~ A10
TWRP A11 ~ A12.1
PBRP
Orange Fox
SHRP
Now before you publish the device tree in the GitHub Repository so maybe you want understand about some flags (setup & configurations that TeamWin source code have). After that so you can understand what we have in the Android.mk; AndroidProducts.mk; device.mk; twrp_device.mk; vendorsetup.sh; primarily in the BoardConfig.mk.

Some references:
TWRP_flag
VARIABLES_HEADER
Some from @rokibhasansagar
USEFUL TWRP RECOVERY FLAGS by ZawZaw
TWRP Flags for BoardConfig.mk by MSF Jarvis
Some flags for BoardConfig.mk by Bodya-Kolibass
Flags for BoardConfig.mk by nemo-nemo
With time and android being updated, some of these flags end up and become deprecated in the TeamWin code.
But the main issue here is that you understand what each flag means and what your device has to be placed in the *.rc files of the device tree.
I'm going to leave a very interesting reading about TWRP that user Идите Лесом - 4pda did in order to understand what TWRP means in Operating System mode/view.
TWRP as a separate OS. Structure, working principles, main components.
End of part 1 of 3


## Custom Recovery for MediaTek devices-II.md

      
    Raw
  

              Custom Recovery for MediaTek devices-II.md
            
          
    part 2 of 3

Understanding if the Custom Recovery device tree for MediaTek devices is good for compiling


This guide continues part 1 of 3

How we know from here the folders and files that Custom Recovery needs to compile have *.mk extensions; *.flag; *.fstab; *.rc to edit and place settings or related information for your device.
Not everything is so automatic and good often. The offer to make a device tree automatically made by a developer or creator is very interesting and easy to use. But understand that the developer does not have their device in their hands and much of the information comes from the device itself.
So keep in mind that what the developer did was help create a basic device tree with general information. Most of them (which are few) can help or hinder the compilation of Custom Recovery.
So let's stick to some of this information.
android_device_brand_devicename

This is a how the people can know about the repository. Example:
android = OS
device = device with that OS
brand = generally from `ro.product.{system;vendor;product;odm;system_ext}.brand=`
devicename = generally from `ro.build.product=` or `ro.product.{system;vendor;product;odm;system_ext}.device=`


prebuilt
This is the folder that should contain the kernel and related files like dtb and dtbo.
Sometimes you can have the kernel with different names like kernel.gz; zImage; Image.gz-dtb; Image.gz or whatever name can be referenced in the BoardConfig.mk file so the source can find the kernel.
In addition, we still have cases of having a subfolder inside the prebuilt folder being prebuilt/dtb/mt6xxx.dtb as a reference to the dtb file, i.e., that is a folder/DIRectory for the dtb file.
It all depends on how you write so that the source finds the related and necessary files.
In case you didn't know, but this part goes to the main location of a recovery.img or boot.img.
We can see that there are more files with the kernel; dtb and dtbo; but these files will be made from information placed in the BoardConfig.mk file lie this:


root@DESKTOP-lopestorm:/mnt/c/projects/MT6771-A11/bootStock-UMIDIGI_BISON.R.E_V1.0_20220524# dir
boot.img-base     boot.img-dtboff         boot.img-kerneloff  boot.img-ramdiskcomp      boot.img-tagsoff
boot.img-board    boot.img-hash           boot.img-oslevel    boot.img-ramdisk.cpio.gz  boot.img-zImage
boot.img-cmdline  boot.img-headerversion  boot.img-osversion  boot.img-ramdiskoff       ramdisk
boot.img-dtb      boot.img-imgtype        boot.img-pagesize   boot.img-secondoff


recovery
This is the folder that should contain the files or and subfolder(s) or and file(s) that put in the ramdisk folder.
As you saw above, the view and internal organization of a recovery.img or boot.img file can contain the main part and ramdisk. So that's where the recovery folder comes in as a reference to put folders, subfolders and files inside in the ramdisk through the root folder. Everything in the root folder will be copied to ramdisk!! So be careful with that.
Example: android_device_brand_devicename/recovery/root/system/ ; android_device_brand_device/recovery/root/vendor/ ; android_device_brand_device/recovery/root/others folders/
This is a bit of a delicate part because you have to understand what you need and what is needed in it.

Starting with android_device_brand_devicename/recovery/root/
In the root folder the device tree can have the correct file(s) mostly as the init.recovery.mt6xxx.rc& init.recovery.usb.rc

-- init.recovery.mt6xxx.rc
Inside this file, there are programming lines that refer to information that may be important to start from the internal storages; start some encryption/decryption service; import some file that has something related to the device; tell you how the structure is done on your device; start vibration or lighting service or service to other stores; etc
It is understood that service is the word given to start to execute something.
-- 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.
In the root folder the device tree can have the correct folders like system; vendor and others folders.

android_device_brand_devicename/recovery/root/system/

Inside this folder we can put some files that can help in something. The system folder can also have subfolders that refer to necessary files. The most common subfolders in the Android 11 are bin, etc and lib64.
Inside the bin subfolder there can be files like any binary file or *.so files to solve problems/issues like vibration, lighting or any relevant or necessary file to solve certain goals like encryption/decryption.
Inside the etc subfolder can have files like fstab.postinstall, task_profile.json, recovery.fstab, twrp.fstab or twrp.flags and or other subfolders like vintf with some files like manifest.xml. These files related to stock ROM/firmware in the system/system/etc/[vintf] and system/system/etc/.
The recovery.fstab, twrp.fstab or twrp.flags files must contain the necessary partitions for mounting, backup and also for Custom Recovery to be able to make the MicroSD block partition (external_sd) and or OTG check and mount (open) this in your internal file manager or external file managers as well as give read and write capability.
The recovery.fstab file can contain all partitions or just some essential partitions. If you take the file from within boot.img or recovery.img, the way it is written may change. That's localized in the ramdisk\system\etc\ of img file.
The twrp.fstab or twrp.flags file must contain the other partitions that are not in recovery.fstab. The way the partitions are written in the twrp.fstab or twrp.flags file must follow the following sequence:
 |  mount point  |   fstype   |   device   |     flags     |

If you can know more about these so read/tranlaste Description of recovery.fstab mount flags from 4pda site; Fstab entries; Partition map or and Device Configuration or search in the internet.
Inside the lib64 subfolder can have files like any binary file or *.so files to solve encryption/decryption and or other subfolders like hw with some files like android.hardware.boot@x.x-impl-x.x-mtkimpl.so. That file you can have in the stock ROM/firmware of vendor/lib64/hw folder and x is the number of related file of the Android version.

android_device_brand_devicename/recovery/root/vendor/

Inside this folder we can put some files that can help in something like ueventd.rc from vendor/ stock ROM. The vendor folder can also have subfolders that refer to necessary files. The most common subfolders are etc and lib64.
Inside the etc subfolder can have subfolders like vintf with some files like manifest.xml or and compatibility_matrix.xml. These files related to stock ROM/firmware in the vendor/etc/vintf.
Inside the lib64 subfolder can have files like any binary file or *.so files and or other subfolders like hw with some files like some *.so files to solve encryption/decryption.
Depending on the type of encryption your mt6xxx device has, the vendor folder may still contain subfolders like app\t6 for trustkernel encryption or thh\ta for microtust encryption or app/mcRegistry for trustonic encryption with the subfolders and related files.
Other subfolders like firmware may still be needed to fix touch screen or improve it or other informations/solutions with drivers/hardware.
Maybe the stock ROM doesn't have the files mentioned above and so your firmware may have Android 10, 9,......
For Android 11 with only boot.img file the device tree should have the first_stage_ramdisk subfolder

android_device_brand_devicename/recovery/root/first_stage_ramdisk/

Inside the first_stage_ramdisk subfolder has files or a unique file like fstab.mt6xxx or and fstab.emmc. These files are inside the stock boot.img file in the ramdisk/first_stage_ramdisk folder\subfolder and is localized to the stock ROM/firmware img file or the device's own Read Back process.


End of part 2 of 3


## Custom Recovery for MediaTek devices-III.md

      
    Raw
  

              Custom Recovery for MediaTek devices-III.md
            
          
    part 3 of 3

Understanding how to compile/build Custom Recovery with Device Tree for MediaTek Devices

How we know from here the files the Custom Recovery needs to compile have *.mk extensions. These files have the ability to give the information to the Custom Recovery source to call certain configurations, directions, particulars and specific parts if necessary for the boot/recovery.img file to be created/compiled correctly. If any information is incorrect/wrong then the source will return with errors and the img file will not be made. But there are also cases where something is missing or it doesn't have any information regarding parts of the device, so the Custom Recovery may be created/compiled wrongly, causing it to not start on the device or there will be failures like bootloop, black screen and even reboot into android system.
Agains, this is a very delicate part because you have to understand what you need and what informations is needed each mk file.
The entire Android system consists of specific files. This depends on correct information and the direction of how it will be built.

Build levels

There are 4 build levels (from large to small):

Architecture  ==>> All devices with the same architecture (armv6, armv7, x86, MIPS);
Board  ==>> All devices with the same chipset and board hardware;
Device [device] ==>> Specific device or devicename;
Product [product] ==>> Modifications of the device, for example, for different countries.

Each specific file is a distinct set of components that can be easily added, removed or replaced in a larger system via modules. Each module is accompanied by a makefile (*.mk). In this case the *.mk file describes how to build specific hardware and/or software files. General example of how it's done and what it's for:
(LOCAL_MODULE := <build_name>) ==>> Module name
(include $(CLEAR_VARS)) ==>> Clearing local variables
(LOCAL_SRC_FILES := main.c) ==>> Source files
(LOCAL_MODULE_TAGS := eng or userdebug) ==>> Tags { in which builds the module will be present. For example, in developer builds only}
(LOCAL_SHARED_LIBRARIES := cutils) ==>> Libraries {which libraries we need}
(include $(BUILD_EXECUTABLE) ==>> Temporary file


android_device_brand_devicename


-- Android.mk  ==>> Overview ----- DEFINITION module ----- How to make a tree for Android mount composition.

In Android.mk file is specified:
 LOCAL_PATH := $(call my-dir)
 ifeq ($(TARGET_DEVICE), devicename)
 include $(call all-subdir-makefiles,$(LOCAL_PATH))
 endif

(call my-dir) ==>> copy the current directory and all included files
(TARGET_DEVICE), devicename ==>> refers to a specific current device.
(LOCAL_PATH) ==>> copy only files from the current directory

-- AndroidProducts.mk

This file only indicates which type of build option in LOCAL_MODULE_TAGS the img will be made according to the desired choice being referenced in the *.img-cmdline file and in the BoadConfig.mk file to generate the prop.default file . The choice of build type or build variants can have "user", "userdebug" or "eng". In AndroidProducts.mk the following is specified:
 PRODUCT_MAKEFILES := \
 $(LOCAL_DIR)/twrp_devicename.mk

 COMMON_LUNCH_CHOICES := twrp_devicename-eng

(LOCAL_DIR) is the way to direct the device tree structure with the scripts/variables/strings of a current directory or diferent directory. Very similar to the same thought by DEVICE_PATH.
COMMON_LUNCH_CHOICES ==>> That is only used for the lunch menu, which only shows up in the local choices for building the img with options as user, eng or userdebug.
The twrp_ is defined from here

-- BoardConfig.mk

Getting here, I hope you have already read the part of RECOVERY FLAGS & VARIABLES and understood some parts that make up the BoardConfig.mk file to make it easier to understand.
I can't highlight all the functions of each flag because it depends on what each device has to offer. But we can focus on the main flags and they can usually be copied without prejudice to different Soc MT6xxx.
How you know the device tree should have very informations about your device as Board; Name; Manufacture; etc
If you can read about New device Board and others strings. Read about CPU architecture; API; and other layers. Use the information for understand the makefiles for your device and product to place correct informations in your device tree. This is usually the file that gets the most information and settings to compile Custom Recovery and if there are any compilation errors, it usually comes from somewhere in this file.
Let's focus on this android_device_wingtech_WTVIS01/BoardConfig.mk (reference of android_device_brand_devicename) file to understand its flags.
Click to open

DEVICE_PATH := device/wingtech/WTVIS01 --->> is the path where the device tree structure has as the main directory with its folders, subfolders and/or files. Very similar to the same thought of LOCAL_PATH.
# Architecture --->> from Supported ABIs. Generally the device can have arm for 32-bits or armv8-a or armv8-2a 64-bits from Target information variables. All this informations is from the stock boot.img unpacked and you can know about reading multilib build.
TARGET_ARCH := arm64
TARGET_ARCH_VARIANT := armv8-a
TARGET_CPU_ABI := arm64-v8a
TARGET_CPU_ABI2 :=
TARGET_CPU_VARIANT := generic

TARGET_2ND_ARCH := arm
TARGET_2ND_ARCH_VARIANT := armv7-a-neon
TARGET_2ND_CPU_ABI := armeabi-v7a
TARGET_2ND_CPU_ABI2 := armeabi
TARGET_2ND_CPU_VARIANT := generic
TARGET_BOARD_SUFFIX := _64
TARGET_USES_64_BIT_BINDER := true

# Assert --->> The name or/and model of device for update/FOTA
TARGET_OTA_ASSERT_DEVICE := WTVIS01
# File systems  --->> Read about File System support, Partitions, Dynamic Partitions and Board configuration changes.
For A12 read about EROFS.
BOARD_HAS_LARGE_FILESYSTEM := true
#BOARD_RECOVERYIMAGE_PARTITION_SIZE := 33554432 # This is the maximum known partition size, but it can be higher, so we just omit it
BOARD_SYSTEMIMAGE_PARTITION_TYPE := ext4
BOARD_USERDATAIMAGE_FILE_SYSTEM_TYPE := ext4
BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := ext4
TARGET_USERIMAGES_USE_EXT4 := true
TARGET_USERIMAGES_USE_F2FS := true
TARGET_COPY_OUT_VENDOR := vendor

TARGET_USERIMAGES_USE_EXT4 -->> This variable needs to be set as true to build a filesystem in ext4 format. Generally all partitions have.
TARGET_USERIMAGES_USE_F2FS -->> This variable needs to be set as true to build a filesystem in f2fs format. Generally only userdata partition have.
TARGET_COPY_OUT_VENDOR -->> Variables we check as OUT_DIR is set to allows you to set it to list of directories. This can be useful if you set OUT_DIR to be a different directory (system_ext; odm; ...) than other outputs of your build system. In short, the folder is created as per the need of the partition.
# A/B
AB_OTA_UPDATER := true
TW_INCLUDE_REPACKTOOLS := true

AB_OTA_UPDATER -->> is reclacioned about Virtual A/B with boot partition containing the recovery's ramdisk.
TW_INCLUDE_REPACKTOOLS -->> Add an GUI button to repack the boot partition with the current TWRP ramdisk. This will remove the need of TWRP .zip installers.
# Kernel
All this informations is from the stock boot.img unpacked and you can know about reading multilib build or you can read about Boot Image Header
BOARD_KERNEL_CMDLINE := bootopt=64S3,32N2,64N2 buildvariant=user
BOARD_KERNEL_CMDLINE += androidboot.force_normal_boot=1  -->> Adc for Android 11 Boot Reason or System-as-root changes.
TARGET_PREBUILT_KERNEL := $(DEVICE_PATH)/prebuilt/Image.gz
TARGET_PREBUILT_DTB := $(DEVICE_PATH)/prebuilt/dtb.img
BOARD_BOOTIMG_HEADER_VERSION := 2
BOARD_KERNEL_BASE := 0x40078000
BOARD_KERNEL_PAGESIZE := 2048
BOARD_RAMDISK_OFFSET := 0x11a88000
BOARD_KERNEL_TAGS_OFFSET := 0x07808000
BOARD_FLASH_BLOCK_SIZE := 131072 # (BOARD_KERNEL_PAGESIZE * 64)
BOARD_MKBOOTIMG_ARGS += --ramdisk_offset $(BOARD_RAMDISK_OFFSET)
BOARD_MKBOOTIMG_ARGS += --tags_offset $(BOARD_KERNEL_TAGS_OFFSET)
BOARD_MKBOOTIMG_ARGS += --dtb $(TARGET_PREBUILT_DTB)
BOARD_MKBOOTIMG_ARGS += --header_version $(BOARD_BOOTIMG_HEADER_VERSION)
BOARD_KERNEL_IMAGE_NAME := Image.gz
TARGET_KERNEL_ARCH := arm64
TARGET_KERNEL_HEADER_ARCH := arm64
#TARGET_KERNEL_SOURCE := kernel/wingtech/WTVIS01  # Use if have device Source Code
#TARGET_KERNEL_CONFIG := WTVIS01_defconfig  # Use if have device Source Code

This part is related to the main structure and prebuilt files.
# Bootloader -->> Add More option of Bootloader
TARGET_BOOTLOADER_BOARD_NAME := mt6765
TARGET_NO_BOOTLOADER := true

# Platform -->> This is located in *.prop and has ro.board.platform=mt6xxxx as the main information. Beware of device information that contains software-related mt6xxxx and hardware-related mt6xxxx. Example: device with mt6762 and mt6765. In this case, Board is software related!
TARGET_BOARD_PLATFORM := mt6765

# Hack: prevent anti rollback -->> This is located in *.prop and has ro.system.build.version.release=android version; ro.build.version.security_patch=yyyy-mm-dd and ro.vendor.build.security_patch=yyyy-mm-dd as main information. But you can modify the time yyyy-mm-dd and android version so that a prevent anti rollback takes effect. Read Rollback protection or AVB includes Rollback Protection too.
PLATFORM_SECURITY_PATCH := 2099-12-31
VENDOR_SECURITY_PATCH := 2099-12-31
PLATFORM_VERSION := 16.1.0

# TWRP Configuration
TW_THEME := portrait_hdpi
TW_EXTRA_LANGUAGES := true
TW_SCREEN_BLANK_ON_BOOT := true
TW_INPUT_BLACKLIST := "hbtp_vm"
TW_USE_TOOLBOX := true

TW_THEME -->> Write according to your device's resolution specification.
TW_SCREEN_BLANK_ON_BOOT -->> This is required at the time you want the double/single touch screen wake to be activated to "wake up"/return the device and redisplay the Custom Recovery options.
TW_INPUT_BLACKLIST -->> This includes or does not include the mouse cursor. So it refers to the use of a mouse. This is used if the touch screen driver does not work.


-- README.md

Any *.md file has the characteristic of informing something related to the device or something particular for anyone who wants to read it. So this file is not directly linked to the img file compilation. Let's say for example that the md file has the same purpose as a txt file.

-- device.mk

This file has the characteristic of functions related to what the device has or in particular linked to the Operating System that inform parts of software or hardware.
Click to open

LOCAL_PATH := device_brand_devicename

# Dynamic Partitions
PRODUCT_USE_DYNAMIC_PARTITIONS := true

# VNDK
PRODUCT_TARGET_VNDK_VERSION := 30

# API
PRODUCT_SHIPPING_API_LEVEL := 30

PRODUCT_PLATFORM := mt6765

# A/B
ENABLE_VIRTUAL_AB := true

AB_OTA_POSTINSTALL_CONFIG += \
    RUN_POSTINSTALL_system=true \
    POSTINSTALL_PATH_system=system/bin/otapreopt_script \
    FILESYSTEM_TYPE_system=ext4 \
    POSTINSTALL_OPTIONAL_system=true

# Boot control HAL
PRODUCT_PACKAGES += \
    android.hardware.boot@1.1-impl-recovery \
    android.hardware.boot@1.1-impl \
    android.hardware.boot@1.1-service

PRODUCT_PACKAGES_DEBUG += \
    update_engine_client

PRODUCT_PACKAGES += \
    otapreopt_script \
    update_engine \
    update_verifier \
    update_engine_sideload
    
PRODUCT_PACKAGES += \
    android.hardware.fastboot@1.0-impl-mock \
    fastbootd

# health Hal
PRODUCT_PACKAGES += \
    android.hardware.health@2.1-impl \
    android.hardware.health@2.1-service \

TW_OVERRIDE_SYSTEM_PROPS := \
    "ro.build.product;ro.build.fingerprint;ro.build.version.incremental;ro.product.device=ro.product.system.device;ro.product.model=ro.product.system.model;ro.product.name=ro.product.system.name"

Some of these have # symbol is not important in compilation. Then they serve to inform something related to the flag or string. Usually comments or relative to what this is intended for. This example above defines a device that has the Custom Recovery structure on the boot partition with slots _a and _b. You can see other example here.
LOCAL_PATH =>> is the path where the device tree structure has as the main directory with its folders, subfolders and/or files. Very similar to the same thought of DEVICE_PATH.
A/B => part referring to devices that have recovery in the boot partition. Called Virtual A/B, it has recovery_ramdisk directly in boot.img and there is no partition for recovery.img.
PRODUCT_PACKAGES =>> adds files relative to the android source code and also, if necessary, to the device source code that are defined by the modules like Virtual AB files.
TW_OVERRIDE_SYSTEM_PROPS =>> Overrides properties of the device according to the build.prop file or another *.prop file.
VNDK & API =>> Android API version.
PRODUCT_USE_DYNAMIC_PARTITIONS.
Boot control HAL implement Virtual A/B necessary files for update with AB_OTA_POSTINSTALL_CONFIG script/process configuration.
fastbootd and enable fastbootd


-- [system or vendor].prop

This file shows the properties that can be located in System, Vendor, Product, Odm, System_ext of the device/company/model that give permission, access, enable, disable any part or set properties in Android, with guidelines able to condition the resources of that device in relation to software and/or hardware.
Click to open

It all depends on the device, what it has and what it can have. Whether to enable something related to encryption/decryption or even touch-screen improvement (haptic).
The properties informations can come from the file that is located in the stock boot.img file inside in the boot/ramdisk/prop.default or in the system.img & vendor.img and can be viewed with any text editor.
The most common lines are:
ro.sf.lcd_density=nnn
ro.mediatek.platform=MT6xxx
ro.hardware=mt6xxx
ro.crypto.volume.filenames_mode=aes-256-cts

Remember about platfom hardware and platform software with the example from BoardConfig.mk /# Platform has software in the TARGET_BOARD_PLATFORM := mt6765. So in this case is hardware in the ro.hardware=mt6762.


-- twrp_devicename.mk

The file organize, call all strings and/or flags of Android source code and build correctly modules and others files. From this device configuration, a product is created with a product definition makefile that declares product-specific information about the device, such as name and model. The following steps describe how to configure the product makefiles and Writing product makefiles.
Click to open

# Inherit from those products. Most specific first.
$(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/base.mk)

# Installs gsi keys into ramdisk, to boot a developer GSI with verified boot.
$(call inherit-product, $(SRC_TARGET_DIR)/product/gsi_keys.mk)

# Virtual A/B OTA
$(call inherit-product, $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)

# Inherit from star device
$(call inherit-product, device/brand/devicename/device.mk)

# Inherit some common recovery stuff.
$(call inherit-product, vendor/twrp/config/common.mk)

# Device identifier. This must come after all inclusions
PRODUCT_DEVICE := DEVICE
PRODUCT_NAME := twrp_NAME
PRODUCT_BRAND := BRAND
PRODUCT_MODEL := MODEL
PRODUCT_MANUFACTURER := MANUFACTURER

Device identifier =>> This information can come from the file that is located in the stock boot.img file inside in the boot/ramdisk/prop.default and can be viewed with any text editor to find and replace with device; name; brand; model and manufacture.
call inherit =>> It is a call to add the function with the related argument. To know what this function has so is need look for its definition. So the inherit-product does that and three more things accordig to file in link.
Virtual A/B OTA
gsi_keys
core_64_bit


The final directory structure of device tree looks like below:

Click to open

android_device_brand_device

├── prebuilt
│   ├── Image.gz
│   └── dtb.img
├── recovery
|   └── root
|       ├── first_stage_ramdisk
|       |   └── fstab.*
|       ├── system
|       |   ├── bin
|       |   |   └── *.so or *.service
|       |   ├── etc
|       |   |   ├── vintf
|       |   |   |   └── manifest.xml
|       |   |   ├── fstab.postinstall
|       |   |   ├── recovery.fstab
|       |   |   ├── task_profile.json
|       |   |   └── twrp.fstab
|       |   └── lib64
|       |        └── hw
|       |            └── *.so
|       ├── vendor
|       |   ├── bin
|       |   |   ├── hw
|       |   |   |   └── *.service
|       |   |   └── *.so
|       |   ├── etc
|       |   |   └── vintf
|       |   |       ├── compatibility_matrix.xml
|       |   |       └── manifest.xml
|       |   ├── lib64
|       |   |   ├── hw
|       |   |   |   └── *.so
|       |   |   └── *.so
|       |   └── ueventd.rc
|       ├── init.recovery.mt6xxx.rc
|       └── init.recovery.usb.rc
├── Android.mk
├── AndroidProducts.mk
├── BoardConfig.mk
├── README.md
├── device.mk
├── [system or vendor].prop
└── twrp_devicename.mk


Last updated on 2023/06/02.

Old updated on 2022/10/23.

Thanks and Notes

^{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 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 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.}
^{Thanks to @SebaUbuntu for twrpdtgen.}
^{How I write in gist: Writing on github}
^{How I compile img file with Action in github: Using online resource to build custom recovery - TeamWin - Fox - SHRP - PBRP}