PAYATHON 2026

Android 以 AAR 集成支付宝支付 SDK 报错 4000

支付老李

结论

使用完整的支付宝支付 SDK AAR 接入时，AAR 自带的 AndroidManifest.xml 通常会通过 Manifest Merger 自动合并，应用工程不必重复注册相关 Activity。

不过，不能因为“已经改用 AAR”就直接删除原有配置。Activity 是否需要保留，应以 APK/AAB 最终生成的合并清单为准：

  • 合并后的 Manifest 已包含当前 SDK 所需的 Activity：删除应用工程中的重复注册。
  • 合并后的 Manifest 缺少这些 Activity：保留或补充注册，并检查 AAR 是否完整、依赖配置是否正确。
  • 项目中同时存在旧版 JAR、残缺的 AAR 或自定义 Manifest 合并规则：先解决混合集成问题，不要简单地通过增删 Activity 掩盖问题。

错误码 4000 表示支付过程中出现系统异常，无法单凭这个错误码认定 Activity 未注册。定位问题时，还要结合 Logcat、最终合并的 Manifest 和 SDK 返回结果。

为什么改成 AAR 后通常不需要手动注册

AAR 除了 Java/Kotlin 代码，还可以包含资源、原生库和 AndroidManifest.xml。Android Gradle Plugin 构建应用时，会把 SDK 清单中的组件声明合并到应用清单。

因此，“无需手动注册”需要满足以下条件：

  1. 工程实际依赖的是完整 AAR，而不是从 AAR 中提取的 JAR。
  2. AAR 内部已经声明当前版本所需的 Activity。
  3. 构建过程中没有排除、覆盖或删除这些声明。
  4. 最终打包的变体与检查的构建变体一致，例如同为 release 或同为 debug。

只要有一项不满足，删除应用清单中的旧配置后，就可能在拉起支付、打开 H5 收银台或处理支付回跳时失败。

建议的排查步骤

1. 确认项目只使用一种 SDK 接入方式

检查依赖中是否同时存在：

  • 支付宝 SDK 的 AAR；
  • 旧版支付宝 SDK JAR；
  • 其他模块重复携带的支付宝 SDK；
  • 文件名不同但内容相同的多个 AAR。

Gradle 依赖示例：

dependencies {
    implementation files('libs/alipaysdk.aar')
}

如果使用本地 AAR，也可以按照项目当前的 Gradle 配置方式声明。不要在保留旧 JAR 的同时加入 AAR，否则可能造成类冲突、清单来源混乱或实际加载的版本不一致。

2. 检查 AAR 中是否包含组件声明

AAR 本质上是压缩包，可以直接查看其中的 AndroidManifest.xml。检查当前 SDK 文档中提到的 Activity 是否确实存在。

不要参照其他版本的示例推断组件名称。支付宝 SDK 不同版本可能会调整组件及其属性，应以项目实际使用的 AAR 为准。

3. 查看最终合并的 Manifest

在 Android Studio 中打开应用模块的 AndroidManifest.xml，切换到 Merged Manifest 视图并搜索：

com.alipay.sdk

检查所需 Activity 是否出现在最终清单中，同时确认其来源以及 android:exported、android:configChanges、android:launchMode 等属性。

也可以在构建产物目录中查看对应变体的 Manifest 合并结果。由于目录会随 Android Gradle Plugin 版本变化，使用 Android Studio 的 Merged Manifest 视图通常更方便。

4. 检查是否存在清单覆盖规则

注意应用或其他模块中是否有类似配置：

<activity
    android:name="某个支付宝 SDK Activity"
    tools:node="remove" />

或者：

<application
    tools:replace="android:name">

tools:node="remove" 会主动从最终清单中删除组件。即使 AAR 已经声明了 Activity，它也可能不会出现在最终 APK 中。

5. 结合 Logcat 判断是否确为 Activity 问题

组件未注册时，日志中可能出现：

ActivityNotFoundException

或者类似信息：

Unable to find explicit activity class

如果没有这类异常，还需要继续检查：

  • PayTask.pay(...) 的调用线程和参数；
  • 签名、应用包名和支付宝开放平台配置；
  • 支付订单字符串是否完整；
  • SDK 是否被混淆或裁剪；
  • 支付宝客户端版本和设备运行环境；
  • SDK 返回的完整 resultStatus、memo 和 result。

不要只记录 4000。完整的返回内容更有助于判断问题来自清单、参数还是运行环境。

什么时候需要保留 Activity 注册

遇到以下情况时，可以保留或补充手动注册：

  • 实际使用的 AAR 没有声明所需 Activity；
  • 使用旧版 SDK，且该版本的官方接入说明明确要求应用手动注册；
  • SDK 以 JAR 形式接入，清单内容无法自动合并；
  • AAR 经过二次打包、裁剪或转换，导致 Manifest 丢失；
  • 构建系统或自定义插件没有正确执行 Manifest 合并；
  • 最终合并的 Manifest 明确缺少支付流程实际调用的 Activity。

手动声明时，必须使用当前 SDK 版本要求的完整配置。旧版 SDK 曾使用过如下形式的组件声明：

<application>
    <activity
        android:name="com.alipay.sdk.app.H5PayActivity"
        android:configChanges="orientation|keyboardHidden|navigation|screenSize"
        android:exported="false"
        android:screenOrientation="behind" />

    <activity
        android:name="com.alipay.sdk.app.H5AuthActivity"
        android:configChanges="orientation|keyboardHidden|navigation|screenSize"
        android:exported="false"
        android:screenOrientation="behind" />
</application>

这只是旧版 SDK 中常见的示例，不能直接用于所有版本。应从当前 AAR 的 Manifest 或该版本的官方接入文档中复制准确声明，不要自行猜测 Activity 名称和属性。

什么时候应当移除手动注册

满足以下条件时，应删除应用工程中重复的 Activity 声明：

  • 当前使用的是官方完整 AAR；
  • AAR 已经声明相关 Activity；
  • Merged Manifest 中可以看到这些组件；
  • 应用没有覆盖 SDK 默认属性的实际需求；
  • 支付、回跳和 H5 场景均已验证通过。

重复声明通常会由 Manifest Merger 合并，但应用中的属性如果与 AAR 不一致，可能引发合并冲突，也可能意外覆盖 SDK 要求的配置。确认 AAR 可以正确提供声明后，交给 SDK 维护这些组件更合适。

注意事项

Android 12 及以上版本要求带有 intent-filter 的组件明确设置 android:exported。不要为了消除构建错误而随意修改支付宝 SDK Activity 的导出属性。应优先升级到与目标 Android 版本兼容的 SDK，并使用对应版本的官方配置。

修改 Manifest 后，应执行一次干净构建并重新安装应用，避免旧安装包或增量构建结果干扰判断。判断依据不是源码中的某一份 AndroidManifest.xml，而是实际安装包里的合并 Manifest。只要所需 Activity 已正确进入最终安装包，就不必在应用清单中再次注册。如果没有进入，应先查明合并失败或依赖不完整的原因，再决定是否手动补充。

备注：内容仅供参考。