MTK-Android13-实现拷贝预置资源到vendor分区下

预置文件到 /vendor/lib 目录下、预置文件到/vendor/etc 目录下 、预置文件到/vendor/lib/hw 文件目录下

---

前言 - 需求

     集成一个遥控器语音方案到系统，实现语音控制大屏设备的功能。 其中设计到把 .so 和 .xml 分别内置拷贝到 机器的 /vendor/lib 、/vendor/lib/hw 、 vendor/etc目录下。

先看看需求和实际效果吧：借助一个需求来总结 拷贝资源到 /vendor/lib 目录下的知识点。

所以，系统要做的事情，就是内置资源到指定的目录下。

---

一、参考资料

拷贝文件到系统目录出现错误error: found ELF prebuilt in PRODUCT_COPY_FILES

假设对MTK 平台有一定属性或者不太熟悉，之前总结过的知识点可以参考下：

Android 系统属性添加篇
MTK-Android 系统拷贝预置资源 里面有copy 可执行文件到 指定目录

之前知识点列举出来，主要就是为了有一个思路： 在 mtk 平台内置 .so 、资源文件 、可执行文件 基本上都两个思路：

• 配置模块，在模块.mk 文件里面实现功能
• 基于.mk 文件里面配置，里面 PRODUCT_COPY_FILES 来实现

二、实现方案

修改文件如下：

\device\mediateksample\k69v1_64_k419\BoardConfig.mk
\device\mediateksample\k69v1_64_k419\device.mk

修改内容分别如下：
在 BoardConfig.mk 文件中添加一行配置如下:

BUILD_BROKEN_ELF_PREBUILT_PRODUCT_COPY_FILES := true

在 device.mk 配置文件中添加拷贝脚本，如下：

# custom wfc googlevoice
PRODUCT_COPY_FILES += $(LOCAL_PATH)/zhixianble_audio_policy_configuration.xml:$(TARGET_COPY_OUT_VENDOR)/etc/zhixianble_audio_policy_configuration.xml:mtkPRODUCT_COPY_FILES += $(LOCAL_PATH)/fise/audio.zhixianble.default.so:$(TARGET_COPY_OUT_VENDOR)/lib/hw/audio.zhixianble.default.so
PRODUCT_COPY_FILES += $(LOCAL_PATH)/fise/libzhixian_audio_sdk.so:$(TARGET_COPY_OUT_VENDOR)/lib/libzhixian_audio_sdk.so

按照以上配置，即可实现拷贝资源文件到 /vendor 目录下的对应的目录下，实现内置资源功能。

三、MTK平台相关知识点

mediateksample 目录介绍

     MTK平台中的mediateksample目录是设备配置和项目特定文件的存储位置，主要用于定制和配置基于联发科(MTK)芯片组的特定设备项目。这个目录是Android开源项目(AOSP)中device目录下的一个重要组成部分。

     为了让你快速了解mediateksample目录的主要内容，我用一个表格来汇总：

组成部分	描述	示例/备注
项目特定目录	以项目名命名（如k6833v1_64），包含该设备的所有特定配置和代码。	项目名通常反映芯片型号和特性（如k65v1_64_bsp可能对应MT6765芯片平台）
ProjectConfig.mk	核心配置文件，定义了设备的各类宏和开关。	可在此文件里配置内核版本、功能模块（如摄像头、传感器）、分区大小等
AndroidBoard.mk	指导编译系统如何编译和处理设备树、内核等板级相关文件。
设备树文件 (.dts)	描述硬件组件和连接关系，位于项目目录或链接到内核目录。	设备树源文件(.dts)最终会被编译成设备树 blob(.dtb)供内核使用。
vendorsetup.sh	将设备的编译产品名称添加到Lunch菜单中，便于选择编译目标。

