Side effects of changing filter and requirements o

问题:

No previous questions about it, so here I ask.

Background:

I have an old app, in free and paid versions, in the Play Market. I created a new version, radically changed and with a different payment system (free app + in app purchases only, no more a paid version: reduce maintenance costs). minSdkVersion also changed from 1.5 to 2.1.

Because of all those differences, I decided to upload a new app, not just update the current one (i.e., not selectively provide a new apk for API 7+ --- multiple APKs). This is especially important because of the new payment system, as I don't want to force old, paid customers, to buy everything again. I want to leave them alone and happy as they are (4.4/4.7 rating). In short, I don't want to "force" people into anything. In this case, into buying again the same thing through in-app-purchases, besides other things the new app offers.

Questions:

Having explained to you my background, it raises the obvious questions:

1. How do I hide the old apps from the API 7+ audience while still keeping them visible to all the current API 7+ customers, i.e., those that already bought it?

My biggest concern here is the paid app. I'm thinking about pushing a new version with maxSdkVersion set to 6 (SDK 2.0.1), effectively blocking new API 7+ customers to the old apps. But I'm worried that the current API 7+ customers will suddenly lose access to the app. That raises two questions:

2. Will they be able to keep updating the app? is it reasonable to guess "yes"?

3. Even if the answer to the previous question is "yes", it's still unclear to me what will happen if the user uninstalls the app, and then go find it again in the Market (not just updating). Will it disappear or will it still appear under his "bought" apps list, considering that meanwhile the app filter requirements changed?

Remark: I would upload a test app to see that, but AFAIK the author is not allowed to buy his own app (even the license behaves differently), so I couldn't test the uninstall-filter-install scenario.

---

---

---

# # # # # # # Reply to answers: # # # # # # #

@Sparky:

I think you got it wrong. I know my way around multiple APKs, and, of course, the documentation. The problematic here is way beyond that.

Note also that maxSdkVersion is deprecated, so this throws a little bit of a wrench into your proposal to cap the old APK when you issue the new APK.

Thank you. I missed that.

Multiple APKs offers a simpler user story.

If you say so (besides the other things I didn't quote), I think you probably didn't wrap your head around this issue. Please follow me:

1. I have n paid customers that bought my current Pro app version.
2. They are using the feature set X that they've got with the Pro version.
3. I decide now to implement in-app-purchases to offer feature set X, Y and so on...
4. Unfortunately, these changes made by app API 7+.
5. Thus, as you so suggest, I decide to offer multiple APKs.
6. Now, the API 7+ crowd suddenly gets updated to this new version of my app.
7. Because they update to the new APK, they LOSE their feature set X. They now need to buy X again (from the in-app-purchase menu). I took from them something they already had, albeit in a "less shiny" way. It's like me saying:

You either pay me again or you lose what you already have.

Do you see the problem now? Do you see why I'm forced to provide a new app? Or am I still not getting what you said (I think not)?

回答1:

Here is an untried idea for your consideration:

• Upgrade your present, pre-in-app-payments app to include a ContentProvider that provides a cryptographic hash that only it knows how to generate in response to a random seed (to prevent replay attacks).

• Release your new app that uses in-app payments as a separate APK, and have it check for the existence of the earlier app on the user's system by attempting to access the ContentProvider just described, passing it a random value and confirming that the response is correct. If such a response is received, then the user owns the old app, and you can enable the corresponding features of the old app in the new app without requiring any in-app payments to do so.

Now, if some of your users skip the upgrade to the old app that gives them the new ContentProvider, and go straight to your new app, they'll be dinged for the payments. But they can then upgrade if they like and run the new app again to get validated.

This does address your issue. However, it has issues of its own. So, put it in your tool kit and see if it comes in handy, as is or in combination with something else you may later devise!

回答2:

You will do yourself a disservice issuing a new app instead of an update without at least considering multiple APKs, because it complicates upgrading your existing paid users.

Suppose you simply update your paid app to API level 7, cut its price to 0 and add In-App Payments. Devices with API level >=7 will be offered an upgrade, while devices with API level <=6 will not be notified, won't see it in Play (Market), and won't be able to reinstall if they uninstall. That would be 'no' to your questions 2 and 3.

But now it is possible to implement multiple APKs: http://developer.android.com/guide/market/publishing/multiple-apks.html http://developer.android.com/training/multiple-apks/

Specific to your issue, you can offer multiple APKs based on API level: http://developer.android.com/training/multiple-apks/api.html

This lets you maintain two versions of the same app, separated by API level. So the answer to your question 1 is, implement multiple APKs per the cited articles.

By publishing a whole new app, your answer to question 2 is 'yes'. By implementing multiple APKs, the answer to question 2 is also 'yes', and your application lineage/upgrade story is a lot simpler from the user's perspective (a bit harder for you technically, easier in the customer service department). Note also that maxSdkVersion is deprecated, so this throws a little bit of a wrench into your proposal to cap the old APK when you issue the new APK.

Likewise with question 3. Either by publishing a new app or implementing multiple APKs, you can keep offering an APK for the legacy API levels that your users can find and install.

Multiple APKs offers a simpler user story. Publishing a new app makes it easier for you to differentiate the apps, if for example you want to say, "Look! Now EXTRA shiny!"