For my Android application, I want to release it for free, but with ads. Then, I want to give the user an option to remove the ads for a nominal fee using the PayPal library. That way, I don't have to have 2 separate versions of my application that I have to monitor, develop, etc.
Anyways, after the user pays me to remove the ads, I need to securely store something that indicates that they paid so that it isn't easy to spoof my app. How should I do this? I was thinking of encrypting a string and storing that encrypted value in SharedPreferences. Is that a viable option? If one were to take the apk off of their device and give it to someone else, does SharedPreferences move with it, or is it saved outside of the apk? What about if someone has root access? Can they spoof SharedPreferences?
If possible, I'd like to avoid having to query a server every time the app is launched.
Thank you!
I would argue a few of points:
Refactor your application into a free, ad supported version and a paid version. You can package things such that you'll be able to share almost every piece of the application. Then just post the free and paid versions in the market.
Anyone willing to work their way around your copy protections was never going to pay for your app anyway.
You're offering a value proposition. If the only thing that separates your free and paid version is ads then your app better be something the user can't live without. If you're planning on expanding the paid version with more features then #1 above is probably a better idea anyway.
What you could do is take some unique data from the phone (device ID, app version...etc...) in your app and combine that into a message.
Then use a public/private key pair. The public part can be in your app and the private part you keep with you.
When a user pay for your app, it sends you the string with device ID and so on and when you got the payment, you send back a blob of data containing a certificate.
Your app can verify the certificate against the device ID or whatever your decided to put in there by using the public key.
There are still a lot of details you'd have to work out (how the data is sent back and forth...etc...), but with those kind of tools, you should be able to achieve what you are looking for.
You can look here about how to manage certificates : http://developer.android.com/reference/java/security/cert/package-summary.html
Of course, how sophisticated you want to be depends on your app and how much people will have to pay for. Reverse engineering to bypass all that is certainly possible, but I doubt many people would go through the trouble if they only have to pay $0.99 to get rid of the ads.
If the user is determined enough, they will be able to reverse-engineer your app and get the decryption key, or just patch away your protection altogether. SharedPreferences are stored in a file that is accessible to anyone (ok, maybe anyone will root access...).
In summary, save yourself the effort and don't even try to protect your app... who is going to reverse engineer your app to merely get rid of advertisements anyway?
You might want to skimp on the complicated protections for now and wait until in-app purchase arrives. I'd imagine there would be a secure, reliable solution at that point in time.
Related
Is there any way, to check on server if this is my application sending data or it's someone's who decompiled my app? Note that both my and fake apps may be downloaded by user from Google Play. I have only one idea - in Google Play you cant post two applications with the same package names, so maybe I can send package name to server or something like this.
It can't be done without some help from OS - because an app would not know whether it was modified (the modification check itself can be hacked).
The ways I'd go would be the following:
Excercise the options Google Play Store gives you - license check and app encryption
Add some auth data to the application itself and verify it on the server (some encryption key). The data should change with each version
Accept only 2-5 last versions (for people who haven't yet updated)
This way, any pirated version will be valid for only a week or so... And for someone wanting to use the app constantly it will be easier to buy it, than re-download it every 1-2 weeks.
It won't protect you completely, but will make thievery time-consuming and hardly worth it given the option to buy the app. Enough to convince the users who would have bought the app to buy it. Those who pirate things out of principle can not be converted in any case...
there are some points which can make your code and application more safer.
use proguard(see on android devlopment site) it offuscates(other words makes it messy at compile time) your code.
secondly you could use encryption and decryption send some secret key encrypted
I have an app right now that I am planning to put onto Google play as a paid app. I know that one can decide at a later date to make the app free. I'm thinking that I might one day want to make the app free, selling some of the features that are now included in the paid version. Is there a way that I can tell if a user paid for an app?
The best I can suggest is to put some SharedPreference in your app marks it as "paid", then release a new version of your app which does not have this (when you make it free). Then, you can check the flag to see if it was there before it went free.
The downside to this is that root users may be able to change that value, if they were to discover it. Another downside is that clearing the data would clear the flag.
To avoid those downsides, you could store the data in a webserver database, but this seems like a fair bit of extra work for something like this.
Use a SharedPreference, as Eric suggests, but encode your value; instead of using true or yes, use a hash of the device ID so that no one can post that value for use on other devices. Then you can just recompute the hash when testing this indicator, to ensure it is your own value and not one entered by a user.
I seem to have reached dead-end as to how may i create a proper model which plays well under a scenario that i have in mind.
The scenario is as follows; User purchases an application from Google play. At run-time i request user credentials (Google account associated with current device) which i then transfer to a web-service. At that point the back-end service tries to Auth user and identify if they have actually purchased the application in question and only then return any data relative to the request. (keep in mind that any request in general, as we are talking about a content based application, to the web-service at any point of the run-time life-cycle must always pass through the above pipe).
Now the reason for the above scenario being so specific is for the following reason;
-I would like everything to be managed by the end service rather than having any Auth process running natively as it may easily get bypassed. What i mean is that as long as anyone can decompile the application on their device, inspect the code, recompile it to their needs, have full access to any file if the device is rooted or even be allowed to clear any data related to the application by simply pressing the "clear data" option from android's application settings..... i do not see any other viable scenario other than the one i described above.
Now having said all of the above my problem is that it seems that Google does not like this specific scenario with both Google play developer api and Google+ api.
So i would really appreciate your comments, thoughts and any related materials you may have to offer in regards to the scenario i mentioned and ways to tackle down this problem.
I don't know of any such API that you can use. Why not try LVL, which would make sure that it's actually downloaded from the Android market? And if it's a paid app, the user must have definitely paid for it.
As far as decompiling is concerned, try Proguard. It's not 100% perfect solution, but it's pretty hard to break it.
Now, coming to the content. If you don't want anyone else to steal your content, then encrypt and save it. You can have a pretty good encryption mechanism that works with your web services, which would ensure that it's very very difficult to break.
What's wrong with using LVL and ProGuard? These tools were designed specifically to address your concerns with license verification and reverse engineering, respectively.
And, really don't worry too much about the one in a thousand people who might try to get your paid app for free. If your app is any good, then you'll be making plenty of sales anyway.
If I've read your proposal correctly, that sounds like a gross violation of your users' privacy and would definitely be a violation of Google's ToS. Why would your users give you their private credentials? They aren't supposed to be given to anyone, so why should they trust you or your systems with them? You would also be liable if you got hacked and credentials were stolen.
I'm developing an Android app which should be free to use for a certain period. When the phase of free use ends the user should register and pay to be able to use the app furthermore.
No I wondering how I could archive this, as the user might simply re-install the app to extend the period of free use. So I need a way to identify the user in such a way that he cannot pretend to be someone else or a new user. At the same time I want to avoid that the user has to do any registration if possible before the free use period ends.
At the moment I think about identify the user by his telephone number or SIM card id as he probably won't buy a new SIM card only to be able the use the app for free. The disadvantage of this is that this is limited to devices which are phones so any WIFI tablet won't be able to use the app as it doesn't have a SIM card.
Are there any other options to archive this behavior?
What you want to do is to track installations. This can be done by getting a unique id and then saving it using shared preferences. You could put this into a folder on the SD-card but I don't think I'm the only one getting annoyed by this kind of behaviour in apps. Rather than putting a file on the SD-card want to backup the file using BackupManger and uploading it to the cloud.
You can find info about the BackupManager here:
Data backup
and a short part of this video on tracking installations here, 16:30 min in:
Google I/O 2011: Pro tips
I really recommend you (all) to watch the video as it goes through many rookie and pro misstakes.
When reading about the BackupManager you'll find out that, just as all the other solutions, it wont work on all devices. I don't think this will be a big concern of yours, it will be a small group of people who can work around your trial period ending but there will always be. Spend time on developing your app and making it better instead.
You might want to read this post from the Android Developers blog.
They recommend the ANDROID-ID, though it has it's downsides.
You might want to try:
import android.provider.Settings.System;
..
String android_id = System.getString(this.getContentResolver(), System.ANDROID_ID);
Although some devices apparently return the same value for this, which I think is contradictory to what the API docs say. It's possibly useful to use this as a secondary check.
However do try to take caution in sending personal details such as IMEI or phone number etc back to your server as users rightfully get a little anxious about such things being broadcast. You could always do a hash of the IMEI (if accessible, can't remember off the top of my head) and add this to the ANDROID_ID, creating something that's going to more or less be unique. Maybe hash some other detail in addition to this to really guarantee uniqueness as hashes can and will clash.
Is there a unique Android device ID?
Most voted answer (Joe's) in above is the best approach I have found so far.
I would like to use in-app billing in my android application (instead of creation 2 versions of application - free and pro). If user paid, then additional options in Preferences should be available.
My application synchronizes data with website (not my).
Each time synchronization happens, I would like to check if user paid or not.
How should I do it?
I think the easiest means for you would be to use Managed purchase. More on it is at http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type
The "manage by user account" purchase
type is useful if you are selling
items such as game levels or
application features. These items are
not transient and usually need to be
restored whenever a user reinstalls
your application, wipes the data on
their device, or installs your
application on a new device.
Update: website and API updated refer this now https://developer.android.com/google/play/billing/api.html
There are to many ways to do that, i will try and give you some of the most used
what about user accounts? can your application support users? if it does, its practically solved with 1 user per 1 account. just add a flag to your DB for each user. this is the most secure way, its very easy to know if someone is stealing from you thats why all MMO's (like WOW) use this type of check. you can easily know if theres more then one user on an account as well
the downside is that it requires more processing and some support is case someone's account gets stolen or other user support of that kind.
you can save a sort of key inside your application. and some other key on the server. if the key matches (either 1 to 1 or after some manipulation) then you have yourself a paid user, other you dont.when someone buys the application then change the key on the device.
just do what you dont want to do and have 2 applications for free and paid it will probably be less work then the other 2 list above.
there are many ways of doing what you want. but i'll tell you this:
most applications use method 2 but on the opposite direction, meaning serial key.
i dont think your gonna create an mmo so theres no need for option 1 unless you really dont want anyone hacking your application (which i assume no matter what you do it will be hacked in todays world. i'll advice you to trust those who pay and accept those who dont)
method 3 is just easy in my opinion especialy when you want to just remove menu options, but it also creates duplicate repositories for code.
good luck. what ever you decide is good, make a theft protection, if someone wants to steal it, they will, dont fight it (even PS3 got hacked in the end)