本片文章为本人第一次上传Google Play的工作总结，可能文章过于基础，大佬勿喷，本文全部命令环境皆为 Windows。预计阅读时间：10分钟
update time : 2020年4月22日19点44分
jks签名问题
本地通过 gradlew resguardxxxRelease （自定义 resguardTask打包）生成正式版Apk，提交Google play 提示密钥时间即将到期。（心里纳闷了 怎么会快到期了呢？）我们 通过 keytool 命令获取 jks 中详细信息：
确定 JDK bin文件夹下 有没有Keytool 。（如果没有运行 jarsigner.exe 文件，生成），然后使用
keytool -list -v -keystore xxx.jks
生成签名的时，可以指定一个有效时间，这个时间默认为 25 年，并且 Google Play 也有硬性规定，上架的 App 签名有效期必须在 2033-10-22 日期之后。如果一直提示密钥时间即将到期，可以尝试将有效时间修改的更长甚至 1W+年
代码问题
缺少64位CPU so包问题
在 Google Play 上发布的应用必现支持 64 位架构，这个意味着上架的应用要包含多份架构的 SO 包，
如果只有 ‘armeabi’，是不行的。为支持 64 位，增加 ,‘arm64-v8a’ 架构。
通过命令行 adb shell getprop ro.product.cpu.abi
根据返回值 可以看到手机默认的so 文件夹。arm64-v8a 是64位的。另外，一般手机内存超过4G 都是64位的，因为32支持的最大内存是4G.
历史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());
builder.setOnKeyListener((dialog, keyCode, event) -> {
if (event.getAction() == KeyEvent.ACTION_UP && keyCode == KeyEvent.KEYCODE_BACK) {
mHandler.cancel();
dialog.dismiss();
return true;
}
return false;
});
AlertDialog dialog = builder.create();
dialog.show();
}
上架后测试问题
这里首先说一下 App bundle
Google 官方推出 App Bundle 已经有一段时间了，简单了解后明白它算是一个比较成熟的官方动态化组件技术，不过对于在国内上线的应用来说，基本感受不到这个技术带来的便利。再加上2019年底 Google 部分条件限制，现在提交正式版本 必须提交 App bundle 版本，简单总结bundle：将所有情况下的资源全部提交到应用市场上，下载时通过动态判断安装符合用户手机的资源包、语言包和abi包。
so 文件问题
上架下载APP 发现登录一直进不去，报错提示网络请求 Put Body为空，（这里牵扯 ndk 请求字段加密和解密的问题）最开始以为 so 包是因为 bundle 动态打包的原因没有将so打进去，验证问题：
下载 bundletool.jar
使用命令反编译aab包
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 智能分包
bundle {
density {
enableSplit = false // 样式 尺寸文件
}
language {
enableSplit = false // 语言文件
}
abi {
enableSplit = false // abi so文件
}
}
经过后期反编译apk，发现so包都有打入apk，那就不应该了！整个人都是蒙蔽的
转机
有位同事 告诉我不会是产品 默认勾选了 google signing吧？我整个人瞬间醒了
Google play默认签名
来到Google play console后台，发现Google 是默认不可关闭 signing 签名配置的。从Google上下载的应用重新签名打包，这个时候导致于你的应用签名证书 MD5，SHA1,SHA-256统统发生了改变，所以凡是使用到这些配置的第三方都受到了影响。（此时内心万马奔腾）由于本人参与的项目 ，与服务器通信的所有信息都是通过so 加密的，so文件又对app签名进行了校验，签名改变，so加密不通过返回空字符串，最终导致了 put body 的数据 都是空的后果。
你的应用加入了签名计划，前面第一个是googlePlay给你的新签名，右上角可以下载签名证书，后面的是你上传应用的签名证书。有了签名证书，
理论上 第一种方案：我们可以打两套包，专门为GooglePlay打一个渠道。
第二种方案 ：替换GooglePlay 签名文件
这里着重实现第二种方案，
下载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% ： 输出文件（将该文件提交到GooglePlay中）
命令行中需要替换的 最好都用绝对路径
替换好后，最好重新上传一个包，包签名才能生效。
遛了 …