Android项目引入Kotlin Multiplatform模块后接口暴露类型无法解析

我之前处理过类似的复合构建+KMM模块的IDE类型索引问题，结合你的场景，分享几个可行的排查和解决方向：

这个现象的本质是复合构建（includeBuild）模式下，Android Studio的索引系统没有正确关联KMM子模块的类型——虽然构建能正常完成（说明Gradle元数据和依赖逻辑是对的），但IDE层面无法解析接口返回的子模块类型，导致显示[ERROR : SomeType]。

1. 确认KMM模块的依赖暴露逻辑 #

你的shared-app（即mppFramework）用api(":mppModuleX")依赖子模块是正确的，但要确保每个KMM子模块的Android目标配置完整且类型是公开的：

• 在每个mppModuleX的build.gradle.kts中，Android部分要明确指定源码目录，避免IDE遗漏类型：

android {
    sourceSets {
        named("main") {
            java.srcDirs("src/androidMain/kotlin")
            resources.srcDirs("src/androidMain/resources")
        }
    }
}

• 检查子模块中SomeType及其相关接口的访问修饰符，确保是public（Kotlin默认是public，但如果用了internal会导致跨模块无法访问）。

2. 强制重建IDE索引 #

Android Studio在复合构建场景下经常会出现索引滞后的情况，试试以下操作：

• 点击工具栏的Sync Project with Gradle Files，等待同步完成后重新查看代码
• 如果无效，执行File → Invalidate Caches...，勾选Invalidate and Restart，彻底清空旧索引重建
• 极端情况下，可以删除旧Android项目的.idea文件夹和所有build文件夹，然后重新导入项目

3. 优化复合构建的依赖替换规则 #

你当前的依赖替换没有指定变体，KMM模块有多个目标（Android/iOS等），IDE可能无法自动匹配正确的Android变体。可以在旧Android项目的settings.gradle中补充变体指定：

enableFeaturePreview("GRADLE_METADATA")
includeBuild("mpp-project") {
    dependencySubstitution {
        substitute(module("our.package.name:shared"))
            .using(variantOf(project(":shared-app")) {
                attributes {
                    // 指定Android默认 flavor 和 debug 构建类型
                    attribute(com.android.build.api.attributes.ProductFlavorAttr.of("default"), "")
                    attribute(com.android.build.api.attributes.BuildTypeAttr.of("debug"))
                    // 指定Java API 用途
                    attribute(org.gradle.api.attributes.Usage.USAGE_ATTRIBUTE, 
                              objects.named(org.gradle.api.attributes.Usage, "java-api"))
                }
            })
    }
}

这样能帮助IDE精准定位到Android目标的类型定义。

4. 验证旧项目的依赖声明 #

确保旧Android项目的myApp模块中，依赖KMM模块的方式是使用坐标而非直接项目路径：

// 正确写法
implementation("our.package.name:shared")

// 错误写法（会跳过复合构建的依赖替换逻辑）
// implementation(project(":shared-app"))

5. 检查KMM模块的元数据完整性 #

进入KMM项目的build/publications目录，查看Android变体（比如androidDebug）下的module.json文件，确认其中包含了所有子模块的依赖引用，且SomeType的全类名正确。如果元数据缺失，可以执行KMM模块的publishToMavenLocal任务，该任务会生成完整的Gradle元数据，帮助IDE识别类型。

如果以上方法都无效，可以暂时将KMM模块发布到本地Maven仓库，然后旧Android项目直接依赖本地Maven坐标。这种方式可以排除复合构建的索引问题，验证是否是KMM模块本身的类型暴露逻辑存在缺陷。

内容的提问来源于stack exchange，提问作者Agács Tamás