Voocii博客
首页博客AI 热榜作品集读书友链工具关于

© 2026 Voocii. Built with Next.js & tRPC.

GitHubXEmailRSS


Android应用 Google Play 上架指南 (2026年)

教程rick-hayekrick-hayek2026年1月8日

本文档旨在指导如何将基于 Capacitor 的移动端应用打包并发布至 Google Play 开发者商店。


目录

  1. 前期准备
  2. 本地打包 (Android App Bundle - AAB)
  3. GitHub Actions 自动化签名与发布 (可选)
  4. Google Play Console 创建与配置应用
  5. 封闭测试与生产环境发布 (重点: 12 人测试规则)
  6. 安全与合规声明 (针对密码管理器与加密应用)

1. 前期准备

在开始上架前,请准备好以下资源和账号:

1.1 开发者账号与资质

  • Google 开发者账号:注册需缴纳一次性 25 美元费用。
  • 邓氏编码 (D-U-N-S):如果你以公司/组织身份注册,Google 强制要求提供邓氏编码进行验证。如果以个人身份注册,则需要身份及地址验证。

1.2 应用资产(商店图文)

  • 应用图标:512 x 512 像素,PNG 格式,最大 1MB。
  • 置顶大图 (Feature Graphic):1024 x 500 像素,JPG 或 24 位 PNG,最大 1MB(用于在商店顶部展示,非常重要)。
  • 手机屏幕截图:至少 2 张,最大 8MB。比例为 16:9 或 9:16,单边长在 320px 到 3840px 之间。
  • 平板电脑截图:分别准备 7 英寸和 10 英寸平板的截图各至少 2 张(可选,但推荐提供)。
  • 文本描述:
    • 应用名称:不超过 30 个字符。
    • 简短说明:不超过 80 个字符。
    • 完整说明:不超过 4000 个字符。

1.3 隐私政策 (Privacy Policy)

  • Google 要求必须提供一个可公开访问的隐私政策网址。你可以在项目根目录下创建一个PRIVACY_POLICY.md,然后渲染到 GitHub Pages 或部署至你自己的网站上,获取公开 URL。

1.4 签名密钥库 (Keystore)

  • 使用你本地 .jks 签名证书文件。
  • 确认记录好以下信息:
    • 密钥库路径:./path-to/your-app-sign-key.jks
    • 别名 (Alias)
    • 密钥库密码 (Store Password)
    • 密钥密码 (Key Password)
# 查看jks里的信息
keytool -list -v -keystore ./path-to/your-app-sign-key.jks

找不到keytool的话:

# 查看jks里的信息
"/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/keytool" -list -v -keystore ./path-to/your-app-sign-key.jks

2. 本地打包 (Android App Bundle - AAB)

Google Play 商店目前强制要求新上架的应用必须提交 .aab 格式(Android App Bundle),而非 .apk。

2.1 同步最新代码至 Android 工程

在项目根目录下执行:

# 构建前端静态资源
npm run build -w @yourapp/app

# 将构建好的资源同步到 Android 目录
npx cap sync android

2.2 使用 Android Studio 打包

  1. 用 Android Studio 打开 packages/app/android 目录。
  2. 点击顶部菜单栏:Build -> Generate Signed Bundle / APK...。
  3. 选择 Android App Bundle,点击 Next。
  4. 在 Key store path 中选择你的 .jks 文件,输入你的密码、别名和别名密码。
  5. 选择输出路径,并将 Build Type 设为 release,点击 Create。
  6. 构建完成后,你将在输出目录下获得一个 app-release.aab 文件。

3. GitHub Actions 自动化签名与发布 (可选)

如果你不想每次在本地手动打包,可以配置 GitHub Actions。当你在代码库推送形如 v1.0.0 的版本 Tag 时,GitHub 会自动完成构建、签名并生成 release 资源包。

首先,在项目的 .github/workflows/release.yml 路径下创建部署流程配置文件,定义好构建、签名与发布的 Action 配置:

name: Build & Release Android App

