技能介绍

要解决什么问题

Unity 手游上线国内渠道时，往往要在 Android 工程里叠多套游戏、广告、支付 SDK。各渠道 AAR 的 Manifest、provider/activity 冲突、Gradle 依赖方式（本地 AAR vs Maven）、以及 Unity 与 Java 层的回调桥接，都会因项目结构不同而踩坑。本技能面向「还没定死接入路径」的团队：不预设你的目录、宏或构建系统，而是用一套可复用的评估与实施流程把接入细节在分析过程中定下来。

技能如何工作

核心是 三维度模型（SDK 来源、项目架构、构建方式），第零步用 references/project-assessment.md 产出决策表，后续步骤都据此分支：

SDK 分析：本地 AAR 可走 scripts/aar_analyzer.py analyze --all，报告覆盖 Manifest 冲突、对外 API、类重复、加固与 .so 列表；远端 Maven 则解析 pom.xml / build.gradle 拿 groupId:artifactId:version 与传递依赖。
架构与契约：按单体 / 母包子包 / Flavor 等模式选方案；渠道模块统一对齐 references/channel-contract.md（C# AndroidJavaProxy 或 Java/Kotlin 中间层 + AndroidJavaObject.Call()）。
构建与验证：Manifest 用 aar_analyzer.py --diff 后在相同 XML 层级加 tools:replace；Gradle 模式见 references/gradle-patterns.md；测试按 references/testing-strategy.md 覆盖启动、登录、进关、失败重试、退出五条冒烟路径。

适用边界与注意点

技能提供的是 通用接入方法论与参考清单，不能替代某一渠道 SDK 的官方文档与合规要求。远端 SDK 若仅有闭源 Demo、子模块结构异常，仍需人工对照 Demo 与 build.gradle。ProGuard、具体 flavor 命名与你们 CI 的耦合，要在本流程结论基础上按项目再落地。