本篇文章為本人第一次上傳Google Play的工作總結，可能文章過于基礎，大佬勿噴，本文全部指令環境皆為 Windows。預計閱讀時間：10分鐘
update time : 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 也有硬性規定，上架的 App 簽名有效期必須在 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位的。另外，一般手機記憶體超過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.jar
下載下傳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中）
指令行中需要替換的 最好都用絕對路徑
替換好後，最好重新上傳一個包，包簽名才能生效。
參考文章
遛了 …
接入Google Analytics
google Analytics 接入參考部落格
關于Google Play商店不允許使用TBS SDK的問題
為了減少您的apk包大小增量，及時動态發版解決安全隐患，TBS SDK采用了背景動态下發核心的方案。由于Google Play 禁止任何二進制代碼的下發（包括so、dex、jar）和插件化技術的使用，如果您有多管道打包能力，您可以在海外版本接入僅保留接口的SDK，保證編譯通過，僅使用系統webview，下載下傳位址，在其他管道使用标準SDK版本以便正常使用X5能力