on:
  push:
    tags:
      - 'v*' # 仅当推送形如 v1.0.0 的 tag 时触发

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Source
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install Dependencies
        run: npm ci

      - name: Build Frontend Web Assets
        run: npm run build -w @yourapp/app

      - name: Setup Java JDK
        uses: actions/setup-java@v4
        with:
          distribution: 'zulu'
          java-version: '17' # Java 17 是目前 Gradle 编译 Android 推荐的版本

      - name: Setup Android SDK
        uses: android-actions/setup-android@v3

      - name: Sync Capacitor Android
        run: npx cap sync android

      - name: Build Android AAB (Release)
        run: |
          cd android
          ./gradlew bundleRelease

      - name: Sign Android App Bundle (AAB)
        id: sign_app
        uses: r0adkll/sign-android-release@v1
        with:
          releaseDirectory: android/app/build/outputs/bundle/release
          signingKeyBase64: ${{ secrets.ANDROID_SIGNING_KEY }}
          alias: ${{ secrets.ANDROID_ALIAS }}
          keyStorePassword: ${{ secrets.ANDROID_KEY_STORE_PASSWORD }}
          keyPassword: ${{ secrets.ANDROID_KEY_PASSWORD }}

      - name: Create GitHub Release & Upload AAB
        uses: softprops/action-gh-release@v2
        with:
          files: ${{ steps.sign_app.outputs.signedReleaseFile }}
          draft: false
          prerelease: false
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

3.1 在 GitHub 仓库中配置 Secrets

进入你的 GitHub 仓库 Settings -> Secrets and variables -> Actions,添加/更新以下 Secrets:

  • ANDROID_SIGNING_KEY:本地 .jks 文件的 Base64 编码字符串(在 Mac 终端运行 base64 -i your-app-sign-key.jks 获取)
  • ANDROID_KEY_STORE_PASSWORD:你的证书库密码
  • ANDROID_ALIAS:别名
  • ANDROID_KEY_PASSWORD:你的别名密钥密码

3.2 触发发布

每次需要发布新版时,在本地打上版本号标签并推送到 GitHub 即可:

git tag v1.0.3
git push origin v1.0.3

GitHub Actions 会自动编译生成签名的安装包并自动创建 Release。


4. Google Play Console 创建与配置应用

登录 Google Play Console 开始创建应用。

4.1 创建应用

  • 点击 Create app。
  • 输入应用名称,选择默认语言。
  • 应用类型选择 App(非游戏 Game)。
  • 价格选择 Free(免费)。
  • 勾选同意开发者计划条款及出口法律,点击 Create app。

4.2 基础信息设置(仪表盘任务)

在后台仪表盘的 "Set up your app" 部分,需要完成一系列表单声明:

  1. 隐私政策:填入你的公开隐私政策网址。
  2. 应用访问权限:选择“所有功能均无需特殊凭证即可直接使用”(根据应用实际情况选择)。
  3. 广告:声明应用中不包含广告。
  4. 内容分级:填写问卷(通常属于工具类应用,无暴力、色情等内容,分级为 3+ 或全年龄段)。
  5. 目标受众和内容:选择目标年龄段(根据应用实际情况选择)。
  6. 新闻应用:声明应用不是新闻应用。
  7. 数据安全 (Data Safety)(非常重要!):
    • 声明:不收集或共享任何用户数据(根据应用实际情况选择)。
    • 勾选:“所有收集的数据都传输进行了加密”(根据应用实际情况选择)。
  8. 金融特性声明:如果被问及,声明不提供具体的金融贷款或直接的金融交易支付服务。

4.3 谷歌应用签名 (Google Play App Signing) 与 SHA 证书指纹避坑指南

当你向 Google Play 提交 .aab 格式文件时,Google 强制要求启用 Google Play 应用签名(Google Play App Signing)。这引入了一个非常普遍但致命的“签名指纹不匹配”大坑:

Warning

本地密钥 vs 谷歌签名密钥:

  • 本地密钥库 (.jks):现在变成了“上传密钥 (Upload Key)”,Google Play 仅用它来验证是你上传的包。
  • 谷歌签名密钥 (App Signing Key):Google 接收到 .aab 后,会在云端使用 Google 独立生成的密钥对应用重新进行签名,用户最终从商店下载到的 .apk 使用的是这个谷歌签名密钥。
  • 后果:这导致你本地打包的 APK 签名指纹,同 Google Play 商店分发的 APK 签名指纹完全不一致!

