0

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.

Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

One would be a debug cert, yes, as I'm testing in Eclipse and running on emulators/devices etc. While the actual 'updated' version was exported as a signed app and uploaded to a webserver. Are you saying that, if (for example) I were to uninstall the app manually. Install signed app via adb, then run, it would probably work as intended? I'll give it a whirl.
You sir, are a life saver! Uninstalled from devices/emulators. Installed manually via ADB (signed exported - old version) - Launched and it was more than happy to update. Brilliant help. Thank you ever so much!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.