My app has been pirated recently and I'm trying to prevent further losses in revenue.
I am using an In App Purchase system to purchase the premium version of the app.
Apparently someone bought my app and released a pirated version by doing a backup (where premium= true)
Now i would like to run an IAP check when my app is installed to check if the user really has purchased the premium version.
Is there a way to do this as soon as my app is installed or updated?
UPDATE:
I have to run the IAP without using SharedPreferences as they can easily be backed up and the backup distributed
Why not just check it once a day (or week)? You can set the SharedPreference to the last time a successful check was completed. Of course, you'll want to check for future dates and reject those, since that's what I'd do to get around a system like that. You might want to give a 24-hour leeway on future dates to accommodate for time-zone changing, but it shouldn't be too hard.
This way, even if someone backed up your app, it would only work for the next day or so before checking again.
To be honest, though, this might not help much. If people are pirating your app, they'll find ways to get around (just about) anything you throw at them.
Related
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
I am building an application which I wish to upload to the app store as a paid app. But i would like to post it as a trial app for a set amount of time. I looked at all the options in the app billing version 3. I have found a few problems.
If I create my app with a non-consumable inapp item then i will not be able to keep it for a set duration as a trial app(Please let me know if my assumption is correct).
I f I create it via a subscription based model then is there a way I can make the subscriptions last forever and not yearly?
I think I know what you're asking, but if I'm wrong let me know.
What you want to do is let the user download the app for free, let them use it for say 7 days, then require them to pay for the upgrade IAP (in app purchase) or prevent them using it?
If the above is correct there is one main problem that you're going to encounter. To track the date the user started using the app you will have to use something like a shared preference, an entry in a sql db or some local file etc... The only problem with all of these options is the user can erase the data and install the app again to use it free for another 7 days. The only way around this is to implement your own web registration service which I imagine would be a little too difficult.
The best way, assuming you're not too bothered about the people who will bypass it, is to capture the date/time when the app first starts and save it. Each time the app starts check if they have purchased the upgrade, if not check the current date/time against the stored value and if your trial period has elapsed, prompt them to buy the upgrade or close the app.
The main problem here is the user uninstalling / reinstalling the app and losing the shared preferences.
The easy way around this is to use Google's SharedPreferencesBackupHelper
Android SharedPreferences Backup Not Working
You simply save the install date as a preference. Even if the app is un-installed, if they install it again, the orig install date will still be available for you to query.
I have a customer that has requested a refund (as his 15 minute window in play store has expired). If I give him a refund manually, the play store (as far as I know) will still allow the user to reinstall if uninstalled, and the app will still be on his phone and usable.
I need to know a way around this, something I could code into the app perhaps. I considered having the app grab the device id and upload it to a remote server, and if its in the DB then the app pops up a window and wont run. The issue with this is it becomes specific to that device, if the user gets a new phone, or installs on a different device, it will work.
What could I do to make it so that upon giving someone a manual refund, they cant reinstall. I dont want people being able to get a refund and then just use the app for free.
Ive seen a few other similar questions here about this kind of thing, but they all were closed due to not being programming related. I want to make sure its known that I am asking a programmatic question, as I hope to implement some sort of check into the app.
I want to publish a trial of my app. In this app, the user has to save a lot of values in the sharedPreferences. If he decides to buy the full version, would the trial be deinstalled, and the sheredPreferences would be deleted too? Does anyone know that?
It would be very nice, if the sharedPreferences wouldnt be deleted, so the full version has access to the value of the trial, therefor the user hasnt to save all the values again.
Yes, the SharedPreferences are deleted when they uninstall the trial and install the full.
I see a few options you could use, either use the same app for both and use an unlock style of purchase, either via in app purchase, or by selling a separate "unlock" app.
You could save their settings to a remote server and have the full app download them from there. This one has the advantage of allowing syncing of settings across multiple devices, downside is you'd have to make and maintain a server.
You could save them to some other permanent file on the device, but personally I hate it when an app leaves something behind when I uninstall it.
Is it possible, to publish the trial with a lower versioncode as the full version, so the trial only would be updated and the sharedPreferences wouldnt be deleted?
I've been asked for some review copies of an Android app I've written, which is great, but I'm not willing to give out the full app to just anyone. I want to make a time-limited version (which works for about two weeks, then gives up the ghost).
What is the easiest way to do this? I haven't tested this myself, but I think that in theory if one built the app using a keystore which expires in two weeks might work. Is that correct, or do I have to put a line of code in the app which shuts it down if you attempt to boot it after a set date?
The keystore is not checked after the application is installed; only at installation time is the date verified.
You would have to put in your own time limit code, I imagine. Though if you want to be really paranoid, you could consider that the user could alter their device's clock.
Alternatively, you could do an online check (against time on your server), or make each APK that you hand out have an individual token embedded which gets validated against your server.
I have a simplest suggestion, what if the reviewer buys the application, and you refund the payment?
I just thought of a cool way to do this.
You make a Beta version of your app, and you can define the group of testers, you just need the email address of that person, or a G+ community they can request access to, and then you add them to the Beta program.
easiest way is to hardcode an end date and no longer run after that. it can be circumvented if users change their system time, but that is kind of a hassle to go through.
otherwise, you can have your app check the license periodically by connecting to your server over http, but that requires more work.
This sounds like a great idea. You'd probably want to make the app phone home and verify with a server that a certain amount of time has elapsed. Users can always delete your preferences file on the phone or uninstall and reinstall the app to get around on-phone restrictions.
I believe the keystore approach may also work, but I'm not sure exactly how they work in Android.
Please make this an open source project when you finish - I think this would be useful to a lot of people!
You could use TelephonyManager.getDeviceId() and create a build of your application that would only ever run on the reviewer's phone.
You could either hard code this into the application or have the phone check against your server where you'd store permissions for each Device ID. With the latter case you could have your application display the Device ID when it can't find a license; the reviewer tells you this and then you enter this in your DB.
As per Google: "If you plan to publish your application(s) on Android Market, the key you use to sign the application(s) must have a validity period ending after 22 October 2033. The Market server enforces this requirement to ensure that users can seamlessly upgrade Market applications when new versions are available"
What we did with our developer challenge II entry was when we hit the expiration date any new data we processed was replaced by an expiration warning. So the application functioned with existing data but not with any new data the user entered after the expiration. Since our app processed text messages, setting back the clock was an unrealistic long-term solution for the user to overcome the expiration.
Depending on the type of application your are giving to reviewers, you may have another options.
You code it like a lot of shareware and only let the application run so many times. The code for this would be very easy to implement. Sure the reviewer could delete the data, but not very easily. I don't think they would go through that much trouble for maybe a couple dollars.