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.
For more information, please visit Mt6762 Android Core Board.
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.
There are 4 build levels (from large to small):
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.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.
-- 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 += \
[email protected] \
[email protected] \
[email protected]
PRODUCT_PACKAGES_DEBUG += \
update_engine_client
PRODUCT_PACKAGES += \
otapreopt_script \
update_engine \
update_verifier \
update_engine_sideload
PRODUCT_PACKAGES += \
[email protected] \
fastbootd
# health Hal
PRODUCT_PACKAGES += \
[email protected] \
[email protected] \
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
The company is the world’s best Android ARM Main board supplier. We are your one-stop shop for all needs. Our staff are highly-specialized and will help you find the product you need.
-- [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
├── 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
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
Sorry, we just need to make sure you're not a robot. For best results, please make sure your browser is accepting cookies.
Are you interested in learning more about Allwinner SBC for Intelligent Transportation? Contact us today to secure an expert consultation!