核心作用

     mediateksample目录的核心作用在于隔离不同项目的配置差异，实现同一个代码库支持多个不同的硬件设备项目。每个项目都有自己的子目录（例如 k6833v1_641, spm8666p1_64_car2），里面包含了该设备特定的配置、内核选项、设备树文件、启动引导配置等。

     在MTK的编译系统中，当你选择特定的项目（或称为“午餐组合”）进行编译时，编译系统会定位到mediateksample下对应的项目目录，读取其中的配置（特别是ProjectConfig.mk）来定制化整个系统镜像的生成过程。这包括：

• 指定内核版本：如 LINUX_KERNEL_VERSION = kernel-4.141
• 指定内核配置和设备树：确保使用正确的defconfig和.dts文件来描述硬件。
• 包含项目特定的模块和覆盖：将设备特有的驱动、库或应用集成到最终镜像中

开发操作

     在开发过程中，如果需要创建一个新的设备项目，通常会在mediateksample目录下复制一个已有的类似项目目录，然后进行修改。这个过程可能涉及
在 mediateksample 下创建新的项目目录。

• 修改新目录中的 ProjectConfig.mk 及其他配置文件。
• 可能需要在内核源码中为新项目添加对应的设备树文件(.dts)和配置(defconfig)。
• 修改新项目目录下的 AndroidProducts.mk 等文件以注册新产品。
• 通过 lunch 命令选择新创建的项目进行编译。

注意事项

• 样本与实际项目： mediateksample 中的 sample 意味着它通常包含参考实现或示例配置。实际量产项目的目录名称可能与此不同，或者其具体配置会因产品定义而异。

• 版本差异： MTK不同平台（如Android 9.0, 11, 12等）和不同芯片组（如MT6762, MT6765, MT6833等）的mediateksample目录结构或配置文件细节可能存在差异，需参考MTK提供的对应平台文档。

• 与vendor/mediatek/proprietary的关系： mediateksample目录通常包含更偏向于设备硬件抽象层(HAL)适配、内核配置、系统构建相关的配置。而一些MTK闭源的库、驱动、框架修改、以及更底层的芯片相关配置，往往放在vendor/mediatek/proprietary目录下。两者需要配合工作。

总结

     mediateksample目录是MTK平台设备开发的起点和核心配置所在地，它将AOSP通用代码与MTK芯片特性以及具体设备的硬件配置连接起来。通过这个目录下的文件，开发者可以高效地定制和构建出针对特定硬件设备的Android系统镜像。

BUILD_BROKEN_ELF_PREBUILT_PRODUCT_COPY_FILES 配置

     为什么要学习、了解这个知识点？ 因为在实际.mk 文件里面配置的时候， 涉及到.so 拷贝的时候，总是报错，不允许拷贝 可执行文件、.so 文件的。 配置它等于true,就绕开系统检查。
报错：error: found ELF prebuilt in PRODUCT_COPY_FILES 参考资料：拷贝文件到系统目录出现错误error: found ELF prebuilt in PRODUCT_COPY_FILES

     简单来说，BUILD_BROKEN_ELF_PREBUILT_PRODUCT_COPY_FILES := true 这个配置的作用是：禁用构建系统对预编译的 ELF 文件（主要是 .so 动态库文件）的一项严格检查，从而允许某些本来会导致构建失败的预编译库被复制到最终的系统镜像中。

核心概念解析

• BUILD_BROKEN_...:在 AOSP 的构建系统中，以BUILD_BROKEN_开头的标志通常用于禁用某些严格的检查或错误。它们本质上是“逃生舱口”，允许开发者绕过一些导致构建失败的限制，但代价是可能会引入潜在的风险或问题。BROKEN 这个词暗示这个选项可能会让构建处于一种“不完美”或“有风险”的状态。

• ELF_PREBUILT: 指的是预编译的 ELF 文件。在 Android 上下文中，这绝大多数情况指的是第三方提供的、已经编译好的 .so（共享对象/动态链接库）文件，而不是从 AOSP 源代码直接编译出来的。

• PRODUCT_COPY_FILES: 这是 Android 构建系统中一个非常重要的机制。它是一个列表，定义了哪些文件需要从源代码树中的路径复制到最终设备镜像中的对应路径。例如，将vendor/acme/lib/libfoo.so复制到 system/lib64/libfoo.so。

