KMM共享模块androidMain与Android项目build.gradle.kts的配置疑问

一、何时在共享模块的androidMain中配置依赖？ #

• 当依赖是共享模块代码在Android平台上的实现支撑时，放在这里：
  • 跨平台库的Android专属驱动/实现，比如SQLDelight的Android Driver、Ktor的Android HttpClient引擎——这些是commonMain里的通用逻辑（如数据库操作、网络请求接口）在Android端运行必需的底层依赖。
  • 仅被共享模块内Android专属代码调用的依赖，比如共享模块androidMain中写的Android特用工具类所需的AndroidX库片段，这类依赖只服务于共享模块自身的Android端逻辑，无需暴露给App模块。
  • 跨平台Kotlin库的Android变体依赖，部分KMM库会针对Android提供适配版本，需在androidMain中引入以匹配平台特性。

二、何时在androidApp的build.gradle.kts中配置依赖？ #

• 当依赖是Android应用层专属的功能依赖时，放在这里：
  • 仅App模块使用的UI库，比如Jetpack Compose组件、Material Design库——这些是App层构建界面的工具，和共享模块的跨平台逻辑无关。
  • 应用级服务依赖，比如Firebase Analytics、Crashlytics这类仅在App层初始化和调用的服务，共享模块无需直接依赖。
  • 仅被App模块代码调用的Android系统API封装库，比如权限处理、系统服务封装工具，共享模块的跨平台逻辑不涉及这些场景。

三、为什么共享模块需要androidMain代码集？ #

共享模块的核心是复用跨平台通用逻辑，但并非所有代码都能完全跨平台统一实现：

• 部分功能在不同平台的实现逻辑差异极大，无法在commonMain中统一编写。比如文件存储、传感器访问、系统通知，Android和iOS的API完全不同，必须分别在androidMain和iosMain中写平台专属实现，再通过commonMain的expect/actual机制让通用逻辑调用这些平台代码。
• 跨平台库的平台专属配置/初始化代码，比如Ktor的Android端需要指定特定网络引擎，这类代码只能放在对应平台的sourceSet中。
• 共享模块可能需要适配Android特有特性，比如使用Context、ContentResolver等系统API实现逻辑，这部分代码只能放在androidMain中，避免污染commonMain的跨平台纯净性。

本质上，androidMain是共享模块里Android平台专属代码和依赖的容器——既保证了commonMain通用逻辑的跨平台独立性，又能让共享模块在Android平台上完整实现所需功能，同时保持代码职责的清晰划分，不用把平台专属代码强行塞进App模块。

内容的提问来源于stack exchange，提问作者me.at.coding