解决第三方 SDK 验证失败问题

如果你的应用接入了 Google 登录、Firebase、微信登录/分享、支付宝/微信支付、高德/百度地图 等需要配置 SHA-256 或 MD5 证书指纹 的第三方 SDK,请务必进行以下操作:

  1. 不要只使用本地 .jks 提取出的 SHA-256 指纹。
  2. 登录 Google Play Console。
  3. 在左侧导航栏找到 Setup -> App integrity (设置 -> 应用完整性)。
  4. 切换到 App signing (应用签名) 标签页。
  5. 复制 "App signing key certificate" (应用签名密钥证书) 下方的 SHA-256 fingerprint。
  6. 将这个谷歌官方生成的 SHA-256 填入你的 Firebase Console、微信开放平台或 Google Cloud 凭据后台。

多渠道更新与安装包冲突(自动更新失效踩坑)

因为签名指纹不匹配,如果你计划同时在自己官方网站分发 APK,并上架 Google Play,会遭遇严重的升级冲突:

  • 冲突表现:

    • 如果用户先安装了官网下载的 APK(本地密钥签名),当尝试从 Google Play 更新时,系统会提示**“签名不一致,无法更新”**。用户必须手动卸载官网版(导致本地数据全被清除)才能安装商店版。
    • 反之,如果应用内置了检测官网更新并下载 APK 安装的功能,商店版用户更新时会遇到**“应用未安装,因为包与现有包冲突”**报错,自动更新完全失效。
  • 解决方案:

    • 方案 A(统一密钥):在 Google Play console 首次上传 AAB 时,不要选择让谷歌自动生成密钥,而是选择**“导出并上传 Android Studio 的密钥”**,把你本地分发官网 APK 的 .jks 证书上传。这样两边的签名完全一致,可以无缝覆盖升级。
    • 方案 B(代码层分渠道过滤):如果无法统一密钥,必须在代码中检测应用安装来源。对于从 Google Play 安装的用户,禁用你自己的 APK 下载升级逻辑,引导其走 Play 商店更新流程:
      // 伪代码:检测是否为谷歌商店渠道
      const installer = await getInstallerPackageName(); // 原生对应 getInstallerPackageName()
      if (installer === 'com.android.vending') {
        // 禁用自定义应用内下载更新,引导至 Google Play 商店详情页
        openPlayStore('market://details?id=your.package.name');
      } else {
        // 允许从官网下载 APK 进行覆盖升级
        triggerLocalApkDownload();
      }
      

5. 封闭测试与生产环境发布 (重点: 12 人测试规则)

Important

谷歌个人开发者账号新规 (2023年11月起生效): 个人开发者账号在申请将应用发布到“生产环境(正式上架)”之前,必须进行封闭测试(Closed testing)。

  • 硬性指标:必须邀请至少 12 名测试人员。
  • 测试时长:测试人员必须连续加入测试并保留应用至少 14 天。
  • 测试期结束后,你才可以在控制台提交上架正式版(Production)的申请,谷歌将对测试反馈进行评估审查。

5.1 创建封闭测试轨道

  1. 在左侧菜单中选择 Testing -> Closed testing。
  2. 点击 Create track。
  3. 在 Testers 标签页中,创建一个测试人员列表(可以输入测试人员的 Google 邮箱)。
  4. 在 Releases 页面中,点击 Create new release。
  5. 上传你之前生成的 .aab 格式的 App Bundle 文件。
  6. 检查并保存,然后点击 Start rollout to Closed testing。
  7. 获得测试链接,分享给你的 12 位测试人员,让他们下载并保持安装 14 天。

5.2 封闭测试满 14 天申请正式上架的“控制台问卷”答题攻略

当 14 天封闭测试结束,且 12 位测试人员全部达标后,你可以点击“申请发布到生产环境(Apply for Production)”。此时谷歌后台会强制要求你填写一份测试总结问卷。谷歌的人工审核员会仔细评估这份问卷,如果回答过于应付或不合逻辑(例如回答“没有任何 Bug,测试很完美”),申请将会被直接驳回,并被要求重新进行 14 天测试。

