设备树的ify

在试图为不被官方支持的设备编译ROM（大多数情况下）时，需要自行寻找设备树相关文件。通常多数设备可以在GitHub找到前人的工作（手搓设备树这事不在本文讨论范围内，会搓设备树的dalao也不用看这两篇教程），通常是以android_device_<设备品牌>_<设备代号>命名的仓库。（图片中是小米6X的设备树，仅举例）搜索设备树
不同的类原生ROM通常有不同的定义，因而这些前人的劳动成果可能与你要编译的ROM并不适配，表现为启动编译的过程中各种报错找不到Makefile配置文件定义的模块，这时候就需要修改设备树中的相关Makefile文件以适配当前编译的ROM，这一过程被称为设备树的“ify”过程。
设备树举例
还是以小米6X的设备树为例，原来的设备树适用于PixelExperience，但我想要编译LineageOS，此时就需要对一些文件进行修改。本例中通常需要更改AndroidProduct.mk和aosp_wayne.mk的内容，使之与LineageOS相匹配。修改的目标内容视不同ROM而定，建议参考你要编译的ROM官方支持的设备所公开的设备树。
mk-2

常见的构建类型及其区别

构建类型特性
eng具有额外调试工具的开发配置，默认开放完整的adb调试权限而无需授权，通常在调试设备树时建议使用eng构建
userdebug与“user”类似，但具有 root 权限(通过adb root获取)和调试功能；是首选编译类型
user权限受限；适用于生产环境，使用adb无法获取root权限，官方系统通常是user构建

此外，不同构建类型下构建软件包的配置也会有所不同。
在使用brunch命令直接启动编译流程或使用lunch命令设定编译配置时可以指定构建类型。

以为Redmi K50(rubens)构建LineageOS 21(基于Android 14 QPR3)为例：
命令：brunch lineage_rubens-ap2a-eng
其中lineage_rubens——设备名称
ap2a——构建版本
eng——指定构建类型为eng