最近、会社の祖先の署名証明書の有効期限が切れていることを突然発見したので、急いで解決策を検討し始め、採用した方法をここに記録しました。
1. 証明書の有効期限
- まず、期限切れの署名証明書を更新または再生成する方法はありません。証明書が置き換えられた場合, バージョンをインストールする前に、最初にインストールされたアプリをアンインストールする必要があります. アプリが既にアプリ マーケットにある場合, 一貫性のない証明書を含む APK ファイルを更新することはできません. 一部のアプリ マーケットは、作業命令は更新を申請しますが、ストックユーザーは新しいバージョンを更新する前に常に元のアプリをアンインストールする必要があり、その影響は非常に深刻です。
- 署名証明書を生成する際には、指定された有効期間に注意する必要があります. デフォルトの有効期間は 25 年です. Google Play にも厳しいルールがあります. 有効期限が変更されたわけではありません.何の問題もありません。
二、解決策
これは、Google が提供するソリューションでもあり、 Android 9.0 以降に導入されたAPK 署名スキーム v3です。
Android は、次の 3 つのアプリケーション署名スキームをサポートしています。
- v1 スキーム: JAR 署名に基づく
- v2 スキーム: Android 7.0 で導入されたAPK 署名スキーム v2 。
- v3 スキーム: Android 9 で導入されたAPK 署名スキーム v3 。
署名スキーム v3 は、v2 の拡張バージョンと見なすことができます. 圧縮されたパッケージ全体をチェックする検証方法を引き続き使用します. 署名は APK 署名ブロックに保存されます. 違いは、v3 スキームが複数の証明書をフォームに保存することをサポートすることです.これにより、古い証明書の署名を署名ブロックに追加し、署名キーのローテーションの方法で署名の置き換えとアップグレードを実現できます。
このように、ユーザーが v3 署名方式で署名された APK に更新すると、Android 9 以降で、APK は APK 署名方式 v3、v2、または v1 に対して順次検証されます。古いプラットフォームは v3 署名を無視し、v2 署名を検証してから v1 を検証しようとします。初めて APK を更新する場合、ストック アプリはまだ v3 署名スキームを使用していないため、古い証明書の v2 および v1 署名が順番に直接検証され、v3 署名の検証が開始されます。
3. v3 署名方式プロセスの更新
1.署名鍵のローテーション
新しく生成された署名証明書と古い証明書ファイルを準備し、次のコマンドを使用して署名キーをローテーションし、系列ファイルを生成します。apksigner を生成するにはAPI 28以降を使用する必要があることに注意してください(v3 署名方式は Android 9.0 以降でサポートされています)。
apksigner rotate --out *lineage --old-signer --ks *old-signer-jks --new-signer --ks *new-signer-jks
- *lineage : 生成された系統ファイル パス、たとえば d:\lineage
- *old-signer-jks : 古い署名者証明書のパス
- *new-signer-jks : 新しい署名証明書のパス
注: Window 環境では、対応する環境変数 Path を構成して、ディレクトリを切断せずに apksigner コマンドを直接使用できます。
2. APK 署名
リネージュ ファイルを取得する前の手順を完了したら、次のコマンドを使用して APK に署名できます (API 28 以降)。
apksigner sign --ks *old-signer-jks --next-signer --ks *new-signer-jks --lineage *lineage app.apk
- *系統 : 前のステップで生成された系統ファイル
- *old-signer-jks : 古い署名証明書
- *new-signer-jks : 新しい署名証明書
- app.apk : 署名する APK
入力が完了したら、確認し、プロンプトに従って古い証明書と新しい証明書のパスワードをそれぞれ入力すると、APK の v3 署名が完了します。
3. APK 署名の検証
署名後、検証リンクに到達したら、APK 署名が成功したかどうか、署名情報に問題がないかどうかを確認する必要があります.ここでは、より直感的な方法を使用します.各 API バージョンで取得した APK 署名証明書情報を表示します.検証を提供する方法として、次の 2 つのコマンドがあります。
apksigner verify -v --print-certs app-name.apk
apksigner verify -v --print-certs --max-sdk-version [sdkversion] [apk]
-
コマンド 1 は、使用している apksigner の対応する API バージョンでサポートされている署名スキームの最高バージョンの証明書情報を表示するために、より一般的に使用されます。
-
ここでは、APK 署名情報を完全に検証する必要があります。使用する必要があるのはコマンド 2 です。これは、APK
--max-sdk-version [sdkversion]署名が検証に合格することを確認するために apksigner によって使用される最高の Android フレームワーク API レベルです。APK の署名スキームのどのバージョンの署名情報を検証する Android バージョンに対応する携帯電話として理解できます。
栗を持ち上げる:
apksigner verify -v --print-certs --max-sdk-version 22 app-name.apk
apksigner verify -v --print-certs --max-sdk-version 26 app-name.apk`
apksigner verify -v --print-certs --max-sdk-version 30 app-name.apk
- Android 7.0 (API 24) 以降は v2 署名メカニズムをサポート
- Android 9.0 (API 28) 以降は v3 署名メカニズムをサポート
- sdkversion = 22の場合、Android 5.1 は V1 署名スキームのみをサポートするため、Verifies の v1 スキームのみが true になります。そのため、このバージョンの Android フォンは v1 の署名情報のみを検証し、APK はストックを正常に上書きしてインストールすることもできます。アップグレードするアプリ;
- 同様に、sdkversion = 26の場合、v1 と v2 の両方が true になります。ここで、API 22 と 26 の場合、取得した APK 署名情報は同じであることがわかります。これは古い証明書の情報であり、古い証明書が正常に継承されたことを示しています。
- sdkversion = 30、v3、v2、および v1 の署名スキームがこの時点で同時にサポートされる場合、取得した署名情報が上記の 2 つと異なる場合、それは私たちの新しい証明書の情報です。証明書を正常に完了 Android 9.0 以降のプラットフォームのアップグレードおよび交換では、この証明書の情報を検証に使用します。
- 注: keytool -printcert -jarfile app-name.apk を使用して APK 証明書情報を表示することはお勧めしません。keytool は Java JDK が提供する証明書管理ツールであり、JAR に基づく APK の v1 署名情報しか表示できないためです。サイン。
拡張: 一部のアプリでは、ランタイム署名証明書の検証が行われます.ここで取得した証明書情報は、実際には v1 の署名情報であるため、ストック クライアントが上書きされて更新された後に取得された証明書情報の不一致を心配する必要はありません.以下は、弊社アプリで証明書情報を取得する方法であり、テスト後、正常に上書きインストールすることができます。
PackageInfo pi = packageManager.getPackageInfo(packageName, PackageManager.GET_SIGNING_CERTIFICATES);
SigningInfo signingInfo = pi.signingInfo;
if (signingInfo.hasMultipleSigners()) {
return signingInfo.getApkContentsSigners();
} else {
return signingInfo.getSigningCertificateHistory();
}
相互激励！
参考＞ https://developer.android.google.cn/studio/command-line/apksigner?hl=zh-cn