Question

I know there are plenty of questions about this on here, but I've tried everything (but the correct 'thing', obviously!) and nothing seems to shine any light on the problem I'm having.

I've written an app (for a customer), which is designed to be hosted on their own server. The app references a simple text file with the latest version code in it and checks it against it's own version. If it's out of date it goes off and downloads the update. Everything is working as intended up to this point.

I use the:

Intent i = new Intent(Intent.ACTION_VIEW);
i.setDataAndType(Uri.fromFile(outputFile), "application/vnd.android.package-archive");
i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(i);

...code to start the install process of the newly downloaded .apk file. And that all starts as I would expect.

I click on "Install" - when I'm prompted to confirm the overwriting of the current app, with the new. It starts, and then displays:

App not installed. And existing package by the same name with a conflicting signature is already installed.

Now I'm aware that Android can't have multiple applications sharing the same package name, which is fine, but nothing comes up in LogCat and I can only assume that the OS is annoyed at me attempting to 'update' my app, even though I'm going through all the correct channels and using the inbuilt package manager to do it for me!

Can anyone tell me what the OS is moaning about? I'm not attempting to install two apps side by side, I want it to update it, which it starts to do, and then gets really confused.

Is it something to do with me using the same keystore for signing the packages? I highly doubt it as I've used the same keystores previously to handle updates to games and the like, but I just can't figure out what it's complaining about.

Hopefully someone out there has had this issue and solved it, and can point me in the right direction. I'm flying a bit blind with the limited information it's giving me :(

Cheers.

Was it helpful?

Solution

You have built the new and old versions using different signing keys; likely you either built them on different machines, or one is a debug certificate and the other a release one. When this happens, you typically have to manually and explicitly remove the old version before installing a new one with a different certificate - it's basically a safety measure against inadvertently installing a trojanized imposter update.

Note that you can move certificates between build machines (and may have to if you turn the codebase over to the customer), though you will want to be careful when doing so.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top