There are a few apps on the market that are set up to have a free main component(which is a trial limited to 7 days lets say) then "recharge" apps that will add a certain amount of subscription time to an account for the user that allows them to keep using the main app. These "recharge" apps are available in the market as well. What I would like to know is how to make it so that once the user has paid for one of these "recharge" apps and used it to add time to their subscription, they are unable to uninstall it and re-download it(for free since they paid for it once). Basically how do I set my application up so that you only get 1 successful download of the app from the market per payment. Once the time has been added to the users account I would like the market to behave as though the "recharge" app has never been purchased.
What I would like to know is how to
make it so that once the user has paid
for one of these "recharge" apps and
used it to add time to their
subscription, they are unable to
uninstall it and re-download it(for
free since they paid for it once).
You cannot prevent them from uninstalling and re-downloading it. At most, you might work out your own mechanism to prevent the app from applying a new "recharge".
Once the time has been added to the
users account I would like the market
to behave as though the "recharge" app
has never been purchased.
This is not possible. In fact, it works in the reverse -- the user will forevermore be able to download it, on as many devices as they want, so long as they are using the same Google account for each device. Purchases of apps are for the lifetime of the Android Market, not for a developer-selected lifetime.
Check out the new in app billing functionality, you may be able to leverage some of it's functionality to sell additional functionality/subscription time.
Setup a server and once the user downloads the app, on the first start the app shall connect to your webserver and send the IMEI oder device serial number to the server and the server will send a code which enables all the features.
Since the date of the first activation is stored on your database on your server, the user won't be able to change it until he puts in a new SIM Card (hence changing his IMEI number) even if he redownloads the application several time, the IMEI basically never change unless you change the SIM.
Related
I have an app that has in-app purchases where users can purchase set of videos and there are ten of these sets. Now, before they do this they have to sign up for this app using their personal e-mail (not necessarily their phone's primary e-mail).
Since they have to log in this app, I was planning that they get the right to open the app and the set of videos they purchased from whatever device they use.
Problem:
After thinking about this and since this app is only directed towards local audience, I am afraid that users will pass their accounts to each other and my customer number will decrease.
Solution I thought about:
I will put a message when the users buy the set of videos that says: "These videos will only be viewed from the device you download it on". Which means I will use certain flags to ensure that an account will download them once. So that if someone is to share an account s/he won't be able to download because they where already downloaded.
Question:
If I do like this then if the user uninstalls this app, s/he will lose all the videos they purchased. Thus, if they install it again, they will have to buy the set of videos again. I am not sure if professional apps let the users have what they purchased back if they reinstalled the app or not.
So, is there a way that I can still use the solution that I thought about and still have my users regain what they bought before they uninstalled the app? Or do you have a completely different suggestion that can solve my problem.
Account sharing is a big topic. Daily business for Netflix and Amazon.
I'm not a big fan of your solution because of all the restrictions. I would suggest following approach:
User signs up in your App
You create a unique ID on the device (GUID - https://developer.android.com/training/articles/user-data-ids)
You store this data on the database plus the GUID on the device
You can now verify that the user has valid access.
I would suggest adding another field like max_guids=2. So that if the user looses the device he can still access his data (yes, this also means 1 single device sharing is possible, therefore you can detect irregularity with login sessions and ban the user).
Sounds better?
I have an Android app and I also offer 1 inapp purchase to unlock such app to the Pro version.
I know how to do use the inapp purchase API and such but I found discordant ways on how to check if the app should start as Free or Pro.
Many people suggest that after a successful purchase the app should store the Google Play receipt or other information in a local database and let the app check the presence of that information at startup (in order to start properly as Free or Pro)
My question is, instead of bothering saving the purchase information and retrieving it from a local database why not calling the restore purchase API RestorePurchases(), have a look at the returned object if the InApp item is present and unlock the app accordingly?
As far as I know the call doesn't require internet connection, it's just a local call to the local Google Play authority... am I missing something?
Let me explain how we manage it at QuitNow!, an app with the same behavior than yours.
We only have one SKU called unlock_all_pro_features. If the user has it, it means that the user bought the PRO features before.
So, in the Android side, everytime the app is started we try connecting to IInAppBillingService. When onServiceConnected() is called, we ask it for all the user owned SKU's. If it has our lovely SKU, we store in a SharedPreference that the user was a PRO one. And then, if it wasn't PRO before doing all this magic, we update the screen to show the brand new features.
Bad things there: the user can return the SKU!
To face that, when we consider that a user was a PRO one, we also ask if the user has the needed SKU. If that check fails 20 times, we reset the features to the FREE version.
Why checking it 20 times instead of just one time? Sometimes, we found that the service said that the user had any SKU, while he actually had the PRO one. Why? Don't know. So, checking it 20 times is a simple way to assure that we don't kick PRO users when unneded.
I have a paid app in the Google Play Store. I'm considering reducing the price of that app (somewhat; not all the way to free) and offering one of the features as a separate in-app purchase.
If I did that, I wouldn't want to yank the feature away from anybody who's already bought it.
Is there any way to figure out either the date that the user bought my app, or the original version of the app that they bought, or something like that? I'd like to say something like, "If the app was before the price change (either by date or by version), they should have the feature for free; otherwise, require IAP to unlock the feature."
For example, iOS does have a feature like this; the app receipt includes an "originalVersion" field which can be used to control access to features.
Unfortunately for your customers, this is impossible. There is no API call or anything else to Google Play where you can get the time on which the app was bought.
I know there is an android-publisher API in existance, however it doesn't offer any feature to check that.
The functions you want to use are not public availible and only used by the Playstore internally!
Workarounds which you could do:
1. Get the time the app was installed
On the first start you could check that and unlock the features.
Warning: This system could be abused by changing the time on the device
long installed = context
.getPackageManager()
.getPackageInfo(context.getPackageName(), 0)
.firstInstallTime;
2. Give users free keys
You could give every user who's using the app atm a free key via mail or push notification
3. Unlock the inapp purchase now
Publish an app update which unlocks the inapp purchase for free. After a few weeks you could pusblish your new version with the lower price and just unlock the features as if your current customers had bought your extension.
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, 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).
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. For that reason you should:
4. Provide Support
In the about or FAQ section of your app and on first run of your new version set a support mail adress which customers can use if they have any problems because the new features were not unlocked for them.
They could provide any proof (bill) for their purchase.
Like I said, those ideas are workarounds, but I don't know of any "official" way to check to see an app install is an upgrade or an initial install.
Your best option may be a combination of those four.
FYI: I've opened a feature request/idea in Google Cloud Connect for work which you could vote: https://connect.googleforwork.com/ideas/9392 (You can only vote if you have a paid Google Buisiness Account)
I hope this helps you at least a bit.
As far as i know, the best you can do is find the date it was installed. http://developer.android.com/reference/android/content/pm/PackageInfo.html#firstInstallTime
This is what I am trying to do:
Put an app into a free beta
Make the user have a time limit on how long they can use it for "Beta Testing" (Time Bomb But this is easy to get around)
After the users beta time is up (Say 30 days) when the user enters the application [Or better yet they get a screen pop up when they start their phone]a screen pops up saying a message about beta being over, if you like our product please purchase the paid version.
So what I am doing is making a 30 day trial period on my application.
(I'm almost sure this has been done before, I'm wondering how to do it myself)
Probably the easiest way to detect the end of the trial would be store the current date using Preferences when the app first launches, and then compare that stored date with the current date (from the phone or from the internet) on every subsequent launch.
The user could just clear the application's data from Settings, or uninstall and reinstall the app, however, and it would start working again.
One solution to that is to have the app register the device, or the user's google account, with a server of yours on first launch, which the app connects to, to request permission on each subsequent launch.
A cheaper solution would be to design your app so that clearing its data or uninstalling and reinstalling it is enough of a chore to discourage users from doing it; for example, prevent exporting data from the app within the trial, so that the user has to choose between either paying or uninstalling the app and losing all their work.
I am making an app.Which has a free trial version and a premium version.The free version runs as premium for 7 days and after that it will prompt user to buy premium and exit.To do so I have come up with some ideas such as:
1)Identify the device uniquely and send that unique id and date to a server.And on start up check if this device's app is more than 7 days old if so block it.And when the user uninstalls the app and installs again upon registering to the server the app will be blocked.I have read about some ways of identifying a device uniquely.But as this link suggests none of them is reliable and won't work on every device and OS version.
2)I can write a file to sdcard indicating the app installation and check for that particular file on first run to detect re-installation.But that file can be easily deleted by the user and the app re-installed thus obtaining another trial for 7 days which is not acceptable.
Is there a way I can attain my goal?
These things can be done but, I encourage you to think again. What you're proposing is not good for your users and not good for users usually means lower app sales.
The app has to check with your server every time it starts. So I can't use it if I have no data connection or your server is down? Even if I paid for it?
Whatever you do, it can be defeated, especially if using date bound stuff.
I recommend that you think about adding value to the premium version, which is not in the free version, that will encourage people to buy. Or support the free one with advertising, which a lot of people will gladly pay a reasonable amount to get rid of. I recommend NOT releasing a free version which is in someway crippled but rather to make your paid version valuable to the user.
My suggestion is that -
Trial version -
Send a time stamp key(a key as hex string which holds current time and device serial number and trial or premium id) to the server when it is started. In server if any key is not stored, that means the app is started first time and save it for future checking. Server will send a time stamp key(key with server current time) to the device. And device will save this key in local database.
Next time when the app wii start again, the key will be sent to server and server will extract time and serial number from key and check with the first key(as identified first launch), if it exceeds 7 days as identified that the app has been expired.
If network is not available don't start the app.
Premium version -
Extract the trial or premium id from key, it is premium don't expire the app just keep continue the app.
It will work for all cases if user change the device time won't hamper this logic.