connectedhomeip 仓库 Android 第三方依赖管理指南chipDeps、set_up_android_deps.py 与 GN 构建目标生成【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip导读本文面向在 Matterconnectedhomeip仓库中开发 Android 应用的工程师系统讲解该仓库如何管理 Android 第三方依赖从在 Gradle 中声明chipDeps依赖、通过set_up_android_deps.py一键下载 JAR 并生成 GN 构建目标到最终在应用BUILD.gn中引用依赖的完整链路。读完本文你将掌握为仓库新增一个 Android 依赖的标准操作流程并理解其背后 Gradle 解析 Groovy 任务生成 GN 编译消费 的双构建系统衔接原理。一、目录职责一个目录、两套构建体系的桥梁third_party/android_deps/是 connectedhomeip 中专门用于管理 Android 第三方依赖的目录。其设计目标是解决一个核心矛盾Matter 的整体构建基于 GN.gn/.gni文件而 Android 依赖的解析与下载天然属于 Gradle 生态。该目录通过一套定制脚本把两者衔接起来。目录内各文件职责如下文件职责third_party/android_deps/README.md使用说明本文所依据的官方文档third_party/android_deps/android_deps.gradle定义chipDeps配置及依赖声明被build.gradle引入实现配置共享third_party/android_deps/build.gradle定义setUpAndroidDepsGnBuildGenerator类型与copyArtifacts两个 Gradle 任务third_party/android_deps/set_up_android_deps.py一键入口脚本调用 Gradle 任务生成BUILD.gn随后用gn format统一格式third_party/android_deps/buildSrc/src/main/groovy/GnBuildGenerator.groovy核心生成器解析chipDeps依赖树输出java_prebuilt目标third_party/android_deps/BUILD.gn自动生成的 GN 构建目标文件需提交入库third_party/android_deps/artifacts/下载的 JAR 二进制目录禁止入库third_party/android_deps/gradlew/gradlew.bat/gradle/wrapper/Gradle Wrapper固定构建所用 Gradle 版本当前为 Gradle 8.7见gradle/wrapper/gradle-wrapper.properties二、添加新依赖的标准流程根据 README.md 的官方说明为仓库新增一个 Android 依赖只需三步。2.1 第一步在chipDeps配置中声明依赖编辑 third_party/android_deps/android_deps.gradle在dependencies块中为chipDeps配置添加依赖。该文件当前内容如下// This file is kept separate from build.gradle, so that the chipDeps configuration it defines can be shared. apply plugin: base repositories { google() mavenCentral() } configurations { chipDeps } dependencies { chipDeps androidx.annotation:annotation:1.1.0 }要点说明仓库源依赖从google()与mavenCentral()两个 Maven 仓库解析覆盖了 AndroidX 官方库与 Maven Central 上的绝大多数开源 JARchipDeps命名该配置是一个自定义 Gradle configuration仅用于收集需要转译为 GN 目标的依赖与应用自身的implementation/api配置完全解耦当前示例仓库默认依赖androidx.annotation:annotation:1.1.0即 AndroidX 注解库为 Android 侧代码提供NonNull、Nullable等注解支持文件拆分原因注释中明确指出该文件与build.gradle分离是为了让chipDeps配置可以被共享被build.gradle通过apply from: android_deps.gradle引入。新增依赖时按group:name:version格式追加即可例如chipDeps com.google.code.gson:gson:2.10.1。2.2 第二步运行一键脚本在仓库根目录执行./set_up_android_deps.py该脚本完成两件事见 third_party/android_deps/set_up_android_deps.py调用 Gradle Wrapper 执行setUpAndroidDeps任务对生成的BUILD.gn执行gn format规范化格式。脚本实现细节源码级说明def main(): chip_root os.getenv(PW_PROJECT_ROOT) android_deps_dir os.path.join(chip_root, third_party/android_deps) gradlew gradlew if sys.platform ! win32 else gradlew.bat gradle_executable os.path.join(android_deps_dir, gradlew) subprocess.check_call( [gradle_executable, -p, android_deps_dir, setUpAndroidDeps]) subprocess.check_call( [gn, format, os.path.join(android_deps_dir, BUILD.gn)])值得注意的运行前提脚本通过环境变量PW_PROJECT_ROOT定位仓库根目录——这是 Pigweed 环境变量体系的一部分意味着通常需要在已激活的 Matter 构建环境中运行跨平台友好Windows 上自动切换为gradlew.bat其余平台使用gradlew脚本依赖系统中存在gn命令位于 PATH用于最后一步格式化。2.3 第三步在应用代码中引用生成的目标依赖下载完成后JAR 落入artifacts/目录GN 目标写入BUILD.gn。应用代码通过以下形式引用deps [ ${chip_root}/third_party/android_deps:my_dep, ]目标命名规则GN 目标名由 Gradle 依赖名自动推导。官方示例中androidx.annotation:annotation:1.1.0生成的构建目标名为annotation。推导依据是 Gradle 依赖坐标的 artifact 部分即三段坐标group:name:version中的name。当前仓库自动生成的 BUILD.gn 内容如下# This BUILD file is auto-generated, modify the GnBuildGenerator task instead of editing this file manually. import(//build_overrides/chip.gni) import(${chip_root}/build/chip/java/rules.gni) java_prebuilt(annotation) { jar_path artifacts/annotation-1.1.0.jar }文件中java_prebuilt来自${chip_root}/build/chip/java/rules.gni中定义的 Chip Java 构建规则其jar_path指向相对本目录的下载产物。2.4 实际消费示例仓库中的真实引用annotation目标已在仓库中被实际消费可在以下两个文件中找到引用src/app/server/java/BUILD.gn#L58${chip_root}/third_party/android_deps:annotationsrc/platform/android/BUILD.gn#L127${chip_root}/third_party/android_deps:annotation这表明annotation目标服务于 Matter 的 Android 服务器app server与平台层代码是验证声明 → 下载 → 生成 → 消费闭环的真实用例新增依赖时可参照这两个位置补全deps。三、提交与忽略策略哪些该入库哪些不该入库README 明确给出两条版本管理纪律BUILD.gn必须提交入库因为它是构建入口开发者需要追踪依赖最终指向哪里即每个依赖对应哪个 JAR 文件提交后所有开发者无需重新运行生成脚本即可构建artifacts/禁止提交该目录存放的是 JAR 二进制文件体积大且可由脚本随时重新下载属于典型的构建产物。这一策略与build.gradle中的clean任务相互呼应clean { delete artifacts }即执行 Gradleclean时会清空artifacts/进一步确认其可再生产物的定位。四、底层原理GnBuildGenerator 如何把 Gradle 依赖树变成 GN 目标setUpAndroidDeps任务的类型是 GnBuildGenerator.groovy位于 Gradle 的buildSrc中随仓库编译这是整个机制的核心。其工作流如下。4.1 Gradle 任务编排build.gradlethird_party/android_deps/build.gradle 中定义了两个任务及其依赖关系apply plugin: base apply from: android_deps.gradle task setUpAndroidDeps(type: GnBuildGenerator) {} task copyArtifacts(type: Copy) { // Defined in android_deps.gradle from configurations.chipDeps into artifacts } clean { delete artifacts } setUpAndroidDeps.dependsOn copyArtifactscopyArtifacts把chipDeps配置解析出的所有 JAR 拷贝到artifacts/目录setUpAndroidDeps执行GnBuildGenerator且依赖copyArtifacts保证先有 JAR 再生成BUILD.gn。4.2 依赖树遍历与目标生成生成器通过 Gradle 的解析 API 获得依赖图firstLevelModuleDependencies及其children随后对每个模块输出一个java_prebuilt目标chipDepsConfiguration.resolvedConfiguration.firstLevelModuleDependencies.each { allDeps it it.children.each { allDeps it } } allDeps.each { def artifact it.moduleArtifacts[0] // ... 校验逻辑 ... stringBuilder.append(java_prebuilt(\$it.module.id.name\) {\n) stringBuilder.append( jar_path \$COPIED_ARTIFACTS_DIR/${artifact.file.name}\\n) // ... }值得强调的工程细节传递依赖自动展开不仅处理一级依赖还递归收集所有子依赖children因此声明的库若带有传递依赖也会一并生成 GN 目标传递依赖的deps关联子依赖会以deps [:子依赖名]的形式挂到父目标上保持依赖图在 GN 侧同样完整严格的产物校验若某个模块产生多个顶层产物moduleArtifacts.size() 1或产物扩展名不是jar生成器会抛出IllegalStateException终止任务。这限制了当前方案仅支持单 JAR 形式的库——AAR 或其他打包形式不在支持范围内头部自动生成生成的BUILD.gn自动拼接copyright_header.txt的版权头与GENERATED_WARNING警告行警告明确要求修改生成逻辑而非手工编辑BUILD.gn。4.3 目标命名的一致性GN 目标名取自it.module.id.nameGradle 模块坐标的 name 部分与 README 所述 androidx.annotation:annotation:1.1.0 变为 annotation 完全一致也与生成的BUILD.gn中java_prebuilt(annotation)相互印证。五、常见问题与操作注意事项基于源码可以总结出以下实操注意点环境变量缺失导致脚本失败set_up_android_deps.py依赖PW_PROJECT_ROOT定位仓库根目录建议在 Matter 开发环境如执行过scripts/activate.sh的 shell中运行不支持 AAR 依赖生成器的校验逻辑只接受单一jar产物。AndroidX 中的 UI 组件库如androidx.appcompat、androidx.recyclerview通常以 AAR 发布不适用于此流程需要引入 AAR 时应考虑其他方案如build/chip/java/rules.gni中的既有规则或在仓库中另行处理生成结果需复审后提交运行脚本后应git diff检查BUILD.gn变化确认目标名、jar_path与预期一致再提交入库artifacts/不要手动提交若误提交可通过clean任务清理后再行处理注意仓库为只读研究环境此处仅描述常规开发流程Gradle 版本固定项目通过 gradle/wrapper/gradle-wrapper.properties 锁定 Gradle 8.7首次运行 Wrapper 会自动下载对应发行版。六、小结connectedhomeip 通过third_party/android_deps/实现了用 Gradle 声明与解析、用 GN 编译与链接的混合依赖管理模式开发者只需在android_deps.gradle中追加一行chipDeps声明运行./set_up_android_deps.py即可自动完成 JAR 下载与BUILD.gn目标生成随后在任意应用目标的deps中以${chip_root}/third_party/android_deps:name形式引用。这套流程的核心价值在于把第三方 Android 依赖的版本管理收敛到一处 Gradle 文件同时把构建产物JAR与构建描述GN 目标严格区分提交策略兼顾了依赖可追踪性与仓库清洁度是理解 Matter Android 构建链路的必读入口。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 connectedhomeip 仓库 Android 第三方依赖管理指南：chipDeps、set_up_android_deps.py 与 GN 构建目标生成
connectedhomeip 仓库 Android 第三方依赖管理指南chipDeps、set_up_android_deps.py 与 GN 构建目标生成【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip导读本文面向在 Matterconnectedhomeip仓库中开发 Android 应用的工程师系统讲解该仓库如何管理 Android 第三方依赖从在 Gradle 中声明chipDeps依赖、通过set_up_android_deps.py一键下载 JAR 并生成 GN 构建目标到最终在应用BUILD.gn中引用依赖的完整链路。读完本文你将掌握为仓库新增一个 Android 依赖的标准操作流程并理解其背后 Gradle 解析 Groovy 任务生成 GN 编译消费 的双构建系统衔接原理。一、目录职责一个目录、两套构建体系的桥梁third_party/android_deps/是 connectedhomeip 中专门用于管理 Android 第三方依赖的目录。其设计目标是解决一个核心矛盾Matter 的整体构建基于 GN.gn/.gni文件而 Android 依赖的解析与下载天然属于 Gradle 生态。该目录通过一套定制脚本把两者衔接起来。目录内各文件职责如下文件职责third_party/android_deps/README.md使用说明本文所依据的官方文档third_party/android_deps/android_deps.gradle定义chipDeps配置及依赖声明被build.gradle引入实现配置共享third_party/android_deps/build.gradle定义setUpAndroidDepsGnBuildGenerator类型与copyArtifacts两个 Gradle 任务third_party/android_deps/set_up_android_deps.py一键入口脚本调用 Gradle 任务生成BUILD.gn随后用gn format统一格式third_party/android_deps/buildSrc/src/main/groovy/GnBuildGenerator.groovy核心生成器解析chipDeps依赖树输出java_prebuilt目标third_party/android_deps/BUILD.gn自动生成的 GN 构建目标文件需提交入库third_party/android_deps/artifacts/下载的 JAR 二进制目录禁止入库third_party/android_deps/gradlew/gradlew.bat/gradle/wrapper/Gradle Wrapper固定构建所用 Gradle 版本当前为 Gradle 8.7见gradle/wrapper/gradle-wrapper.properties二、添加新依赖的标准流程根据 README.md 的官方说明为仓库新增一个 Android 依赖只需三步。2.1 第一步在chipDeps配置中声明依赖编辑 third_party/android_deps/android_deps.gradle在dependencies块中为chipDeps配置添加依赖。该文件当前内容如下// This file is kept separate from build.gradle, so that the chipDeps configuration it defines can be shared. apply plugin: base repositories { google() mavenCentral() } configurations { chipDeps } dependencies { chipDeps androidx.annotation:annotation:1.1.0 }要点说明仓库源依赖从google()与mavenCentral()两个 Maven 仓库解析覆盖了 AndroidX 官方库与 Maven Central 上的绝大多数开源 JARchipDeps命名该配置是一个自定义 Gradle configuration仅用于收集需要转译为 GN 目标的依赖与应用自身的implementation/api配置完全解耦当前示例仓库默认依赖androidx.annotation:annotation:1.1.0即 AndroidX 注解库为 Android 侧代码提供NonNull、Nullable等注解支持文件拆分原因注释中明确指出该文件与build.gradle分离是为了让chipDeps配置可以被共享被build.gradle通过apply from: android_deps.gradle引入。新增依赖时按group:name:version格式追加即可例如chipDeps com.google.code.gson:gson:2.10.1。2.2 第二步运行一键脚本在仓库根目录执行./set_up_android_deps.py该脚本完成两件事见 third_party/android_deps/set_up_android_deps.py调用 Gradle Wrapper 执行setUpAndroidDeps任务对生成的BUILD.gn执行gn format规范化格式。脚本实现细节源码级说明def main(): chip_root os.getenv(PW_PROJECT_ROOT) android_deps_dir os.path.join(chip_root, third_party/android_deps) gradlew gradlew if sys.platform ! win32 else gradlew.bat gradle_executable os.path.join(android_deps_dir, gradlew) subprocess.check_call( [gradle_executable, -p, android_deps_dir, setUpAndroidDeps]) subprocess.check_call( [gn, format, os.path.join(android_deps_dir, BUILD.gn)])值得注意的运行前提脚本通过环境变量PW_PROJECT_ROOT定位仓库根目录——这是 Pigweed 环境变量体系的一部分意味着通常需要在已激活的 Matter 构建环境中运行跨平台友好Windows 上自动切换为gradlew.bat其余平台使用gradlew脚本依赖系统中存在gn命令位于 PATH用于最后一步格式化。2.3 第三步在应用代码中引用生成的目标依赖下载完成后JAR 落入artifacts/目录GN 目标写入BUILD.gn。应用代码通过以下形式引用deps [ ${chip_root}/third_party/android_deps:my_dep, ]目标命名规则GN 目标名由 Gradle 依赖名自动推导。官方示例中androidx.annotation:annotation:1.1.0生成的构建目标名为annotation。推导依据是 Gradle 依赖坐标的 artifact 部分即三段坐标group:name:version中的name。当前仓库自动生成的 BUILD.gn 内容如下# This BUILD file is auto-generated, modify the GnBuildGenerator task instead of editing this file manually. import(//build_overrides/chip.gni) import(${chip_root}/build/chip/java/rules.gni) java_prebuilt(annotation) { jar_path artifacts/annotation-1.1.0.jar }文件中java_prebuilt来自${chip_root}/build/chip/java/rules.gni中定义的 Chip Java 构建规则其jar_path指向相对本目录的下载产物。2.4 实际消费示例仓库中的真实引用annotation目标已在仓库中被实际消费可在以下两个文件中找到引用src/app/server/java/BUILD.gn#L58${chip_root}/third_party/android_deps:annotationsrc/platform/android/BUILD.gn#L127${chip_root}/third_party/android_deps:annotation这表明annotation目标服务于 Matter 的 Android 服务器app server与平台层代码是验证声明 → 下载 → 生成 → 消费闭环的真实用例新增依赖时可参照这两个位置补全deps。三、提交与忽略策略哪些该入库哪些不该入库README 明确给出两条版本管理纪律BUILD.gn必须提交入库因为它是构建入口开发者需要追踪依赖最终指向哪里即每个依赖对应哪个 JAR 文件提交后所有开发者无需重新运行生成脚本即可构建artifacts/禁止提交该目录存放的是 JAR 二进制文件体积大且可由脚本随时重新下载属于典型的构建产物。这一策略与build.gradle中的clean任务相互呼应clean { delete artifacts }即执行 Gradleclean时会清空artifacts/进一步确认其可再生产物的定位。四、底层原理GnBuildGenerator 如何把 Gradle 依赖树变成 GN 目标setUpAndroidDeps任务的类型是 GnBuildGenerator.groovy位于 Gradle 的buildSrc中随仓库编译这是整个机制的核心。其工作流如下。4.1 Gradle 任务编排build.gradlethird_party/android_deps/build.gradle 中定义了两个任务及其依赖关系apply plugin: base apply from: android_deps.gradle task setUpAndroidDeps(type: GnBuildGenerator) {} task copyArtifacts(type: Copy) { // Defined in android_deps.gradle from configurations.chipDeps into artifacts } clean { delete artifacts } setUpAndroidDeps.dependsOn copyArtifactscopyArtifacts把chipDeps配置解析出的所有 JAR 拷贝到artifacts/目录setUpAndroidDeps执行GnBuildGenerator且依赖copyArtifacts保证先有 JAR 再生成BUILD.gn。4.2 依赖树遍历与目标生成生成器通过 Gradle 的解析 API 获得依赖图firstLevelModuleDependencies及其children随后对每个模块输出一个java_prebuilt目标chipDepsConfiguration.resolvedConfiguration.firstLevelModuleDependencies.each { allDeps it it.children.each { allDeps it } } allDeps.each { def artifact it.moduleArtifacts[0] // ... 校验逻辑 ... stringBuilder.append(java_prebuilt(\$it.module.id.name\) {\n) stringBuilder.append( jar_path \$COPIED_ARTIFACTS_DIR/${artifact.file.name}\\n) // ... }值得强调的工程细节传递依赖自动展开不仅处理一级依赖还递归收集所有子依赖children因此声明的库若带有传递依赖也会一并生成 GN 目标传递依赖的deps关联子依赖会以deps [:子依赖名]的形式挂到父目标上保持依赖图在 GN 侧同样完整严格的产物校验若某个模块产生多个顶层产物moduleArtifacts.size() 1或产物扩展名不是jar生成器会抛出IllegalStateException终止任务。这限制了当前方案仅支持单 JAR 形式的库——AAR 或其他打包形式不在支持范围内头部自动生成生成的BUILD.gn自动拼接copyright_header.txt的版权头与GENERATED_WARNING警告行警告明确要求修改生成逻辑而非手工编辑BUILD.gn。4.3 目标命名的一致性GN 目标名取自it.module.id.nameGradle 模块坐标的 name 部分与 README 所述 androidx.annotation:annotation:1.1.0 变为 annotation 完全一致也与生成的BUILD.gn中java_prebuilt(annotation)相互印证。五、常见问题与操作注意事项基于源码可以总结出以下实操注意点环境变量缺失导致脚本失败set_up_android_deps.py依赖PW_PROJECT_ROOT定位仓库根目录建议在 Matter 开发环境如执行过scripts/activate.sh的 shell中运行不支持 AAR 依赖生成器的校验逻辑只接受单一jar产物。AndroidX 中的 UI 组件库如androidx.appcompat、androidx.recyclerview通常以 AAR 发布不适用于此流程需要引入 AAR 时应考虑其他方案如build/chip/java/rules.gni中的既有规则或在仓库中另行处理生成结果需复审后提交运行脚本后应git diff检查BUILD.gn变化确认目标名、jar_path与预期一致再提交入库artifacts/不要手动提交若误提交可通过clean任务清理后再行处理注意仓库为只读研究环境此处仅描述常规开发流程Gradle 版本固定项目通过 gradle/wrapper/gradle-wrapper.properties 锁定 Gradle 8.7首次运行 Wrapper 会自动下载对应发行版。六、小结connectedhomeip 通过third_party/android_deps/实现了用 Gradle 声明与解析、用 GN 编译与链接的混合依赖管理模式开发者只需在android_deps.gradle中追加一行chipDeps声明运行./set_up_android_deps.py即可自动完成 JAR 下载与BUILD.gn目标生成随后在任意应用目标的deps中以${chip_root}/third_party/android_deps:name形式引用。这套流程的核心价值在于把第三方 Android 依赖的版本管理收敛到一处 Gradle 文件同时把构建产物JAR与构建描述GN 目标严格区分提交策略兼顾了依赖可追踪性与仓库清洁度是理解 Matter Android 构建链路的必读入口。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考