本片文章爲本人第一次上傳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中）
命令行中需要替換的 最好都用絕對路徑
替換好後，最好重新上傳一個包，包簽名才能生效。
遛了 …