I am debugging an Android 13 system where a system launcher app (originally shipped within the system partition) is updating itself through the PackageInstaller API. It might be worth noting that for some reason, all versions of the app have set versionCode to the same value. This basically prevents package manager from comparing version numbers, making it agnostic whether its an upgrade or downgrade.

The whole setup seems to be triggering a strange behaviour.

Initial situation is like this: Version A of the apk is stored in /system/app, version B is already installed in /data/app, successfully.

The chain of events, from what I can tell:

• Version B of the app tries to upgrade itself to version C. It provides an apk file and calls the PackageInstaller API.
• As a first step of the upgrade, version B is killed and removed.
• Now (it seems) ActivityManager detects that there is no foreground activity, selecting version A (from the system partition?) to be started
• The app startup does not look glitch-free, from logcat it looks like the app is killed and started a few times.

Obviously, I am describing a design where different issues are already being identified as not being optimal, or even questionable. However, I would like to come to a better understanding first.

• have effects like these already been documented on the Internet somewhere?
• is there a single, clear violation of Android API specs that is causing that mess?
• How to fix this situation? Would it help to make the installation staged, which I assume leads to an update on the next reboot? How to do so from within Android Studio? SessionParams.setStaged() does not seem to be available there...