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.
Related
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 have just created a developer account at Google Play. Now I got to upload the application but I have a few doubts:
Can I add more then one android APKs for different applications?
Is it possible to upload an application for a testing and after that set the price of the app?
Is it possible to set such criteria where first 500 users get a free download and then the app will be paid?
Is it possible to delete an app and re-upload it if something gets wrong while uploading?
Multiple APKs for one application:
Multiple APK support is a feature on Google Play that allows you to
publish different APKs for your application that are each targeted to
different device configurations. Each APK is a complete and
independent version of your application, but they share the same
application listing on Google Play and must share the same package
name and be signed with the same release key.
Besides that, with your developer account you can create multiple application projects and provide your APKs for them of course.
No. After you have released an application for free you can not introduce a price for it. You'd have to create a new app project with a different package name.
This is not naturally supported by the Google Play Store. But you could implement this by writing a counter function that synchronizes over the web. You could also crawl/scrape your app page in the Google Play Store to get the install number. There are various ways.
After you upload your APK, there is some kind of sanity check integrated in the Play Store routine. This should prevent that anything goes wrong during the upload. Anyway, you can also upload a new APK, replacing the previous. That's how app updates work.
Your case overall sounds like you could use In-App-Billing to let your users access most functionality in your app for free, and after a certain time period has passed, offer them the full functionality after a payment.
Keep in mind that it is not a good practice to promote your app for free in the Play Store but then hide everything behind a payment wall inside the app.
Updated answer:
You need to have different package names (i.e. different app projects in your developer account) if you want to offer a free and a paid APK. It's actually a common practice and you'll find many apps in the Play Store that have a "free" and a paid "premium" version.
Very often, it would be easier for you to maintain and to update your app if the premium version only functions as a key (i.e. without actual functionality) that unlocks certain features of the free version. Therefore, you can check in your code if the user has installed the premium version.
Still, it would be more elegant to not "pollute" the Play Store with a dummy premium app and by implementing this with an In-App-Purchase of your premium functionality. Here is a good tutorial (besides the Android guide that I have linked above).
1)Yes, your account can have multiple applications. Or did you mean for the same app multiple apks?
2)No, once an app is free it can't have a price added to it later. If it has a price you can change what it cost though
3)No
4)You can always upload a new version, which seems to be what you want here.
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 would like to distribute a beta version of my application to a small group of users. Ideally this would be done through the market to make it easier for the beta testers.
Is there a way to restrict an app's presence in the market? The only solutions I could come up with were:
1 - Have users download the .adk from the web and install manually
2 - Release the beta version as a separate app in the market
The first option isn't ideal as you have to potentially walk the user through allowing apps from unknown sources. Not to mention from a user perspective, you're then downloading an app from an untrusted source.
The second option isn't ideal as you then are potentially confusing other users by having multiple versions in the market, one of which might be flaky. And then there's the inevitable comments about how something doesn't work in the market. I guess you could add some sort of password to that version that you only distribute to your beta testers.
Are there any better solutions?
Market is for public apps only so there is not any good ways to do this. Our app was distributed by email as apk when we where doing beta-testing. Use android forums to get beta-testers.
But, if you insist on using android market. I suggest re-name your app and package-names, and put it into the demo category. But again, I would not used android market for beta-testing.
Perhaps put a relatively high price on it and refund the beta users' money.