強化後のアプリケーションのクラッシュを診断する方法

候補と再現条件を修正

同じ名前のファイルは、異なるビルド、署名 ID、または保護設定からのものである可能性があります。パッケージ、バージョン、証明書ダイジェスト、ファイル ダイジェスト、保護構成、デバイス、システム、およびインストール パスを記録します。

一致する保護されていないベースラインを準備し、同じアカウント、ネットワーク、データ状態、起動エントリを使用して再現します。条件が一貫していない場合、帰属の信頼性が低くなります。

• ファイルと署名 ID を修正しました
• デバイスとシステムのバージョンを修正
• 同じインストールまたはアップグレード パス
• 同じアカウント、ネットワーク、データ

最も初期の分岐アプリケーション起動段階を見つける

アプリケーションの起動をプロセスの作成、アプリケーションの初期化、ContentProvider 作業、クラスの読み込み、ネイティブの読み込み、最初の画面のリソース、およびビジネス エントリに分割します。候補が最初に分岐した場所を記録します。

多くの場合、最後のエラーよりも最初の違いの方が役に立ちます。その後の障害は二次的なものである可能性があり、最後のスタック フレーム付近の設定を変更すると、実際の原因が隠れてしまう可能性があります。

通信事業者ごとに共通の互換性ポイントを確認する

Java および Kotlin の場合、リフレクション、動的読み込み、シリアル化、注釈、および名前に依存するエントリを検査します。ネイティブ コードの場合は、ABI、依存関係、JNI の登録、可視性、および初期化順序を検査します。

リソースおよびサードパーティ SDK は、マニフェスト、ファイル パス、整合性チェック、WebView、ホットフィックス システム、または独自の改ざん防止ロジックに依存する場合があります。一度に 1 つの変数を変更します。

• リフレクションと動的ロード
• JNI の登録と依存関係
• Manifest とリソース パス
• 第三者によるセルフチェック

修正後にリリース範囲に戻る

1 つのデバイス上の 1 つのクラッシュを削除しても、その再現ポイントのみが解決されます。同じ候補 ID でインストール、アップグレード、アプリケーションの起動、重要なビジネス パス、ターゲット システム、およびロールバックを再実行します。

利用できないデバイスまたはシステム バージョンを、対象外でリリース範囲が狭いものとしてマークします。別のバージョンの証拠は、欠落している互換性の範囲を置き換えるものではありません。