assembleRelease 仅生成 AAR 文件（如 my-sdk-release.aar），不自动包含混淆规则、依赖声明、源码或文档；必须确保模块为 com.android.library 类型、显式配置 consumerProguardFiles 和 maven-publish 的 publications，且正确导出 components['release'] 以保障依赖传递与下游集成可靠性。
assembleRelease是最直接有效的方式，但光执行这个命令远远不够——它只生成文件，不保证可被正确引用，尤其在跨项目或发布到私服时，容易因配置缺失导致调用方崩溃或依赖丢失。
确认模块类型是 com.android.library
Android 库模块和 App 模块的构建逻辑完全不同，如果 build.gradle 顶部写的是 com.android.application，哪怕你运行 assembleRelease，Gradle 也会报错或静默生成错误产物。
- 必须确保模块根目录下的
build.gradle（或build.gradle.kts）以plugins { id 'com.android.library' }开头 - 删掉任何
applicationId配置，它只属于 App 模块 - 检查
android { ... }块里没有defaultConfig { applicationId "..." }，否则构建会失败并提示 “applicationId cannot be set in library”
assembleRelease 能生成什么，又不能生成什么
执行 ./gradlew :my-sdk:assembleRelease 后，你会在 my-sdk/build/outputs/aar/my-sdk-release.aar 得到一个 ZIP 包，里面包含 classes.jar、res/、AndroidManifest.xml 等，但它不包含混淆规则、不包含依赖声明、不包含源码或文档——这些全靠你手动补全。
- 混淆规则必须通过
consumerProguardFiles 'consumer-rules.pro'显式声明，否则引用方开启混淆后，你的公开类会被误删 - 如果库本身依赖了
okhttp或其他模块，assembleRelease不会把它们打进 AAR，也不会在pom中声明——这意味着别人依赖你的 AAR 时，得自己再写一遍implementation 'com.squareup.okhttp3:okhttp:4.12.0' - AAR 本身不带
sources.jar或javadoc.jar，调试时看不到源码跳转，除非你额外配置generateSourcesJar类型的任务
发布到 Artifactory 时，pom 文件比 .aar 还重要
Artifactory 只负责存和发，它不会帮你“猜”这个 AAR 依赖了什么。真正决定依赖能否自动传递的，是同名的 my-sdk-release.aar.pom 文件。如果你用默认 maven-publish，大概率这个 pom 里 runtime，导致引用方编译通过、运行时报 NoClassDefFoundError。
- 必须在
publishing { publications { ... } }中显式调用from(components['release'])，且确保components['release']已正确定义（AGP 8.0+ 默认不暴露release组件，需手动创建） - 对
api引入的依赖，pom中对应为compile implementation则应为runtime - 若模块含多 flavor（如
free/pro），assembleRelease只打默认 flavor，而publish任务默认不处理 flavor 变体，需要额外配置variants.withType
AAR 打包不是“点一下就完事”的操作，它的可靠性取决于三个隐性契约：模块类型声明正确、混淆规则主动导出、依赖关系如实反映在 pom 中。漏掉任意一个，下游集成时都会变成黑盒排查。
