How to prevent some users from upgrading application from Android market?

Question

We have an application, that can itself be downloaded for free, but works with paid, licensed data. Some users buy particular version of the data while others buy right to use latest data for some period of time. Now as the application evolves, it eventually stops supporting data older than some date. So obviously users who have those data licensed, but no license for newer data don't want to upgrade. But if we publish new version on the market, they would see it and if they upgrade, they will have trouble downgrading back to version that actually works for them.

So can we somehow instruct the market application not to offer upgrades for particular user or some hack to achieve that end?

We currently use mechanism completely independent on the market to sell and check licenses for the data, but could consider different mechanism (like the android in-app billing support or something) if it could help solving the problem.

Answer 1

The way I see it, you have two options to "disable" upgrades:

• Use a different signing key - this will prevent installation without removal of the previous app, but upgrade notifications will still appear (I think)
• Use a different package name - this will prevent upgrades since it is a completely separate app so far as the market is concerned, and also has the side-effect that old versions are still available for those users who are licensed for that data version.

The second option may be a better match since you can roll out upgrades if necessary for bug-fixes, but can also ensure that wholly new versions are not detected as an upgrade.

---

EDIT:

Totally agree that the above options are cumbersome and don't really solve the issue as-is.

As you mentioned however, you could use in-app billing, but given the nature of your requirements, you'd have to use unmanaged purchases which means you'll need some infrastructure to manage authorising purchases and preventing people from buying the same license too many times.

I'm guessing you've already got much of that infrastructure in place to handle distribution of the data though.

Answer 2

Can the data not contain a "format version" number at the start of the file?

Then you can program the app to read version 1 files, a new app needs more fields on the data source, so you create version 2 data, which adds extra fields, version 1 app see's the data needs a newer app, so tells the user to upgrade.

Version 2 app should know how to read version 1 files and version 2 files (perhaps create a reader Interface and implement loaders for the different versions of files.)

You'll have to handle the missing data in v1 / old files in the loader in the v2 app. The loading of older files is the nicest way for the customer as the app shouldn't just stop working after an upgrade.

If you keep a copy of each format's data you can quickly run tests to check the new version's loader can load each file correctly, plus if the app has a bug in there you won't have to fix several app versions, just the current one.

Answer 3

Ok.. I saw one of the posters suggest you have a way to read the old data.
First that's likely the best option but as you say your apps a mess. You should invest some time in migrating your data reading/writing to an abstraction layer. The pain your having on a (likely less than 4 year old project) is only going to get worse.

Okay.. so here's how I've dealt with it in long lived apps..

Create a migration path.. Create a new class call Migrate. In it have several functions to convert the version of the file from n to n-1 convert_1_to_2(fileName){check the version and upgrade data.) convert_2_to_3(fileName)...

I suspect you have your old code, and you could write a method to convert one bit of data to the next.. When you add new features to the data, then you create a new convert.. No knowledge of the earlier ones would be needed, and everything would be nice and self contained. You could even have sub migrations, so part way along the dev cycle, you could have convert_3a_to_3b.

Now... you could archive the original version of the data in case the user wants to go back.