When is LICENSED_OLD_KEY returned from server?

Question

The documentation for application licensing describes LICENSED_OLD_KEY as meaning:

The application is licensed to the user, but there is an updated application version available that is signed with a different key.

On the other hand, the documentation for signing strategies says:

If you sign the new version without using matching certificates, you will also need to assign a different package name to the application — in this case, the user installs the new version as a completely new application.

Since applications are identified by their package names, this seems to say that you can't change the signing key for a published application. (Rather, you can change the key and package, but then it will be treated by the market as a new application.)

I can't think of a scenario where it is possible to receive a LICENSED_OLD_KEY response. Am I missing something?

Answer 1

The documentation states that LICENSED_OLD_KEY

...can indicate that the key pair used by the installed application version is invalid or compromised.

Looks like this code was added for cases where a private key is leaked or can otherwise be no longer trusted. Since the current IPC mechanism doesn't even know which public key is used on the client side, I would guess that the whole package name gets tainted. The idea is that in this case an app should ask a user to upgrade to the new version which isn't tainted and should presumably already exist. Since this upgrade would require switching to a whole new different package, how this is supposed to be done is unclear. My guess is that this mechanism isn't really used at all at this point, so the chances of getting this code are very close to zero. In the current version of the official LVL library this code is treated the same way the normal LICENSED response is.

p.s. Also please note that you confuse the keypair used for signing your apps and the keypair used for the LVL service. Those two are completely different and unrelated. Interestingly, with the latter keypair you don't even get to know the private key at all. You get your own pre-generated public key (one per developer) from your publisher console, and that's all you get.