嘿，这个问题我之前做Wear配对开发时也碰到过类似的，结合你说的「签名APK正常、直接运行不行」的现象，核心原因几乎肯定是调试安装过程中的签名或应用身份配置不一致——毕竟代码和applicationId已经没问题了。下面是几个最可能的原因和对应的解决办法：

1. 调试构建的签名密钥不统一 #

Wear OS和手机应用之间的配对通信依赖相同的签名密钥（哪怕是调试用的密钥）来验证身份。如果你的手机模块和Wear模块在debug构建时用了不同的签名配置，直接运行安装就会导致两端签名不匹配，无法通信。

解决方法：统一两个模块的debug签名配置 #

你可以在项目根目录的build.gradle里定义全局的debug签名参数，然后让两个模块共用这个配置：

// 项目根目录 build.gradle
ext {
    debugKeystorePath = "${rootDir}/debug.keystore"
    debugKeystorePassword = "android"
    debugKeyAlias = "androiddebugkey"
    debugKeyPassword = "android"
}

然后在手机和Wear模块的build.gradle中引用这个配置：

android {
    signingConfigs {
        debug {
            storeFile file(debugKeystorePath)
            storePassword debugKeystorePassword
            keyAlias debugKeyAlias
            keyPassword debugKeyPassword
        }
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
    }
}

这样两个模块的debug构建就会用同一个调试密钥，直接运行时就能正常配对了。

2. 即时运行（Instant Run）干扰了签名或安装流程 #

Android Studio的即时运行功能为了加快调试速度，会用增量安装、修改APK签名的方式来推送更新，但这会破坏Wear和手机应用之间的签名验证逻辑，导致通信失败。

解决方法：关闭即时运行并清理项目 #

• 打开File > Settings > Build, Execution, Deployment > Instant Run，取消所有勾选的选项，关闭即时运行；
• 执行Build > Clean Project清理旧的构建缓存；
• 重新运行两个应用，应该就能正常通信了。

3. Debug构建的applicationId变体不一致 #

虽然你设置了相同的applicationId，但如果其中一个模块的debug buildType里配置了applicationIdSuffix（比如给包名加了.debug后缀），而另一个模块没有，那实际运行时的包名就不一样了，配对自然失败。

解决方法：统一applicationId的后缀配置 #

检查两个模块的build.gradle，确保debug构建的applicationId完全一致：

buildTypes {
    debug {
        // 要么完全移除这行，要么两个模块都添加相同的后缀
        // applicationIdSuffix ".debug"
    }
}

内容的提问来源于stack exchange，提问作者Nimdokai