Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I currently have two versions of an application - a free version with ads and a paid version with no ads. I've had a ton of requests from users to ease the transition from the free version to the paid version, and I'd really like to do that.
One way of doing it is to simply remove the free version, make the paid version free and then add in-app purchasing to remove ads.
My only concern is this: How will I be able to determine which of my users have previously purchased the application? Is it possible to do with Google Play licensing?
There's really no need to remove the paid version (or convert it to free) in order to obtain a free version with IAB, and there are some good reasons to retain the paid version as a separate app from your free one.
One reason is that, depending upon which versions of Android your app supports, as much as ten percent of all devices may not support in-app payments (e.g., because they have an older version of Android Market that does not auto-update and does not support IAB3). That provides an argument for keeping the paid version around.
Also, if a user installs your free app to a device that does not support IAB3, then you can have your app detect that and provide a link to the paid version for them to install as an alternate (to IAB3) upgrade path when they signal to the app that they are ready to upgrade.
And, of course, if you do keep the paid version around, you'll have no problem distinguishing users who have already paid from those who have not.
If you decide to retain your paid version, then you can just add in-app billing to your free version to enable the upgrade to your paid feature set. That will satisfy those users who are looking for an upgrade path that is less disruptive than uninstalling the free app and installing the paid one.
If you have not already done so, you'll probably want to create a project library to hold most of your apps' capabilities, to be shared between your free and your paid versions. You might end up converting your paid project to that very library, and then creating two projects, paid and free, which use that library. If one of your motives for combining both versions into a single free one is concern about maintaining two apps, using a project library could reduce that overhead significantly, although it will not be zero.
In that regard, I have found it useful to create an activity in each of the apps that uses such a project library, which inherits from the main activity in the project library. That main project library activity can be an abstract class, with certain methods to be provided by the activity classes that inherit from it in the APK-generating projects that use it; or, certain methods can just be defaulted in an innocuous manner (rather than defined as abstract) and then overridden in the derived classes within the respective projects. These overrides can be used to tailor the behavior of the project library to the requirements of the specific app (e.g., free vs. paid) that is using it. You can also override pre-defined methods like onCreate(), onResume() and so on to accomplish these same ends of differentiating behavior between the respective (e.g., free vs. paid) apps.
Finally, I would not worry too much about splitting your installs between two APKs, because the free version will probably get the lion's share of those simply due to the ease with which it can be installed and tried, so long as the IAB upgrade process is seamless.
It may be worth noting you can't make the paid version free, it will always have a price tag.
My suggestion would be to add IAB to the free version so users can upgrade from within the app. You can also add a check to look for the package name of your paid version being installed on the device. If you find it, then you can unlock the feature in the free version without the need for the user to purchase the upgrade, as you know they have the paid version installed.
The only problem is, whilst you can persist the flag for the paid version being installed, if they setup on a new device or factory reset for example, when they put the free version on, the flag for pro version is gone and the paid package won't be installed, so they will be prompted to pay to upgrade again. There is no real way to resolve this.
Related
I've already made two different Android projects and they have different package names. They're identical except in the Main Activity where the free version expires after 7 days whereas the paid version checks for a purchase license.
What I want is that when a user installs the paid version then the free version on their device (if it exists) gets replaced by the paid version and also all the user's saved SharedPreferences from the free version move over to the paid version. Is this possible? Or will the user have to uninstall the free version as well as lose all their saved settings?
I read questions related to this and they all talk about using ProductFlavors to create different build variants, but I'm not sure if the purpose of this is just to make the work easier for devs or if it helps in what I'm trying to do.
Yes, if make it like update, replacing old app with new one.
I decided to build a paid version of my free Android application.
The paid version has some extra features. How do I manage both versions?
Is it possible to keep them based on the same source code?
If an application requires unique package name, how do I force paid application to replace free version?
What about db, preferences and other privately stored stuff, how to share them without exposing all data to the rest of the world?
Any advice that will help to manage both projects,
but not answers the above questions directly, is appreciated as well.
There are several approaches:
Put the core of your app in a library project, and create two other projects one for the paid, and one for the free version of the app. An upgrade to the paid version means the user has to uninstall the free version, and looses all the data.
This is the "classical" approach.
Let the user make an in-app payment. The user keeps all database and settings, and you have to maintain only one app.
This option requires extra modules to be included in your app, and extra logic.
Make another dummy/empty app, this is a paid app. The existance of this app means the user has a paid version. The user keeps on using the orginal/free app.
You can simply check by using the PackageManager to see if the paid app is downloaded.
The user keeps all database and settings, and you have to maintain only one app. Ok, there are two apps, but the second can be really small and simple.
You don't have to include additional libraries/code to make an in-app payment. You can also have all your apps upgraded to the 'pro' version with one purchase.
I don't know if all users understand this pattern. For the developper, this can be achieved with minimal work, and the users keep all their settings while upgrading.
I think it's possible and recommended to keep them in same source
code. Otherwise you have to support two versions of app instead of
only one.
If you have only one app therefore you have only one package name.
Create a class responsible for app features availability in current license state (free or paid). This class should store information about license state (free, paid, maybe you will deside to add subscription mode in future in which paid version can expire after some period). Features of your app available only in paid verion shoud check current license state. You can also change app GUI depending of license state. For example hide GUI of paid features, show "Buy" button or ads, etc.
And also if you have only one app that can be free or paid you don't have to share any internal app data between paid and free versions.
I'm having two versions of my app. Free and Pro. I'm going to remove the free version and change status of the Pro version from paid to free and use in app billing to unlock advanced features instead of having two different apps. Users already paid should start off with all features enabled.
Is there a way to check if a user has purchased the app after changing it to free?
From what I have read, LVL can't do this.
Is it possible with IAB v3?
There are several postsbelow here on StackOverflow concerning this topic. The short answer is that there's no fool-proof way to do it.
Some possibilities:
Check for some prexisting object exclusively from the Pro Version(db, pref, etc)
This won't work for new devices, only if it's a simple upgrade on an existing install
Use the old Pro app itself as the "key" to unlock(check PackageManager)
Suffers from the same problem as above, and even uglier
Create a unique id for each Pro customer, save it server-side and check on startup
Necessitates internet access for validation, not very secure, users hate data collection
A hybrid of more than one method would probably work best, but it depends highly on the implementation. No matter what you come up with, there will be some issues, and I don't think there's a way to 100% cover every existing customer.
How to migrate from a paid android application to an application paid for with in-app billing?
Converting an Android application from a free/paid model to in-app paid unlocking
Changing paid Android App to free with In App Billing - grandfathering existing customers
How can I use the paid version of my app as a "key" to the free version?
I am looking to release two version of my app: free and paid. The paid app will have a few more functions but no extra content as such. Originally I was going to release two separate apps on the market but it is proving difficult to keep a single code base and have two separate apps.
Would in-app purchases be a better way to do this? So I release a free app and then allow users to purchase a unlock for the extra functions. This would also mean that I wouldn't have to explicitly use the licensing part of the Android development as that is taken care of within the in-app purchasing.
There are three strategies which come to my mind:
Release two versions, a free version and a paid version. The paid version contains additional features. To make development easier, you should use Android Libaries. These prevent the duplication of code.
Advantages:
Simpler to implement.
Works on other markets as the Android Market because it is not dependant on it.
Disadvantage:
If the user has some data in the free version, you must provide a import functionality for the paid version or the user will loose the data.
You have two versions on the market which get different reviews.
Release two version: a free version which contains all features but some features are locked. Unlock them using a "unlock app" which is a simple paid app released on the market.
Advantages:
Simple to implement.
Works on other markets as the Android Market because it is not dependant on it.
Disadvantes:
Is not that intuitive because the user has a "useless" app installed.
Release one version: a free version which contains all features but some features are locked. Unlock them using in-app purchases.
Advantages:
Finegrained solution: You can unlock different features for different prices.
Disadvantes:
Not that simple to implement, the In-App-API is tricky
Does not work without Android Market
You could also use two separate flavors.
One for the free version and the other for the paid version.
Without rewriting another boss project.
https://developer.android.com/studio/build/build-variants.html
I have an Android app with free and paid versions, where the free version has a time limit, after which it redirects users to the Market to buy the paid version. The two versions have different package names and are submitted to the Market as separate applications.
However, when users buy the paid version, this doesn't replace the free version - they're left with both versions installed at once. I'd like it to install over the free version. Ideally it would also replace any existing shortcuts on the home screen with shortcuts to the new version, but that's less important.
Is there an elegant way to handle this?
You can't have the free version automatically deleted when a user buys the paid one. Only the user of the device can uninstall applications from the phone, and he must do so manually.
If the two icons thing really bothers you, you could always switch to a free version model only, using in-app billing to unlock features or contents in your app.
A popular way to handle this situation is to only release one fully-functional package.
Put all of the functionality into the "free" version, and then release a "Pro Key" which is just an empty package. Then you can add a function to the free version which checks whether the Pro Key is installed. You can then use this function to selectively unlock certain features of the application.
See How can I use the paid version of my app as a "key" to the free version? and Detect if app was downloaded from Android Market for more info about this process.