以下是控制台核心问题及高通过率的回答话术指引:

问题 1:你是如何招募测试人员的?(How did you recruit testers?)

  • ❌ 错误回答:我是花钱买的测试服务 / 我找了网上的刷单公司 / 没招募,自动满 12 人。
  • ✅ 推荐回答:如实说明通过技术社区、邮件列表、社交平台、亲友或 Google 论坛招募。强调测试人员是你的目标受众,熟悉此类应用。
  • 📝 英文示范:“I recruited testers from local developer groups, online technology communities (such as Reddit and Google Groups), and my personal professional network. I filtered for users who frequently use productivity/utility apps to ensure high-quality feedback.”

问题 2:测试人员加入和进行测试是否顺利?(Was it easy for testers to join and test your app?)

  • ❌ 错误回答:非常顺利,什么问题都没有。
  • ✅ 推荐回答:说明测试人员通过加入 Google Group 获得权限,通过商店链接下载。可以适当提到测试初期有个别用户由于 Google 账号区域不匹配导致无法下载,你及时协助解决,以此体现测试的真实性。
  • 📝 英文示范:“Yes, the process was generally smooth. Testers joined our designated Google Group to gain access and downloaded the app via the Play Store. A few testers initially had country-region mismatch issues, which I resolved by expanding the testing countries in the console.”

问题 3:你从测试人员那里收到了什么反馈?(What feedback did you receive from testers?)

  • ❌ 错误回答:大家都说软件很好,没有任何反馈或建议。
  • ✅ 推荐回答:绝对不能写没有收到反馈! 必须列出 2-3 条具体的改进建议(例如:暗黑模式下的对比度不够、iPad 屏幕上文字被截断、部分操作按钮响应不够灵敏等)。
  • 📝 英文示范:“We received constructive feedback. Specifically, testers pointed out that on larger screen devices like iPads, the navigation header margins felt too cramped. Others suggested simplifying the settings panel by displaying theme selectors as icons rather than long text options.”

问题 4:你根据测试人员的反馈采取了什么行动?(What actions did you take based on tester feedback?)

  • ❌ 错误回答:我觉得软件没问题,所以没有改动。
  • ✅ 推荐回答:详细列出针对问题 3 中的反馈你做了哪些代码修改,并发布了更新版本。说明你通过 Closed testing 轨道推送了修复包并让测试人员再次验证。
  • 📝 英文示范:“Based on the feedback, I refactored the navigation header’s responsive padding (adjusted gap on tablets) and simplified the theme switcher into an icon-only control in the mobile drawer. I compiled and published two updated versions to the Closed testing track to verify these fixes.”

6. 安全与合规声明 (针对密码管理器与加密应用)

如果你的应用涉及加密解密,在上架审核时容易受到安全和加解密相关的额外关注:

  1. 加解密出口声明:
    • 建议应用使用设备本地的标准加解密算法(如 AES-256-GCM、PBKDF2),不属于美国出口管制限制的专用军事级加密技术,在合规性问卷中如实填写“使用系统/标准加解密算法”即可。
  2. 应用权限控制:
    • 检查 AndroidManifest.xml 中的权限,确保只配置了最低要求的权限。不要申请不必要的敏感权限(如读取短信、读取联系人或定位权限),否则很容易会导致审核退回。
  3. 本地存储安全性:
    • 确保敏感数据仅保存在应用的沙盒存储中(如 SharedPreferences 的加密实现或 SQLite 数据库)。Capacitor 会自动处理沙盒隔离,确保其他应用无法越权读取数据。

评论 (0)

暂无评论,快来抢沙发吧!

目录
  • 目录
  • 1. 前期准备
  • 2. 本地打包 (Android App Bundle - AAB)
  • 3. GitHub Actions 自动化签名与发布 (可选)
  • 4. Google Play Console 创建与配置应用
  • 5. 封闭测试与生产环境发布 (重点: 12 人测试规则)
  • 6. 安全与合规声明 (针对密码管理器与加密应用)