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.
Related
I am wondering what is the best way to have two different versions of an android app. I would like to have version of my app with ads and one without ads (the paid one). What is the easiest way to achieve this ? I have found something called version flavours here but since I am new to android development I am not sure if that is what I want. Please any suggestions for addressing this ?
You could have two versions of the application in Play store. However, you would have to maintain these separately and it is frustrating to upgrade from free to paid with this approach. If you chose this way of maintaining your application, you would have to have two projects, one for each version. This would result you into having two copies of almost identical source code.
One approach I've seen people do is that the free version also contains the premium features which are unlocked once the user installs a paid unlocker application from the store. However, this has the same result as the first option: you would have to maintain two applications (this time different, though) and the users would have to install additional software.
The best option is to include the premium version as an in-app purchase. The app would contain all the premium features but would be locked by default. Once the user pays for the in-app product (in this case the premium membership), he would unlock all the features.
You can read more about in-app billing here.
Why not just publish two apps with the free one as this :
MyApp
and the paid one as this:
MyApp(Paid).
And this is how to prepare them:
Get your app working, and add ads and then sign it and generate the apk. Publish it. MyApp.apk
Then go back, and remeove the ads, change the package name, add the Paid to the name, and then sign the apk. MyApp(Paid).apk
Then Publish it.
Some free applications can often be upgraded to paid premium versions. Is there a known packaging pattern so that the paid app replaces the free apps, and therefore gets all data the free may have stored ?
I understand that since app is identified by its unique fully qualified name this is impossible for an app to see data from another, but I kinda recall already seeing this. Or does it mean that I have to consider the two apps as completely distinct, and foresee an export/import feature mechanism ?
(this question is not related to the actual development of those two flavours, which can be achieved in many ways, but rather to the way app should be packaged)
Is there a known packaging pattern so that the paid app replaces the free apps, and therefore gets all data the free may have stored ?
No, the package names must be unique. Thus, one app does not "replace" another app and gets its data.
Or does it mean that I have to consider the two apps as completely distinct, and foresee an export/import feature mechanism ?
Yes, two apps are distinct. However, they can still exchange data.
These are common methods:
Publish one (free) app which contains all functionality but only has the free functionality enabled by default. Publish an additional (paid) app which serves as an unlocker. Your free app can check if the unlocker is installed and enabled the paid functionality accordingly. It is recommended to check the package signature of the unlocker app, e.g., as described in the answers here.
Similar to above but use in-app purchases in the free app instead of an additional unlocker app.
Publish both a free and paid app as self-contained apps. You can implement a ContentProvider to transfer data from the free to the paid app. Of course you can implement other export/import methods as well. However, using a ContentProvider with permissions makes it easy to automatically and securely copy the data, e.g., when the paid app is started for the first time.
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?
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.
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