总结

配置项	作用	风险
BUILD_BROKEN_ELF_PREBUILT_PRODUCT_COPY_FILES := true	禁用对预编译 ELF 文件（.so）的 DT_NEEDED 和 DT_RUNPATH 一致性检查，允许构建继续。	可能将运行时才会暴露的库依赖错误隐藏起来，导致系统在运行时发生崩溃。

一句话概括：它是一个让构建系统“睁一只眼闭一只眼”，放过某些有潜在风险的预编译库的开关，用于在开发阶段绕过依赖检查错误，但应谨慎使用。

目录k69v1_64_k419和目录k65v1_64_bsp 及mediateksample 下其它目录

认识 k69v1_64_k419 和 k65v1_64_bsp 知识点前 务必先了解 mediateksample 目录介绍 ，先看 mediateksample 目录，也就务必知道它有哪些功能，做什么的：

说白了，就是下面有很多文件夹，看起来像工程目录一样。

举例说明k65v1_64_bsp 目录

     MTK平台的 k65v1_64_bsp是一个项目代号（或工程代号），主要用于标识基于联发科（MediaTek）MT6765芯片的特定硬件开发板或智能设备解决方案。下面我用一个表格帮你梳理它的可能组成部分和含义：

组成部分	可能含义与解释	备注与参考
k65	很可能指代所采用的主芯片型号，即MTK的MT6765平台347。这是一个面向4G智能手机或智能设备的ARM SoC。	MT6765芯片代号有时会简写或变形，例如“k65”可能源自“MT6765”中的“65”。
v1	通常代表版本号（Version 1），表明这是该平台或开发板的第一个主要版本或初始修订版。	后续版本可能会出现 v2, v3 等。
64	明确指示该项目采用的是64位（64-bit） 的ARM处理器架构34。	MT6765芯片本身集成了8个ARM Cortex-A53内核（64位架构） 。
bsp	通常代表板级支持包（Board Support Package）。	这表明该代码库或设备树文件是为特定开发板或硬件定制的基础软件包，包含启动代码、驱动等。

举例k65v1_64_bsp 综合解读

k65v1_64_bsp 这个代号很可能指的是基于联发科MT6765芯片（64位架构）的第一个版本的开发板或智能设备解决方案的板级支持包。

• 你可以在编译Android系统（如Android 9.0）时看到它，用于标识特定的目标设备 。

• 它也用于标识内核（kernel）编译的目标平台以及相关的设备树文件（.dts） 。

• 这个代号还会出现在提供的配置工具（如DCT工具） 中，用于生成或修改该特定平台的配置文件（如GPIO、I2C等）

知识点主要目的

• 首先要搞清楚自己项目对应的是mediateksample 目录下的哪一个工程，找到对应的修改文件进行修改或添加卑职

四、功能实现背后的神坑

下面列举自己在实现 vendor/lib 目录下内置资源配置的几个坑点，

• 坑点一： 如上，在 device.mk 里面配置 挥汗如雨… ，如上 BUILD_BROKEN_ELF_PREBUILT_PRODUCT_COPY_FILES 错误阻塞，.so 文件始终无法编译到系统里面去，编译失败。
• 坑点二： 在device.mk 用 命令"cp " 来进行拷贝，不报错，但是实际拷贝失败
• 坑点三: 以模块形式，添加模块的.mk 编译 到系统里面去，编译成功，但是实际没有效果，实际拷贝失败
• 坑点四： mediateksample 目录下的哪一个工程搞错，知道在对应的工程目录下修改配置，添加等，但是搞不清楚或者搞错对应的工程，特别是一套源码配置了多个平台，搞混了，结果修改错误的文件，导致无效。
  针对第四点给出建议：查看编译日志，编译日志上面都有显示的，如下：
  

总结

• 实现拷贝资源文件到/vendor/目录下的某个目录
• 通过实现需求，了解了很多知识点，在mtk 平台上面开发特别重要的。 希望后面少踩坑。