总结：Android应用上传至Google Play商店的步骤(android手机应用)(android的)

这篇文章是我第一次上传到Google Play的工作总结。可能内容比较基础，希望大佬们不要嘲笑。本文中所有命令都是在Windows环境下执行的。预计阅读时间为10分钟。
更新时间：2021年01月22日11:37:21

jks签名问题

本地通过 gradlew resguardxxxRelease （自定义 resguardTask打包）生成正式版Apk，提交Google play 提示密钥时间即将到期。（心里纳闷了 怎么会快到期了呢？）我们 通过 keytool 命令获取 jks 中详细信息：
确定 JDK bin文件夹下 有没有Keytool 。（如果没有运行 jarsigner.exe 文件，生成），然后使用

在生成签名时，您可以使用以下命令：keytool -list -v -keystore xxx.jks

。请注意，默认情况下，签名的有效期为25年。根据Google Play的规定，上架的应用程序签名必须在2033-10-22之后有效（这可能让人感到困惑，即使是25年也不够）。如果您不断收到密钥即将过期的提示，请尝试将有效期延长甚至设置为1000年。

代码问题

缺少64位CPU so包问题

在发布到Google Play上的应用程序必须支持64位架构。这意味着上架的应用程序必须包含多个架构的SO包，而仅有armeabi是不够的。为了支持64位，需要增加arm64-v8a架构。

使用命令行 adb shell getprop ro.product.cpu.abi，您可以查看手机默认的so文件夹。如果返回值为arm64-v8a，则表示手机是64位的。此外，一般来说，超过4GB内存的手机都是64位的，因为32位系统最大支持4GB内存。

历史VersionCode 问题

如果存在历史提交的 app bundle 记录，需要更新 app 的 version_code 序号，一般会自动加一。
大约在2020年4月12日左右，对于该 app 的要求版本是 target_sdk = 28左右。

SSL Handler Err 警告

在项目中，当使用WebViewClient的onReceivedSslError()方法回调时，不能直接使用mHandler.proceed()来同意认证书。相反，我们需要向用户显示提示信息，并要求用户手动同意认证证书。以下是代码块示例：

@Override
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
    final SslErrorHandler mHandler = handler;
    AlertDialog.Builder builder = new AlertDialog.Builder(view.getContext());
    builder.setMessage(view.getContext().getString(R.string.SSL_err));
    builder.setPositiveButton(view.getContext().getString(R.string.SSL_next), (dialog, which) -> mHandler.proceed());
    builder.setNegativeButton(view.getContext().getString(R.string.cancel), (dialog, which) -> mHandler.cancel());
    
    AlertDialog alertDialog = builder.create();
    alertDialog.show();
} 
Google官方推出的App Bundle已经有一段时间了。通过简单了解，我们可以明白它是一个相当成熟的官方动态化组件技术。然而，在国内上线的应用中，很难感受到这项技术带来的便利。尤其是在2019年底，Google对部分条件进行了限制，现在提交正式版本必须使用App Bundle版本。

简单总结一下App Bundle：它将所有情况下的资源全部提交到应用市场上，在下载时通过动态判断安装符合用户手机的资源包、语言包和abi包。
 
so 文件问题
 
在尝试上架并下载该APP时，我遇到了一个登录问题。每次尝试登录时，都会出现网络请求错误的提示，指示请求主体为空。这个问题涉及到NDK请求字段的加密和解密。最初我以为是因为动态打包时没有将so包正确地打入bundle中所导致的验证问题。
 
获取 bundletool.jar 下载链接
 
对aab包进行命令行反编译
 
改写后的文案如下：

```
使用以下命令构建apks文件：
java -jar bundletool-all.jar build-apks --bundle=%YMCapp.aab% --output=%YMCapp.apks% --ks=%YMC.jks% --ks-pass=pass:%kspass% --ks-key-alias=%alias% --key-pass=pass:%keypass%

参数说明：
%YMCapp.aab%：aab文件，即app bundle文件
%YMCapp.apks%：输出apks（实质上是一个zip文件，可以修改后缀名解压）
%YMC.jks%，jks文件
%kspass%，key store密码
%alias%，别名
 %keypass%，key密码
```   
在命令行中，最好将需要替换的内容都使用绝对路径来表示。
  
默认 bundle 生成的 aab包中，分为Base Apks 和 Split apks ，针对不同分辨率、cpu架构和语言都有不同的apk可供安装，Split apk中则针对 lib 和 MATH文件进行了区分（后期总结暂时没有图片，最好自己打包aab体会）
 
经过检查，我们发现了一些问题，并且怀疑这可能与分包有关。因此，我们决定默认关闭aab智能分包功能。
 
经过后期反编译apk，发现所有的so包都已经被打入了apk，这是不应该的！整个人都是蒙蔽的。 
转机
有位同事告诉我，也许是产品默认勾选了Google签名吧？这一瞬间，我整个人都清醒了起来。
 
Google play默认签名
 
来到Google play console后台，发现Google 是默认不可关闭 signing 签名配置的。从Google上下载的应用重新签名打包，这个时候导致于你的应用签名证书 MD5，SHA1,SHA-256统统发生了改变，所以凡是使用到这些配置的第三方都受到了影响。（此时内心万马奔腾）由于本人参与的项目 ，与服务器通信的所有信息都是通过so 加密的，so文件又对app签名进行了校验，签名改变，so加密不通过返回空字符串，最终导致了 put body 的数据 都是空的后果。
 
您的应用已加入签名计划。第一个是由Google Play提供的新签名，可以在右上角下载签名证书。后面是您上传应用时使用的签名证书。有了这些签名证书，理论上有两种方案可供选择：第一种方案是为Google Play打包一个专门渠道的应用；第二种方案是替换Google Play的签名文件。
 
这里着重实现第二种方案，
 
Pepk.jar
 
根据官方网站的指引，您可以下载Pepk。
 
以下是改写后的文案：

```
使用以下命令运行pepk工具：

java -jar %pepk.jar% --keystore=%YMCapp.jks% --alias=%alias% --output=%output.zip% --encryptionkey=eb10fe8f7c7c9df715022017b00c6471f8ba8170b13049a11e6c09ffe3056a104a3bbe4ac5a955f4ba4fe93fc8cef27558a3eb9d2a529a2092761fb833b656cd48b9de6a --signing-keystore=%YMCapp.jks% --signing-key-alias=%alias%

参数说明：
- %pepk.jar%：pepk工具的地址
- %YMCapp.jks%：jks文件路径
- %alias%：别名
- %output.zip%：输出文件（将该文件提交到Google Play）
```   
在命令行中，最好将需要替换的内容都使用绝对路径来表示。
  
建议您在替换完成后重新上传一个新的包，并进行包签名以确保生效。
 
参考文章
 
遛了 …
 
接入Google Analytics
 
参考博客：如何接入Google Analytics
 
关于Google Play商店不允许使用TBS SDK的问题
 
为了减少您的apk包大小增量，并及时解决安全隐患，TBS SDK采用了后台动态下发内核的方案。由于Google Play禁止任何二进制代码的下发（包括so、dex、jar）和插件化技术的使用，如果您具备多渠道打包能力，您可以在海外版本接入仅保留接口的SDK，以确保编译通过并仅使用系统webview。请点击下载地址，在其他渠道上使用标准SDK版本以便正常享受X5能力。

标签： 谷歌商店上架 文件 问题