2

私のアプリケーション ユーザーに (Crashlytics/Google Analytics レポートを介して) 奇妙な状況が頻繁に発生しているように見えることを発見しましたが、これは再現できませんでした。

パッケージが更新された後 -PackageManagerクラスによって返されるバージョン コードは、によって返されるものとは異なりBuildConfig.VERSION_CODEます。

int packageManagerVersionCode = context.getPackageManager()
                                .getPackageInfo(context.getPackageName(), 0).versionCode;

boolean versionMismatch = packageManagerVersionCode != BuildConfig.VERSION_CODE;

簡単にするために、ロギング、官僚主義、およびカプセル化のほとんどを割愛しましたが、結果は次のようになります。

  • packageManagerVersionCode 右の更新版に相当します。
  • BuildConfig.VERSION_CODE 更新前のアプリのバージョンと同じです

言及する必要がある重要な点:

  • 私のアプリケーションは、デバイス ファームウェアにシステム アプリとしてプリロードされています。
  • 私のアプリケーションはそれ自体を更新しています(必要な権限があります..)

現在のところ、元の APK は system/priv-app パーティションにインストールされており、アップデートはシステム パーティションにインストールされていないため、アップデート後に元のプリロード アプリのプロセスが終了する時点があると想定しています。ある面ではまだ生きています。この仮定を確認する方法はなく、そのような動作が発生する可能性があるかどうかについての公式の参照も見つかりませんでした。

なぜこのバージョン コードの不一致を気にする必要があるのか​​、また、最初にこの検証を行うアイデアをどのように思いついたのか疑問に思われるかもしれません: すべては、新しいバージョンでの名前の1 つを変更した後に、実稼働ユーザーに対して発生したクラッシュからBroadcastReceiver始まりました。 (リファクタリングの目的から..)マニフェストに登録されています。

レシーバーの名前を元のプリロードされたバージョンで呼び出された元の名前に再度変更すると、クラッシュが発生しなくなりました。そのため、このバージョン コードの不一致と関係があると思われます。

私の質問は次のとおりです。

  • このバージョンの不一致はなぜ発生するのですか?

  • それを防ぐために何かできることはありますか?または少なくとも、プリロードされた元のアプリのコンポーネントがアクティブにならないようにするためですか?

  • なぜそれが起こっているのかについての私の仮定は正しいですか?

4

0 に答える 0