LiteRT-LM Android 示例应用依赖集成合规审计Source Build 与 Maven 双路径检查清单详解【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LM本篇技术指南面向在 Bazel/Bzlmod 工程中集成 LiteRT-LM Android 库的开发者与自动化 Agent系统讲解create-litert-lm-android-demo-app技能所定义的依赖合规检查清单Dependency Compliance Checklist——它覆盖从禁止拷贝源码到双 JAR 导入传递依赖导出Maven 坐标解析等全部审计项。读完本文你将掌握两条源码构建 / Maven 集成依赖路径下每一项检查的判定标准、可落地证据的采集方法以及如何用file、readelf、jdeps、zipinfo等命令产出可复核的合规报告。一、检查清单的定位与审计总原则agents/skills/create-litert-lm-android-demo-app/references/compliance_checklist_dependency.md是整个create-litert-lm-android-demo-app技能在依赖集成环节的验收关口。该技能将生成一个独立的 LiteRT-LM Android 示例应用其完整执行流程记录在 SKILL.md 中步骤 4Obtain LiteRT-LM Shared Library and Kotlin Interface会按用户选择的场景加载对应的依赖集成参考文档初始化依赖检查清单并在集成完成后就地执行本地合规审计步骤 6 再对全部三份合规报告UI / 依赖 / 推理统一复核。在审计开始前必须先理解清单强制要求的两条总原则审计状态重置约束Audit Status Reset Constraint一旦合规审计启动后代码库发生任何改动报告中的全部状态必须重置为Pending或留空以确保所有条目都被完整、干净地重新验证一遍防止旧证据配新代码。证据质量约束Evidence Quality Constraint所有处于活动状态的检查项其Evidence列必须包含具体代码引用文件名与行号或精确的命令输出。诸如verifiedsupportedmanual scroll之类的模糊描述一律不视为有效证据。合规报告以StatusPass/Fail/Skipped与Evidence两列构成的标准表格呈现原清单给出的报告骨架如下供审计时逐行填充RequirementStatusEvidenceCommon Setup BuildNo Source Copy (No C files in app dir)Library Dependency VerificationSource Build SpecificsRepo CheckTarget Arch VerificationTransitive Deps (Source Build)Dual JAR Import VerificationPrebuilt Folder CheckMaven Integration SpecificsMaven Coordinate VerificationMaven Transitive Deps下面按表格的三大分组逐一展开每项检查的判定要点与证据采集方式。二、Common两条路径共用的通用检查项通用检查项不区分构建路径无论用户选择源码构建Source Build还是 Maven 集成Maven Integration都必须满足。2.1 No Source Copy禁止把 LiteRT-LM 源码拷进应用工程审计要求确认没有将 LiteRT-LM 的 C 源码文件直接复制进示例应用工程目录。这是一条边界清晰的检查示例应用应以二进制依赖JAR/AAR的形式消费 LiteRT-LM而不是把引擎源码混入自身工程否则会破坏模块边界、引入重复符号并显著拖慢构建。证据采集在示例应用工程根目录执行文件检索确认不存在*.cc、*.h等 C 源文件如find app_dir -name *.cc -o -name *.h返回空结果并把命令输出贴在 Evidence 列。2.2 Library Dependency库必须以kt_android_library依赖形式引入审计要求确认 LiteRT-LM 库已作为示例应用kt_android_library目标的deps依赖被正式声明而不是以源码、手写 classpath 或拷贝文件的方式裸挂。以本仓库的官方 Kotlin 绑定目标为参照kotlin/java/com/google/ai/edge/litertlm/BUILD 中定义kt_android_library( name litertlm-android, srcs glob([*.kt]), deps [ rules_kotlin//kotlin/compiler:kotlin-reflect, maven//:com_google_code_gson_gson, maven//:org_jetbrains_kotlinx_kotlinx_coroutines_android ], )可以看到LiteRT-LM 的 Android 绑定本身就是 Kotlin 库形式其运行依赖包括 GsonJSON 序列化与 kotlinx-coroutines异步调用支撑。示例应用的kt_android_library应当在deps中显式声明//litert_lm_prebuilt:litertlm_kotlin源码构建路径或maven//:com_google_ai_edge_litertlm_litertlm_androidMaven 路径证据直接引用应用 BUILD 文件中 deps 的完整行号即可。三、Source Build Specifics源码构建路径的专项检查项当用户选择源码构建场景时依赖集成遵循 dependency_source_build.md 的流程清单相应追加五条专项检查。3.1 Repo Check先确认 LiteRT-LM 仓库可用审计要求确认在执行代码生成前已经检查过 LiteRT-LM 仓库并按需拉取/克隆。源码构建的前提是本地存在仓库副本优先询问用户是否已克隆仓库并给出路径若本地不存在需先确认git-lfs已安装缺失则暂停并请用户安装再将仓库克隆到任务根目录下的子目录如[ROOT]/LiteRT-LM构建时必须使用仓库.bazelversion文件锁定的 Bazel 版本。证据采集记录仓库本地路径、git 版本输出、git-lfs版本输出并附上git rev-parse HEAD等可复核信息。3.2 Target Arch Verification用file/readelf -h实测目标架构清单特别强调不要依赖 APK 或 JAR 的目录结构来推断架构而必须对真实的.so文件运行file或readelf -h验证。原因很直观——lib/abi/的目录名可以被随便改写只有 ELF 头部记录的真实架构不可伪造。典型命令file litertlm_native.jar # 先解压出 .so unzip -o litertlm_native.jar -d /tmp/native_check file /tmp/native_check/lib/arm64-v8a/liblitertlm_engine.so # 或 readelf -h /tmp/native_check/lib/arm64-v8a/liblitertlm_engine.so | grep -E Class|Machine注意源码构建时需用 Bazel 预置配置锁定目标架构如--configandroid_arm64对应arm64-v8a、--configandroid_armarmeabi-v7a、--configandroid_x86x86、--configandroid_x86_64x86_64而打入 JAR 时target_abi目录名必须是标准的 Android ABI 名如arm64-v8a不能使用 Bazel config 名如android_arm64。这是最常见的出错点必须在证据里附上file/readelf的真实输出。3.3 Transitive Deps三层配置缺一不可源码构建的传递依赖治理是最容易翻车的环节清单要求逐层核验读取绑定目标的原始 BUILD查看克隆下来的 LiteRT-LM 源码树中//kotlin/java/com/google/ai/edge/litertlm:litertlm-android构建目标的deps属性即上文引用的kotlin-reflect、gson、kotlinx-coroutines-android等在MODULE.bazel中注册将清单中列出的全部外部依赖注册进 Bzlmod 配置保证 Bzlmod 能自动解析若 Bzlmod 无法自动解析必须手动补充全部直接与传递坐标否则会产生编译期ImportDepsChecker错误加入exports列表在litert_lm_prebuilt/BUILD的java_import的exports属性中列出这些第三方外部库使其自动传递到下游 classpath。示例应用侧的litert_lm_prebuilt/BUILD配置如下load(rules_java//java:defs.bzl, java_import) package(default_visibility [//visibility:public]) java_import( name litertlm_kotlin, jars [litertlm-android.jar], exports [ # Export external libraries used inside the Kotlin binding prebuilts # so they are automatically added to down-stream classpaths depending on this rule. maven//:com_example_library_transitive_dependency, ], ) java_import( name litertlm_native, jars [litertlm_native.jar], )依赖被干净导出后应用目标无需重复声明传递依赖直接依赖两个 prebuilt 目标即可deps [ //litert_lm_prebuilt:litertlm_kotlin, //litert_lm_prebuilt:litertlm_native, # ... other dependencies ]补充验证手段清单配套指南建议对生成的绑定 JAR 运行 JDK 的jdeps -summary做字节码级静态校验确认所有包依赖都能在活动 classpath 上得到满足jdeps -summary litert_lm_prebuilt/litertlm-android.jar该命令输出应显示not found的包集合为空若有缺失则说明exports配置遗漏需回到第 1、2 步补齐。3.4 Dual JAR Import Verification双 JAR 都必须java_import源码构建必须产出两个JAR并且两个都要以java_import形式显式导入Kotlin Class JAR编译 Kotlin 绑定目标如//kotlin/java/com/google/ai/edge/litertlm:litertlm-android取其包含编译后.class文件的输出 JARNative JNI JAR编译原生 JNI 库把全部.so按lib/target_abi/目录结构打进新建的litertlm_native.jar。此处的target_abi必须是标准 Android ABI 名。两者都存放在示例应用工程Bazel workspace 根下的litert_lm_android_sample_app/litert_lm_prebuilt/目录并如上节所示通过java_import注册。严格约束不得在android_binary依赖中使用cc_import或直接文件引用 prebuilt.so——Bazel 可能把它们放进 APK 的错误路径。所有原生库必须走 Native JNI JAR 的打包路径。证据采集列出litert_lm_prebuilt目录下两个 JAR 的文件列表并引用 BUILD 中两个java_import的jars属性行号。3.5 Prebuilt Folder Check仓库预构建库是否进入原生打包LiteRT-LM 源码仓库自带各平台预构建加速库本仓库中可见 prebuilt/android_arm64/、prebuilt/android_x86_64/、prebuilt/ios_arm64/、prebuilt/linux_x86_64/等目录。以 prebuilt/android_arm64/BUILD 为例其通过exports_files(srcs glob([**]))导出目录下全部文件内容包括libLiteRtGpuAccelerator.so、libLiteRtOpenClAccelerator.so、libLiteRtTopKOpenClSampler.so、libLiteRtWebGpuAccelerator.so、libwebgpu_dawn.so等 GPU/OpenCL 加速器。审计要求确认源码仓库prebuilt/目录中与目标架构相关的加速库如libLiteRtGpuAccelerator.so是否被成功纳入示例应用的原生打包——即在打包 Native JNI JAR 时将相关加速库与引擎.so一并放入。这一步缺失会导致运行期dlopen找不到 GPU 加速器从而静默回退到 CPU。四、Maven Integration SpecificsMaven 集成路径的专项检查项当用户选择 Maven 集成场景时依赖通过预构建 AAR 解析集成流程见 dependency_maven_integration.md清单相应包含两条专项检查。此路径同样受禁止修改核心 C 引擎文件约束除非用户明确要求。4.1 Maven Coordinate Verification坐标必须精确匹配审计要求确认MODULE.bazel中使用的 Maven 坐标为com.google.ai.edge.litertlm:litertlm-android:latest.release对应的MODULE.bazel配置通过rules_jvm_external的 maven 扩展安装bazel_dep(name rules_jvm_external, version 6.2) maven use_extension(rules_jvm_external//:extension.bzl, maven) maven.install( artifacts [ androidx.core:core-ktx:1.12.0, # Required to handle Edge-to-Edge system window insets in Kotlin com.google.ai.edge.litertlm:litertlm-android:latest.release, ], repositories [ https://maven.google.com, https://repo1.maven.org/maven2, ], version_conflict_policy pinned, use_starlark_android_rules True, aar_import_bzl_label rules_android//rules:rules.bzl, ) use_repo(maven, maven)若目标设备架构与主机不同还需配置 Android NDK 扩展以提供原生 C 编译工具链rules_android_ndk约 0.1.5 版本并在register_toolchains中加入androidndk//:all。应用侧BUILD文件中则直接依赖 Maven 生成的目标名deps [ maven//:com_google_ai_edge_litertlm_litertlm_android, ]证据采集贴出MODULE.bazel中maven.install的 artifacts 列表与对应行号确认坐标字符串逐字一致特别是litertlm-android与latest.release两个片段。4.2 Maven Transitive Deps自动解析与版本冲突处理审计要求确认 Maven 已成功自动解析传递依赖并妥善处理可能出现的版本锁定冲突。Maven AAR 的依赖图由rules_jvm_external自动拉取通常无需手工注册但当 Bzlmod 解析失败、出现编译期ImportDepsChecker报错时必须在maven.install的 artifacts 中显式补充全部直接与传递坐标示例工程中的androidx.core:core-ktx:1.12.0即是这类显式注册的典型。version_conflict_policy pinned策略用于固定冲突版本避免依赖图漂移。证据采集抓取bazel build依赖解析阶段的成功日志或ImportDepsChecker报错消除前后的对比输出如发生版本冲突附上冲突坐标与最终锁定版本。五、合规报告的落地操作与常见陷阱综合以上检查项产出合格合规报告的操作要点可归纳为每条 active 检查必须附硬证据优先引用工作区内真实文件的带行号链接如app/BUILD#L20-L30或直接粘贴终端命令输出块留空、写已人工核对均会被判定为不合规。构建产物用命令实测架构验证用file/readelf -hAPK 内.so位置用zipinfo bazel-bin/app_name.apk lib/*JAR 依赖完备性用jdeps -summary——这些命令输出本身就是最有说服力的证据。任何代码改动后重置全部状态为Pending并完整重跑审计直到所有行均为Pass、所有复选框均勾选[x]且没有任何Pending/Fail残留才能宣告任务完成。路径一旦选定不得中途切换Source Build 与 Maven Integration 两条路径一旦确定就必须坚持到底即使中途出现编译失败也不能在任务进行中更换方案。从本仓库源码可以进一步印证这些审计项的必要性Kotlin 绑定 Engine.kt 的initialize()通过LiteRtLmJni.nativeCreateEngine把modelPath、backend、visionBackend、audioBackend等配置透传给原生引擎Config.kt 中以data class形式定义了EngineConfig、ConversationConfig、SamplerConfig默认backend Backend.CPU()并对maxNumTokens/maxNumImages做了正数校验。一旦原生.so缺失或架构不匹配System.loadLibrary阶段就会直接失败——这正是清单把双 JAR 导入目标架构实测prebuilt 加速库打包列为强校验项的根本原因。六、结语依赖集成是 Android 端侧 LLM 示例应用最容易编译通过、运行翻车的环节。compliance_checklist_dependency.md通过一套可机械执行、证据强制的审计框架把仓库可用性 → 架构真实匹配 → 传递依赖闭环 → 双 JAR 正确导入 → 加速库随包携带 → Maven 坐标精确解析串成一条完整的验收链路。无论你走源码构建还是 Maven 集成把本文梳理的九项检查落到带行号与命令输出的合规报告中就能确保 LiteRT-LM 引擎在目标设备上按预期加载、初始化并执行真实推理。【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LiteRT-LM Android 示例应用依赖集成合规审计：Source Build 与 Maven 双路径检查清单详解
LiteRT-LM Android 示例应用依赖集成合规审计Source Build 与 Maven 双路径检查清单详解【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LM本篇技术指南面向在 Bazel/Bzlmod 工程中集成 LiteRT-LM Android 库的开发者与自动化 Agent系统讲解create-litert-lm-android-demo-app技能所定义的依赖合规检查清单Dependency Compliance Checklist——它覆盖从禁止拷贝源码到双 JAR 导入传递依赖导出Maven 坐标解析等全部审计项。读完本文你将掌握两条源码构建 / Maven 集成依赖路径下每一项检查的判定标准、可落地证据的采集方法以及如何用file、readelf、jdeps、zipinfo等命令产出可复核的合规报告。一、检查清单的定位与审计总原则agents/skills/create-litert-lm-android-demo-app/references/compliance_checklist_dependency.md是整个create-litert-lm-android-demo-app技能在依赖集成环节的验收关口。该技能将生成一个独立的 LiteRT-LM Android 示例应用其完整执行流程记录在 SKILL.md 中步骤 4Obtain LiteRT-LM Shared Library and Kotlin Interface会按用户选择的场景加载对应的依赖集成参考文档初始化依赖检查清单并在集成完成后就地执行本地合规审计步骤 6 再对全部三份合规报告UI / 依赖 / 推理统一复核。在审计开始前必须先理解清单强制要求的两条总原则审计状态重置约束Audit Status Reset Constraint一旦合规审计启动后代码库发生任何改动报告中的全部状态必须重置为Pending或留空以确保所有条目都被完整、干净地重新验证一遍防止旧证据配新代码。证据质量约束Evidence Quality Constraint所有处于活动状态的检查项其Evidence列必须包含具体代码引用文件名与行号或精确的命令输出。诸如verifiedsupportedmanual scroll之类的模糊描述一律不视为有效证据。合规报告以StatusPass/Fail/Skipped与Evidence两列构成的标准表格呈现原清单给出的报告骨架如下供审计时逐行填充RequirementStatusEvidenceCommon Setup BuildNo Source Copy (No C files in app dir)Library Dependency VerificationSource Build SpecificsRepo CheckTarget Arch VerificationTransitive Deps (Source Build)Dual JAR Import VerificationPrebuilt Folder CheckMaven Integration SpecificsMaven Coordinate VerificationMaven Transitive Deps下面按表格的三大分组逐一展开每项检查的判定要点与证据采集方式。二、Common两条路径共用的通用检查项通用检查项不区分构建路径无论用户选择源码构建Source Build还是 Maven 集成Maven Integration都必须满足。2.1 No Source Copy禁止把 LiteRT-LM 源码拷进应用工程审计要求确认没有将 LiteRT-LM 的 C 源码文件直接复制进示例应用工程目录。这是一条边界清晰的检查示例应用应以二进制依赖JAR/AAR的形式消费 LiteRT-LM而不是把引擎源码混入自身工程否则会破坏模块边界、引入重复符号并显著拖慢构建。证据采集在示例应用工程根目录执行文件检索确认不存在*.cc、*.h等 C 源文件如find app_dir -name *.cc -o -name *.h返回空结果并把命令输出贴在 Evidence 列。2.2 Library Dependency库必须以kt_android_library依赖形式引入审计要求确认 LiteRT-LM 库已作为示例应用kt_android_library目标的deps依赖被正式声明而不是以源码、手写 classpath 或拷贝文件的方式裸挂。以本仓库的官方 Kotlin 绑定目标为参照kotlin/java/com/google/ai/edge/litertlm/BUILD 中定义kt_android_library( name litertlm-android, srcs glob([*.kt]), deps [ rules_kotlin//kotlin/compiler:kotlin-reflect, maven//:com_google_code_gson_gson, maven//:org_jetbrains_kotlinx_kotlinx_coroutines_android ], )可以看到LiteRT-LM 的 Android 绑定本身就是 Kotlin 库形式其运行依赖包括 GsonJSON 序列化与 kotlinx-coroutines异步调用支撑。示例应用的kt_android_library应当在deps中显式声明//litert_lm_prebuilt:litertlm_kotlin源码构建路径或maven//:com_google_ai_edge_litertlm_litertlm_androidMaven 路径证据直接引用应用 BUILD 文件中 deps 的完整行号即可。三、Source Build Specifics源码构建路径的专项检查项当用户选择源码构建场景时依赖集成遵循 dependency_source_build.md 的流程清单相应追加五条专项检查。3.1 Repo Check先确认 LiteRT-LM 仓库可用审计要求确认在执行代码生成前已经检查过 LiteRT-LM 仓库并按需拉取/克隆。源码构建的前提是本地存在仓库副本优先询问用户是否已克隆仓库并给出路径若本地不存在需先确认git-lfs已安装缺失则暂停并请用户安装再将仓库克隆到任务根目录下的子目录如[ROOT]/LiteRT-LM构建时必须使用仓库.bazelversion文件锁定的 Bazel 版本。证据采集记录仓库本地路径、git 版本输出、git-lfs版本输出并附上git rev-parse HEAD等可复核信息。3.2 Target Arch Verification用file/readelf -h实测目标架构清单特别强调不要依赖 APK 或 JAR 的目录结构来推断架构而必须对真实的.so文件运行file或readelf -h验证。原因很直观——lib/abi/的目录名可以被随便改写只有 ELF 头部记录的真实架构不可伪造。典型命令file litertlm_native.jar # 先解压出 .so unzip -o litertlm_native.jar -d /tmp/native_check file /tmp/native_check/lib/arm64-v8a/liblitertlm_engine.so # 或 readelf -h /tmp/native_check/lib/arm64-v8a/liblitertlm_engine.so | grep -E Class|Machine注意源码构建时需用 Bazel 预置配置锁定目标架构如--configandroid_arm64对应arm64-v8a、--configandroid_armarmeabi-v7a、--configandroid_x86x86、--configandroid_x86_64x86_64而打入 JAR 时target_abi目录名必须是标准的 Android ABI 名如arm64-v8a不能使用 Bazel config 名如android_arm64。这是最常见的出错点必须在证据里附上file/readelf的真实输出。3.3 Transitive Deps三层配置缺一不可源码构建的传递依赖治理是最容易翻车的环节清单要求逐层核验读取绑定目标的原始 BUILD查看克隆下来的 LiteRT-LM 源码树中//kotlin/java/com/google/ai/edge/litertlm:litertlm-android构建目标的deps属性即上文引用的kotlin-reflect、gson、kotlinx-coroutines-android等在MODULE.bazel中注册将清单中列出的全部外部依赖注册进 Bzlmod 配置保证 Bzlmod 能自动解析若 Bzlmod 无法自动解析必须手动补充全部直接与传递坐标否则会产生编译期ImportDepsChecker错误加入exports列表在litert_lm_prebuilt/BUILD的java_import的exports属性中列出这些第三方外部库使其自动传递到下游 classpath。示例应用侧的litert_lm_prebuilt/BUILD配置如下load(rules_java//java:defs.bzl, java_import) package(default_visibility [//visibility:public]) java_import( name litertlm_kotlin, jars [litertlm-android.jar], exports [ # Export external libraries used inside the Kotlin binding prebuilts # so they are automatically added to down-stream classpaths depending on this rule. maven//:com_example_library_transitive_dependency, ], ) java_import( name litertlm_native, jars [litertlm_native.jar], )依赖被干净导出后应用目标无需重复声明传递依赖直接依赖两个 prebuilt 目标即可deps [ //litert_lm_prebuilt:litertlm_kotlin, //litert_lm_prebuilt:litertlm_native, # ... other dependencies ]补充验证手段清单配套指南建议对生成的绑定 JAR 运行 JDK 的jdeps -summary做字节码级静态校验确认所有包依赖都能在活动 classpath 上得到满足jdeps -summary litert_lm_prebuilt/litertlm-android.jar该命令输出应显示not found的包集合为空若有缺失则说明exports配置遗漏需回到第 1、2 步补齐。3.4 Dual JAR Import Verification双 JAR 都必须java_import源码构建必须产出两个JAR并且两个都要以java_import形式显式导入Kotlin Class JAR编译 Kotlin 绑定目标如//kotlin/java/com/google/ai/edge/litertlm:litertlm-android取其包含编译后.class文件的输出 JARNative JNI JAR编译原生 JNI 库把全部.so按lib/target_abi/目录结构打进新建的litertlm_native.jar。此处的target_abi必须是标准 Android ABI 名。两者都存放在示例应用工程Bazel workspace 根下的litert_lm_android_sample_app/litert_lm_prebuilt/目录并如上节所示通过java_import注册。严格约束不得在android_binary依赖中使用cc_import或直接文件引用 prebuilt.so——Bazel 可能把它们放进 APK 的错误路径。所有原生库必须走 Native JNI JAR 的打包路径。证据采集列出litert_lm_prebuilt目录下两个 JAR 的文件列表并引用 BUILD 中两个java_import的jars属性行号。3.5 Prebuilt Folder Check仓库预构建库是否进入原生打包LiteRT-LM 源码仓库自带各平台预构建加速库本仓库中可见 prebuilt/android_arm64/、prebuilt/android_x86_64/、prebuilt/ios_arm64/、prebuilt/linux_x86_64/等目录。以 prebuilt/android_arm64/BUILD 为例其通过exports_files(srcs glob([**]))导出目录下全部文件内容包括libLiteRtGpuAccelerator.so、libLiteRtOpenClAccelerator.so、libLiteRtTopKOpenClSampler.so、libLiteRtWebGpuAccelerator.so、libwebgpu_dawn.so等 GPU/OpenCL 加速器。审计要求确认源码仓库prebuilt/目录中与目标架构相关的加速库如libLiteRtGpuAccelerator.so是否被成功纳入示例应用的原生打包——即在打包 Native JNI JAR 时将相关加速库与引擎.so一并放入。这一步缺失会导致运行期dlopen找不到 GPU 加速器从而静默回退到 CPU。四、Maven Integration SpecificsMaven 集成路径的专项检查项当用户选择 Maven 集成场景时依赖通过预构建 AAR 解析集成流程见 dependency_maven_integration.md清单相应包含两条专项检查。此路径同样受禁止修改核心 C 引擎文件约束除非用户明确要求。4.1 Maven Coordinate Verification坐标必须精确匹配审计要求确认MODULE.bazel中使用的 Maven 坐标为com.google.ai.edge.litertlm:litertlm-android:latest.release对应的MODULE.bazel配置通过rules_jvm_external的 maven 扩展安装bazel_dep(name rules_jvm_external, version 6.2) maven use_extension(rules_jvm_external//:extension.bzl, maven) maven.install( artifacts [ androidx.core:core-ktx:1.12.0, # Required to handle Edge-to-Edge system window insets in Kotlin com.google.ai.edge.litertlm:litertlm-android:latest.release, ], repositories [ https://maven.google.com, https://repo1.maven.org/maven2, ], version_conflict_policy pinned, use_starlark_android_rules True, aar_import_bzl_label rules_android//rules:rules.bzl, ) use_repo(maven, maven)若目标设备架构与主机不同还需配置 Android NDK 扩展以提供原生 C 编译工具链rules_android_ndk约 0.1.5 版本并在register_toolchains中加入androidndk//:all。应用侧BUILD文件中则直接依赖 Maven 生成的目标名deps [ maven//:com_google_ai_edge_litertlm_litertlm_android, ]证据采集贴出MODULE.bazel中maven.install的 artifacts 列表与对应行号确认坐标字符串逐字一致特别是litertlm-android与latest.release两个片段。4.2 Maven Transitive Deps自动解析与版本冲突处理审计要求确认 Maven 已成功自动解析传递依赖并妥善处理可能出现的版本锁定冲突。Maven AAR 的依赖图由rules_jvm_external自动拉取通常无需手工注册但当 Bzlmod 解析失败、出现编译期ImportDepsChecker报错时必须在maven.install的 artifacts 中显式补充全部直接与传递坐标示例工程中的androidx.core:core-ktx:1.12.0即是这类显式注册的典型。version_conflict_policy pinned策略用于固定冲突版本避免依赖图漂移。证据采集抓取bazel build依赖解析阶段的成功日志或ImportDepsChecker报错消除前后的对比输出如发生版本冲突附上冲突坐标与最终锁定版本。五、合规报告的落地操作与常见陷阱综合以上检查项产出合格合规报告的操作要点可归纳为每条 active 检查必须附硬证据优先引用工作区内真实文件的带行号链接如app/BUILD#L20-L30或直接粘贴终端命令输出块留空、写已人工核对均会被判定为不合规。构建产物用命令实测架构验证用file/readelf -hAPK 内.so位置用zipinfo bazel-bin/app_name.apk lib/*JAR 依赖完备性用jdeps -summary——这些命令输出本身就是最有说服力的证据。任何代码改动后重置全部状态为Pending并完整重跑审计直到所有行均为Pass、所有复选框均勾选[x]且没有任何Pending/Fail残留才能宣告任务完成。路径一旦选定不得中途切换Source Build 与 Maven Integration 两条路径一旦确定就必须坚持到底即使中途出现编译失败也不能在任务进行中更换方案。从本仓库源码可以进一步印证这些审计项的必要性Kotlin 绑定 Engine.kt 的initialize()通过LiteRtLmJni.nativeCreateEngine把modelPath、backend、visionBackend、audioBackend等配置透传给原生引擎Config.kt 中以data class形式定义了EngineConfig、ConversationConfig、SamplerConfig默认backend Backend.CPU()并对maxNumTokens/maxNumImages做了正数校验。一旦原生.so缺失或架构不匹配System.loadLibrary阶段就会直接失败——这正是清单把双 JAR 导入目标架构实测prebuilt 加速库打包列为强校验项的根本原因。六、结语依赖集成是 Android 端侧 LLM 示例应用最容易编译通过、运行翻车的环节。compliance_checklist_dependency.md通过一套可机械执行、证据强制的审计框架把仓库可用性 → 架构真实匹配 → 传递依赖闭环 → 双 JAR 正确导入 → 加速库随包携带 → Maven 坐标精确解析串成一条完整的验收链路。无论你走源码构建还是 Maven 集成把本文梳理的九项检查落到带行号与命令输出的合规报告中就能确保 LiteRT-LM 引擎在目标设备上按预期加载、初始化并执行真实推理。【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
