Home/ Questions/Q 8030185
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T00:41:06+00:00

No previous questions about it, so here I ask. Background: I have an old

  • 0

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)?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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!

    • 0