3

I discovered a strange situation appears to happened a lot to the my application users (via Crashlytics/Google Analytics reporting..) which I did not able to reproduce:

after my package been updated - the version code returned by the PackageManager class is different then the one returned by BuildConfig.VERSION_CODE :

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

boolean versionMismatch = packageManagerVersionCode != BuildConfig.VERSION_CODE;

I spared most of the logging, bureaucracy, and encapsulation for simplicity, but the results are:

  • packageManagerVersionCode equals to the right updated version.
  • BuildConfig.VERSION_CODE equals to the version the app was before the update.

important points that needs to be mentioned:

  • my application is pre-loaded as a system app on the device firmware
  • my application is updating itself (it have the required permissions..)

my assumption currently is that because the original APK is installed in the system/priv-app partition, and the update is not on the system partition, then there is a point in time after the update that the process of the original pre-loaded app is still alive in some aspects. I don't have any way to confirm this assumption, and did not found any official reference whether or not such behavior can happen.

you might wonder why do I care about this version code mismatch, and how I originally got the idea to do this validation: it all started with a crash we were having for production users after we changed in a new version one of the BroadcastReceiver's name (from refactoring purposes..) that registered in the Manifest.

we stopped having the crash when renamed again the receiver back to the original name it was called in the original pre-loaded version, so we suspects it have something to do with this version code mismatch..

My Questions are:

  • Why this version mismatch happen?

  • Can I do anything to prevent it from happen? or at least to make sure components from the original pre-loaded app will not be active?

  • Is my assumption about why it happening is correct?

Community
  • 1
  • 1
Tal Kanel
  • 10,475
  • 10
  • 60
  • 98
  • "at least to make sure components from the original pre-loaded app will not be active?" -- you could try listening for [`ACTION_MY_PACKAGE_REPLACED`](http://developer.android.com/reference/android/content/Intent.html#ACTION_MY_PACKAGE_REPLACED) and if you see the version code mismatch, terminate your process. This is just an idea, as I have never dealt with pre-installed apps personally, so I don't know how "the rules of the game" differ for those compared to ordinary SDK apps. – CommonsWare Apr 01 '16 at 12:28
  • @CommonsWare: thanks for the advice. actually I do listen to ACTION_MY_PACKAGE_REPLACE because I need to run specific code after the package been replaced, so terminating the process is not an option – Tal Kanel Apr 01 '16 at 12:30

0 Answers0