在 Android 模拟器中运行 Matter Java 控制器层测试connectedhomeip 的 Android Emulator Tests 实操指南【免费下载链接】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本文以 src/controller/java/tests/README.md 为骨架讲解 Matter原 Project CHIPconnectedhomeip 仓库Android 控制器层单元测试的运行方式为什么这些测试“必须在外部运行”、如何搭建 Android SDK/NDK 环境、如何用构建脚本产出 CHIPTest 测试应用、如何通过gradle.properties切换被测测试库并结合测试源码剖析 JNI 回调测试与 TLV 编解码测试各自依赖什么运行环境。读完本文你能够独立完成一套“从源码编译 → 模拟器安装 → 运行控制器层单测”的完整流程。一、文档核心约定这些测试必须在外部运行README.md 的内容虽然简短但它确立了一个关键约束These tests must be run externally构建与模拟器配置请参见 Building Android 指南。结合仓库结构可以这样理解这句话src/controller/java/下的 Java/Kotlin 控制器代码设备控制器、TLV 编解码、JSON-TLV 转换、Onboarding Payload 解析等并不是一个独立的 Android 工程它编译后以测试库的形式被注入到examples/android/CHIPTest这个 Android 测试应用中。因此测试无法像 JVM 下的纯单元测试那样在裸主机上直接gradlew test完成全部验证——涉及 JNI 的测试用例需要真实加载 native 库必须借助 Android 模拟器或真机外部执行。测试目录结构被测代码与测试用例的对应关系src/controller/java/tests/目录按被测包名镜像组织当前包含两组测试src/controller/java/tests/chip/devicecontroller/GetConnectedDeviceCallbackJniTest.java验证设备连接回调的 JNI 桥接cluster/ChipClusterEventStructTest.kt、cluster/ChipClusterStructTest.kt集群事件结构与数据结构的构造测试src/controller/java/tests/matter/tlv/TlvReaderTest.kt、TlvWriterTest.kt、TlvReadWriteTest.ktTLV 读/写/回环测试jsontlv/JsonToTlvToJsonTest.ktJSON 与 TLV 的互转测试onboardingpayload/ManualCodeTest.kt、QRCodeTest.kt入网配对负载配对码/二维码解析测试这种“镜像包名 就近放置”的组织方式让测试与被测类的调用关系一目了然也便于在 CI 中按包维度选择要注入的测试库。二、环境准备Android SDK、NDK 与工具链版本docs/platforms/android/android_building.md 给出了明确的版本要求这也是运行本套测试的环境前提1. 版本基线组件要求版本Android SDK34Android NDK28.2.13676358Gradle Plugin / Gradle8.5.1 / 8.7JDK17.0Kotlinkotlinc 需在$PATH中2.1.102. Android Studio 安装步骤按官方文档的顺序完成安装 Android Studio安装 NDKTools - SDK Manager - SDK Tools勾选 Show Package Details选择 NDK (Side by Side) 28.2.13676358安装 Command Line ToolsAndroid SDK Command Line Tools 10.0安装 SDK 平台Android 14.0 (Upside Down Cake) API Level 34安装模拟器镜像Tools - Device Manager - Create device - Pixel 5 - Android S API 34。3. 环境变量设置Linuxexport ANDROID_HOME~/Android/Sdk export ANDROID_NDK_HOME~/Android/Sdk/ndk/28.2.13676358macOSexport ANDROID_HOME~/Library/Android/sdk export ANDROID_NDK_HOME~/Library/Android/sdk/ndk/28.2.136763584. ABI 与 TARGET_CPU 对照表模拟器/真机的 CPU 架构决定TARGET_CPU的取值ABITARGET_CPUarmeabi-v7aarmarm64-v8aarm64x86x86x86_64x64在 x86_64 的模拟器上通常选用x64在 arm64 模拟器或真机上选用arm64。选错 ABI 会导致 native 测试库无法加载JNI 用例直接失败。5. JDK 与 Kotlin 准备macOS 可通过 sdkman 安装 JDK 17sdk install java 17.0.14-temLinux 可直接安装 openjdk-17 并设置JAVA_HOMEsudo apt-get install openjdk-17-jdk export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64Kotlin 编译器需要 2.1.10Linux 下把 kotlinc 下载解压到/usr/lib后加入$PATH即可macOS 可用sdk install kotlin 2.1.10。三、构建 CHIPTest从源码产出测试 APKAndroid 侧有两个相关应用CHIPTool配网与控制工具和 CHIPTest运行 Matter 单元测试。本主题只关心后者且 CHIPTest目前只能通过构建脚本编译无法在 Android Studio 中直接构建。1. 初始化构建环境# 检出仓库后首次需要执行 source scripts/bootstrap.sh2. 构建 CHIPTest 测试包在仓库根目录执行./scripts/build/build_examples.py --target android-arm64-chip-test build该命令会先编译 Matter C 核心与 Java 控制器层再经 Gradle 打包出app-debug.apk。产物位于out/android-TARGET_CPU-chip-test/outputs/apk/debug/可通过 adb 安装到模拟器adb install out/android-$TARGET_CPU-chip-test/outputs/apk/debug/app-debug.apkCHIPTest 工程自身也是一个标准 Gradle 工程examples/android/CHIPTest/gradlew其app/src/androidTest/目录存放运行在设备端androidTest的测试入口这正是“测试必须在外部模拟器/真机运行”的落点androidTest 由adb触发在设备进程内执行能加载jniLibs中的 native 库。3. 切换被测测试库matterUTestLibexamples/android/CHIPTest/gradle.properties 中有三个与本文主题直接相关的开关# Build SDK from source code and debug in Android Studio. Must also set matterBuildSrcDir. matterSdkSourceBuildfalse # Point to the SDK build dir (out/android-arm64-chip-test for example) # to build SDK from source code and debug in Android Studio. # Set to blank to use the SDK prebuilt by scripts/build/build_examples.py. matterBuildSrcDirout/android-arm64-chip-test # Test libs to run matterUTestLiblibPlatformTests.amatterUTestLib指定要注入的测试静态库。默认值是libPlatformTests.a平台层测试要改跑控制器层测试时将其指向src/controller/java/对应的测试库产物即可——这就是 README 中“run these tests externally”的具体含义先由 GN 构建出测试库再由 CHIPTest 的 Gradle 工程在模拟器上执行matterBuildSrcDir/matterSdkSourceBuild从源码构建并在 Android Studio 中调试 SDK 时指向out/android-arm64-chip-test一类的输出目录并将matterSdkSourceBuild置为true留空则使用build_examples.py预构建产物。4. 运行测试APK 安装后可通过 adb 触发 androidTest以设备端测试为例adb shell am instrument -w 测试包名.test或在 Android Studio 的 Device Explorer / Run 菜单中选择 androidTest 源码集运行-e class参数可以精确到某个测试类例如只跑 TLV 读取测试。四、测试源码剖析哪些用例真正依赖模拟器从 GetConnectedDeviceCallbackJniTest.java 可以看清“外部运行”的必要性。该测试类使用RunWith(AndroidJUnit4.class)即 instrumented test依赖真实的 Android 运行时与 JNIBefore public void setUp() { callbackTestUtil new GetConnectedDeviceCallbackForTestJni(new MessagingContext()); } Test public void deviceConnected() { var callback new FakeGetConnectedDeviceCallback(); var jniCallback new GetConnectedDeviceCallbackJni(callback); callbackTestUtil.onDeviceConnected(jniCallback); assertThat(callback.devicePointer).isNotEqualTo(0L); }它验证两条链路连接成功回调JNI 侧回调onDeviceConnectedJava 层拿到的devicePointer必须非 0证明 C 设备对象指针经 JNI 正确回传连接失败回调onDeviceConnectionFailure(jniCallback, 100L)后Java 层应收到ChipDeviceControllerException且errorCode 100L验证错误码跨层传递的保真性。这类测试无法在纯 JVM 中完成因为MessagingContext与 JNI 方法需要加载libCHIP...系列 native 库这正是必须在模拟器/真机上执行的原因。相对地纯 Kotlin 的 TLV 测试则不依赖 native 库。以 TlvReaderTest.kt 为例它使用标准RunWith(JUnit4::class)并内嵌了一段真实配对流程中提取的 Fabric 配置 TLV 十六进制数据作为回归样本// Extracted from a Newman device during a pairing flow. Represents a fabric // ID and keys for the fabric 7885a14c693bf1cb. private val fabricConfig D50000050001002701CBF13B694CA18578360 21525010110240201300310149BF1430B26F5 ... .trimIndent().replace(\n, ) .chunked(2).map { it.toInt(16) and 0xFF }.map { it.toByte() }.toByteArray()测试断言TlvReader能依次解析出 Structure 类型首元素、Fabric ID0x7885a14c693bf1cb以ContextSpecificTag1 携带的UnsignedIntValue形式出现、证书数组AnonymousTagArrayValue以及厂商 ID0x1001。这种“从真实设备抓取的 TLV 样本”保证了 TLV 编解码器对线上数据的兼容性回归属于控制器层数据面质量的关键防线。综合来看src/controller/java/tests/是两类用例的集合JNI 桥接类用例chip.devicecontroller.*必须在外部设备环境运行TLV/JSON/OnboardingPayload 类用例matter.*本身是纯 JVM 逻辑但也统一经由 CHIPTest 的 androidTest 通道在模拟器上执行从而与整包构建流程保持一致。五、小结与常见排查点围绕 src/controller/java/tests/README.md 的核心约定完整流程可以归纳为四步按 android_building.md 装好 Android SDK 34、NDK 28.2.13676358、JDK 17、Kotlin 2.1.10并创建模拟器source scripts/bootstrap.sh初始化构建环境仅首次./scripts/build/build_examples.py --target android-arm64-chip-test build产出 CHIPTest APK 并adb install按需在 examples/android/CHIPTest/gradle.properties 调整matterUTestLib选择被测测试库与matterBuildSrcDir/matterSdkSourceBuild源码联调开关再通过 androidTest 在模拟器上执行。常见排查点native 库加载失败 / JNI 用例报错优先核对模拟器 ABI 与TARGET_CPU是否匹配x86_64 模拟器应选x64arm64 选arm64想调试 C 控制器代码将matterSdkSourceBuild置true并让matterBuildSrcDir指向实际输出目录如out/android-arm64-chip-test即可在 Android Studio 中从源码构建只想跑控制器层测试而非平台层把matterUTestLib从默认的libPlatformTests.a改为对应的测试库产物名。这套机制把 Matter 的 GN 构建体系与 Android instrumented test 体系桥接在一起GN 负责产出可注入的测试静态库CHIPTest 负责在模拟器/真机上执行从而让src/controller/java/控制器层在每次改动后都能得到与真实设备一致的验证。【免费下载链接】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），仅供参考 在 Android 模拟器中运行 Matter Java 控制器层测试：connectedhomeip 的 Android Emulator Tests 实操指南
在 Android 模拟器中运行 Matter Java 控制器层测试connectedhomeip 的 Android Emulator Tests 实操指南【免费下载链接】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本文以 src/controller/java/tests/README.md 为骨架讲解 Matter原 Project CHIPconnectedhomeip 仓库Android 控制器层单元测试的运行方式为什么这些测试“必须在外部运行”、如何搭建 Android SDK/NDK 环境、如何用构建脚本产出 CHIPTest 测试应用、如何通过gradle.properties切换被测测试库并结合测试源码剖析 JNI 回调测试与 TLV 编解码测试各自依赖什么运行环境。读完本文你能够独立完成一套“从源码编译 → 模拟器安装 → 运行控制器层单测”的完整流程。一、文档核心约定这些测试必须在外部运行README.md 的内容虽然简短但它确立了一个关键约束These tests must be run externally构建与模拟器配置请参见 Building Android 指南。结合仓库结构可以这样理解这句话src/controller/java/下的 Java/Kotlin 控制器代码设备控制器、TLV 编解码、JSON-TLV 转换、Onboarding Payload 解析等并不是一个独立的 Android 工程它编译后以测试库的形式被注入到examples/android/CHIPTest这个 Android 测试应用中。因此测试无法像 JVM 下的纯单元测试那样在裸主机上直接gradlew test完成全部验证——涉及 JNI 的测试用例需要真实加载 native 库必须借助 Android 模拟器或真机外部执行。测试目录结构被测代码与测试用例的对应关系src/controller/java/tests/目录按被测包名镜像组织当前包含两组测试src/controller/java/tests/chip/devicecontroller/GetConnectedDeviceCallbackJniTest.java验证设备连接回调的 JNI 桥接cluster/ChipClusterEventStructTest.kt、cluster/ChipClusterStructTest.kt集群事件结构与数据结构的构造测试src/controller/java/tests/matter/tlv/TlvReaderTest.kt、TlvWriterTest.kt、TlvReadWriteTest.ktTLV 读/写/回环测试jsontlv/JsonToTlvToJsonTest.ktJSON 与 TLV 的互转测试onboardingpayload/ManualCodeTest.kt、QRCodeTest.kt入网配对负载配对码/二维码解析测试这种“镜像包名 就近放置”的组织方式让测试与被测类的调用关系一目了然也便于在 CI 中按包维度选择要注入的测试库。二、环境准备Android SDK、NDK 与工具链版本docs/platforms/android/android_building.md 给出了明确的版本要求这也是运行本套测试的环境前提1. 版本基线组件要求版本Android SDK34Android NDK28.2.13676358Gradle Plugin / Gradle8.5.1 / 8.7JDK17.0Kotlinkotlinc 需在$PATH中2.1.102. Android Studio 安装步骤按官方文档的顺序完成安装 Android Studio安装 NDKTools - SDK Manager - SDK Tools勾选 Show Package Details选择 NDK (Side by Side) 28.2.13676358安装 Command Line ToolsAndroid SDK Command Line Tools 10.0安装 SDK 平台Android 14.0 (Upside Down Cake) API Level 34安装模拟器镜像Tools - Device Manager - Create device - Pixel 5 - Android S API 34。3. 环境变量设置Linuxexport ANDROID_HOME~/Android/Sdk export ANDROID_NDK_HOME~/Android/Sdk/ndk/28.2.13676358macOSexport ANDROID_HOME~/Library/Android/sdk export ANDROID_NDK_HOME~/Library/Android/sdk/ndk/28.2.136763584. ABI 与 TARGET_CPU 对照表模拟器/真机的 CPU 架构决定TARGET_CPU的取值ABITARGET_CPUarmeabi-v7aarmarm64-v8aarm64x86x86x86_64x64在 x86_64 的模拟器上通常选用x64在 arm64 模拟器或真机上选用arm64。选错 ABI 会导致 native 测试库无法加载JNI 用例直接失败。5. JDK 与 Kotlin 准备macOS 可通过 sdkman 安装 JDK 17sdk install java 17.0.14-temLinux 可直接安装 openjdk-17 并设置JAVA_HOMEsudo apt-get install openjdk-17-jdk export JAVA_HOME/usr/lib/jvm/java-17-openjdk-amd64Kotlin 编译器需要 2.1.10Linux 下把 kotlinc 下载解压到/usr/lib后加入$PATH即可macOS 可用sdk install kotlin 2.1.10。三、构建 CHIPTest从源码产出测试 APKAndroid 侧有两个相关应用CHIPTool配网与控制工具和 CHIPTest运行 Matter 单元测试。本主题只关心后者且 CHIPTest目前只能通过构建脚本编译无法在 Android Studio 中直接构建。1. 初始化构建环境# 检出仓库后首次需要执行 source scripts/bootstrap.sh2. 构建 CHIPTest 测试包在仓库根目录执行./scripts/build/build_examples.py --target android-arm64-chip-test build该命令会先编译 Matter C 核心与 Java 控制器层再经 Gradle 打包出app-debug.apk。产物位于out/android-TARGET_CPU-chip-test/outputs/apk/debug/可通过 adb 安装到模拟器adb install out/android-$TARGET_CPU-chip-test/outputs/apk/debug/app-debug.apkCHIPTest 工程自身也是一个标准 Gradle 工程examples/android/CHIPTest/gradlew其app/src/androidTest/目录存放运行在设备端androidTest的测试入口这正是“测试必须在外部模拟器/真机运行”的落点androidTest 由adb触发在设备进程内执行能加载jniLibs中的 native 库。3. 切换被测测试库matterUTestLibexamples/android/CHIPTest/gradle.properties 中有三个与本文主题直接相关的开关# Build SDK from source code and debug in Android Studio. Must also set matterBuildSrcDir. matterSdkSourceBuildfalse # Point to the SDK build dir (out/android-arm64-chip-test for example) # to build SDK from source code and debug in Android Studio. # Set to blank to use the SDK prebuilt by scripts/build/build_examples.py. matterBuildSrcDirout/android-arm64-chip-test # Test libs to run matterUTestLiblibPlatformTests.amatterUTestLib指定要注入的测试静态库。默认值是libPlatformTests.a平台层测试要改跑控制器层测试时将其指向src/controller/java/对应的测试库产物即可——这就是 README 中“run these tests externally”的具体含义先由 GN 构建出测试库再由 CHIPTest 的 Gradle 工程在模拟器上执行matterBuildSrcDir/matterSdkSourceBuild从源码构建并在 Android Studio 中调试 SDK 时指向out/android-arm64-chip-test一类的输出目录并将matterSdkSourceBuild置为true留空则使用build_examples.py预构建产物。4. 运行测试APK 安装后可通过 adb 触发 androidTest以设备端测试为例adb shell am instrument -w 测试包名.test或在 Android Studio 的 Device Explorer / Run 菜单中选择 androidTest 源码集运行-e class参数可以精确到某个测试类例如只跑 TLV 读取测试。四、测试源码剖析哪些用例真正依赖模拟器从 GetConnectedDeviceCallbackJniTest.java 可以看清“外部运行”的必要性。该测试类使用RunWith(AndroidJUnit4.class)即 instrumented test依赖真实的 Android 运行时与 JNIBefore public void setUp() { callbackTestUtil new GetConnectedDeviceCallbackForTestJni(new MessagingContext()); } Test public void deviceConnected() { var callback new FakeGetConnectedDeviceCallback(); var jniCallback new GetConnectedDeviceCallbackJni(callback); callbackTestUtil.onDeviceConnected(jniCallback); assertThat(callback.devicePointer).isNotEqualTo(0L); }它验证两条链路连接成功回调JNI 侧回调onDeviceConnectedJava 层拿到的devicePointer必须非 0证明 C 设备对象指针经 JNI 正确回传连接失败回调onDeviceConnectionFailure(jniCallback, 100L)后Java 层应收到ChipDeviceControllerException且errorCode 100L验证错误码跨层传递的保真性。这类测试无法在纯 JVM 中完成因为MessagingContext与 JNI 方法需要加载libCHIP...系列 native 库这正是必须在模拟器/真机上执行的原因。相对地纯 Kotlin 的 TLV 测试则不依赖 native 库。以 TlvReaderTest.kt 为例它使用标准RunWith(JUnit4::class)并内嵌了一段真实配对流程中提取的 Fabric 配置 TLV 十六进制数据作为回归样本// Extracted from a Newman device during a pairing flow. Represents a fabric // ID and keys for the fabric 7885a14c693bf1cb. private val fabricConfig D50000050001002701CBF13B694CA18578360 21525010110240201300310149BF1430B26F5 ... .trimIndent().replace(\n, ) .chunked(2).map { it.toInt(16) and 0xFF }.map { it.toByte() }.toByteArray()测试断言TlvReader能依次解析出 Structure 类型首元素、Fabric ID0x7885a14c693bf1cb以ContextSpecificTag1 携带的UnsignedIntValue形式出现、证书数组AnonymousTagArrayValue以及厂商 ID0x1001。这种“从真实设备抓取的 TLV 样本”保证了 TLV 编解码器对线上数据的兼容性回归属于控制器层数据面质量的关键防线。综合来看src/controller/java/tests/是两类用例的集合JNI 桥接类用例chip.devicecontroller.*必须在外部设备环境运行TLV/JSON/OnboardingPayload 类用例matter.*本身是纯 JVM 逻辑但也统一经由 CHIPTest 的 androidTest 通道在模拟器上执行从而与整包构建流程保持一致。五、小结与常见排查点围绕 src/controller/java/tests/README.md 的核心约定完整流程可以归纳为四步按 android_building.md 装好 Android SDK 34、NDK 28.2.13676358、JDK 17、Kotlin 2.1.10并创建模拟器source scripts/bootstrap.sh初始化构建环境仅首次./scripts/build/build_examples.py --target android-arm64-chip-test build产出 CHIPTest APK 并adb install按需在 examples/android/CHIPTest/gradle.properties 调整matterUTestLib选择被测测试库与matterBuildSrcDir/matterSdkSourceBuild源码联调开关再通过 androidTest 在模拟器上执行。常见排查点native 库加载失败 / JNI 用例报错优先核对模拟器 ABI 与TARGET_CPU是否匹配x86_64 模拟器应选x64arm64 选arm64想调试 C 控制器代码将matterSdkSourceBuild置true并让matterBuildSrcDir指向实际输出目录如out/android-arm64-chip-test即可在 Android Studio 中从源码构建只想跑控制器层测试而非平台层把matterUTestLib从默认的libPlatformTests.a改为对应的测试库产物名。这套机制把 Matter 的 GN 构建体系与 Android instrumented test 体系桥接在一起GN 负责产出可注入的测试静态库CHIPTest 负责在模拟器/真机上执行从而让src/controller/java/控制器层在每次改动后都能得到与真实设备一致的验证。【免费下载链接】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），仅供参考