I sell a game on Google Play called Quantum-X. Not many people have bought it so I want to move to an ad-supported model and make it a free download.
But I want to reward the people who did buy the game by disabling advertising. So existing users see no ads, new users see ads. I can store a flag in some obfuscated, device specific way which makes this determination.
But in order to this I need to tell the difference between paying and non paying users.
So how do I do this? I have a few ideas but I don't know if any of them are viable:
The old app wrote some preferences out. I could look for an old preference and set the flag. But this will not work if someone installs the app on a clean device since they won't have that preference. It is also an exploit since anybody could put the old key in to fool my app into disabling advertising.
My pay app currently uses LVL to validate a person's licence. If I make my app free, what happens when I call LVL? Does it respond LICENCED even if a user downloaded it for nothing? If I could tell paid from non-paying users from the response then I know how to set the flag. But LVL is a pain to test since I would have to upload the app, set it to free and then see what difference there is in the result and there may be none.
I could produce one final update of my pay app which sets the flag and asks users to upgrade. Then I could roll out the app free in a month from now. The same problem exists as with 1. that some users may not update or may install onto clean devices.
I could produce two apps on the store. The pay app could be renamed to "Quantum-X legacy" and a new Quantum-X goes in its place which is free. I would update the legacy version to install the flag, but people would have to switch to the new version for continued support. This would work but it's a lot more effort.
None of these are pretty although 2. would be the least amount of work. Has anyone experience of a working solution, or know a some better way of doing this?
EDIT: My intention is now a hybrid and I've begun to do this:
Rename the old app as Quantum-X Legacy and update the description.
The new free version is called Quantum-X. The only fly in the ointment here is that I must update the app package in the manifest to make the two apps distinct.
I intend to put a test into the free version that calls LVL using the old app's key. If this works the way I think it will, it will tell me when a user has bought the old app (since the licence server is being asked about the old app), and I can write out an obfuscated flag somewhere so I don't have to call LVL any more.
Free users carry on but with ads.
I'm up to 3. and this is my intention. If LVL doesn't work, then I might have to put out an update to the legacy version which writes the flag or puts a code out on screen that someone must use to enable adfree when they install the other version.
Related
We are planning on changing our currently paid app, into a "free" (demo) app with in-app purchase to unlock the full game.
Our problem with making this transition is that we already have customers who've paid for the app. We therefore need to ensure that they wont have to pay for something they've already bought once. We have looked for every possible solution we can think of, but without luck.
Licensing is out of the question, as it will always return valid for free apps.
Any suggestions will be greatly appreciated. As a fallback we'll have to create two apps, but we would much rather prefer to only keep a single one.
Regards
Jannek
Edit:
Thanks for the feedback. We didn't find a solution, but ended up using the first achievement to unlock the game by default. this covers 80% of our players. Unfortunately also 80% of the pirates. for the remaining 20% we setup a token server, where they can unlock the game by entering the last 8 digits from their purchase info.
This also allows us to give out promo codes on Google Play.
A couple of unsatisfying solutions:
Update the app before you make it free. Collect IDs somehow of people who use it and record them. Downside is it will miss people that rarely update or use your app.
Release the paid app as a new package. Convert the old one into a "pre-paid licence". You can detect whether the licence app is installed or not from the new one. Downside is you lose all your ratings and reviews.
I am going to have a alpha release of my app, which is not yet on the market. I want to have the app APK link sent out to friends via email so they can download it from my site CDN.
One question here: if I want to give them updates, what will be a good way? Can I download the new APK within the app, and somehow install the APK to replace the old one without anything to do with the market? So my friends can have the app upgraded while it is still in alpha release?
When I did it, I used Zubhium -- they were a web service with a small API that you could install into your app, giving you a mini "app store"-style backend and handling distribution for you. It would host and distribute your APK, connect up to their server when the app launched, check for updates, invalidate old versions, gather crash logs for you, etc. It was very good.
Zubhium are now https://www.vessel.io -- I presume they still have the above features as part of their now-much-bigger service, but when I checked you had to give them a credit card number even to sign up for the free plan, so I've not played with it.
A friend of mine uses http://testflightapp.com for iOS, and it looks like they have an Android version now, so that's certainly worth checking out. A quick search also shows up http://applover.me. #Janusz recommends http://hockeyapp.net/features in his comment.
As #Nanne points out in his answer, the Play Store itself now lets you distribute to limited alpha- and beta-test groups. That looks like it has fairly minimal features compared to the third-party services (no A/B testing, etc.), but will be familiar and free. And it doesn't need an extra SDK rolled into your app.
So, my general answer is that there's more than one professional beta-testing API/service that you could use, that they're generally very useful, quite easy to roll into your app, solve all the problems you're anticipating and more, and often have a free plan to get started. I'd recommend picking one of them rather than trying to roll your own solution.
If you want this only to be able to release your app in Alpha, and maybe later in beta, take a look at the android market again.
Check out this link: https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
It boils down to the fact that you can have an Alpha-test, and a beta test, each with selected users. You can upload your app as normal, so you'll have updates via the market, but not everyone can download your app.
For the beta at least, you can select a community that is the source of your users, so all that are in that community could be testers.
This is the best method for testing I believe.
Now I've nearly finished my first app and I wanted to have two versions of it, one free (with ads and a little less functionality) and one full/paid version.
I know that you can not completely prevent apps from being cracked/distributed, but anyway, I'm currenlty having some thoughts about what the best method would be to release the app.
1) Both full and light versions in the store with no additional checks
2) Full version with Google Market license check integrated... Does this really bring any "security"? I've read that this protection has been cracked and therefore is pretty useless?
3) Have the light version and convert it via InApp purchase to the full version? Currently I have no idea on how to implement InApp billing and how to check whether a user paid inApp to release the full functionality and... of course there are also ways around that, right?
How would you do it?
Do you try to prevent your app from being illegally shared, or do you think it's not worth the effort, as any protection can be removed (and then it's shared anyway)?
Just gathering some thoughts :)
I have been through the same thought process and settled on option 3 for new apps.
My reasoning is as follows;
With option 1 you have two apps to maintain, users have to do a uninstall of your trial version and you have the problem of migrating data between the two versions.
Option 2 has all the problems of option 1 plus the headache of implementation.
Option 3 you have the benefit of only one codebase to maintain, users can quickly and easily upgrade with all their data intact and you have higher download stats/ratings for the one app rather than two.
Implementing it has got a lot easier with the version 3 of the billing library. I followed the sample from Google here and got a simple remove the ad's with IAB within a couple of hours.
I personally think that an In app purchase is the most secure way to stop people from getting free paid versions of your app, because when someone inevitably (if your app is popular) release an apk file of your app on the internet, it is just the free version.
I have an app on the market that costs $0.99. I want to implement in-app billing so that I can offer it for free with an option to unlock certain features for a price. I've already modified the code to allow that. Question is... how might I mark the 1000+ people who already purchased the app as having purchased it and unlock all the features?
You might be able to hack your way around this if you're using some sort of persistent storage.
For SharedPreferences, on the first run, do a check for one of your preferences using SharedPreferences.contains(). If it contains it, the app must have already been installed. If not, set another preference that marks the user as new(free), and set yet one more so it doesn't do the check every time.
That might only work if the preference doesn't have a "default" value, I'm not entirely sure if setting a default in xml will mark it as contained.
You could do something similar if you have any assets that get transferred to SD, or any similar one-time setup. Just check to see if it's already done before doing it the first time.
If you're using an SQLite DB, you could increment the DB version and mark as "paid" in onUpgrade() if coming from the current version(or earlier).
Like I said, it's a hack, but I don't know of any "official" way to check to see an app install is an upgrade or an initial install. There are some pitfalls here, though. For instance, if a previous paid customer completely uninstalls before installing the new version, or if it's on a new device...
I have seen so many threads on creating a time bound trial versions for an android apps but none of them seems to fulfill my purpose.
Few days back i Launched the paid version of my app and now I want to come up with trial version which i dont want to be crippled from any side. So i want to have a time bound limitation on the trial version. I have created a different Package name for the same. Earlier I was using LVL and now also I am using the same except that i created new license library and changed the
setValidityTimestamp(extras.get("VT"));
to
setValidityTimestamp(String.valueOf(System.currentTimeMillis() + (5* MILLIS_PER_MINUTE))); in ServerManagedPolicy.
so that i can test if trial version works for 5 mins and then give me the license error. I published it on the app store , downloaded it and then found that it was still working beyond 5 mins. Now i have unpublished it. Can someone help me in creating the better time bound application which a user can run for a week (say). Besides he should not be able to uninstall and re-install it and then again use it permanently. I know if i can write the info to some external file but again the file can be deleted from sd card and application can be made accesible to the user free for lifetime.
Regards
Pankaj
Within the current capabilities of LVL, and the degree of user control over your average handset, there is currently NO way to do this without a server-side component. Once your app is uninstalled all traces (except, as you pointed out, files you may write to the SD card, which are user-visible) are removed, so the only way to check for an uninstall/re-install is to generate a consistent, device-specific identifier and check with a server component that will either reject this as a re-install or accept it as a new time trial. Even this can possibly be spoofed by a dedicated customer (depending on the server-side component behavior), so you would need to engineer your software so that your server-side component is a necessary part of the process (i.e. it isn't just a license check, it is actually part of the application's functionality).
If you come up with something that works I'd love to hear about it, but I'd say you're out of luck.
#Femi is right, you need a server side component to make always work. What I tend to do is publish only a free version, and teh user buys the full version as in-app-purchase. The IAP server is your server side check if the use purchased the upgrade or not. You can store a pref on first use to know when the user started using the app. If users uninstall and install again your app, they get a new trail period, but this is annoying, and few will do it to save a few bucks. If you add a message in the app where you ask user nicely to upgrade, or have ads that are removed once you upgrade, it is a good enough solution.