I am creating an iOS and Android App and I want to create a screen where the player can start with a guest account or can connect his account with our own accountsystem.
But my question is: Can I detect a user after the app was uninstalled and installed again?
I know that there is something like the vendor. But this will change.
I know that other apps also can do this.
With the user's permission- have them log into an account. Or provide you with their google of facebook account info. So far as hardware ids, those are discouraged and actively being removed to prevent people from the API to prevent this.
Also remember- that unless the user logs in with an account, you don't really know whether it is the same person. You could know its the same phone, but you don't know if he gave it to his kid sister to play on. Or sold it when he got a new one, and now you've given the new owner access to someone else's account. Also, if you rely on hardware ids you won't know its me when I buy a new phone and download it on that.
So yeah- either have him log in with a username and password, or use a 3rd party signon mechanism like Google or Facebook.
For iOS, there is a recommended approach to do that: by using the DeviceCheck framework. The idea here is that it allows you to persist 2 bits of data across app installations on each device. You can set the first bit to 1 if the user has already installed the app or 0 otherwise. And use the second bit, for example, to check if the user has signed in or not.
The official documentation is pretty good, please check it out.
The downside of this approach is that you will also have to do some work on the backend side.
UPDATE:
If you specifically want to detect the account, there is no reliable approach. One of the options is to use identifierForVendor or generate some kind of device fingerprint (for example, by combining the device model, timezone, locale, etc.), but of course, this will not work every time.
Uniquely identifying a device is a security leak, and all platforms are putting serious restrictions on unique persistent identifiers because of privacy concerns.
Related
My app is free and, using in-app purchases, I'd like to enable additional functionality. To do so, I am envisioning generating an unlock code that is dependent on the current user and the current app version. I need the first so that the same key won't work with someone else's installation (but will work for multiple devices owned by the same user). I may not need the second, but it would give a bit more future flexibility.
To do this, I need some sort of google user id. Is there such a thing? If so, how do I get it?
Thanks.
Google takes care of some of this for you. It will deliver a device dependent key to each device for a user. Your job is
1) Validate the key properly on your server
2) Make sure you return a device-specific authorization value from the server so users cannot just copy data files around.
3) On the device, use the authorization value to enable things.
Validating the key is easy but do make sure you do it on a server. The problem is identifying the device. Google and its partners dropped the ball a bit on that. Tim Bray has a blog article at http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html that discusses the problem. I recommend using the ANDROID_ID despite his reservations. I have doubts about the security of his other proposal but haven't done a full analysis. Definitely stay away from anything network related (IMSI, IMEI, ESN, ...). I also cache the device identifier used and make sure it doesn't change.
Personally, I scramble the data needed to unlock my features in my app. When I get a valid transaction, I compute a key that can be combined with the device id to unlock the data. It is far from perfect but seems to work. I accept that I will be hacked - I just don't want it to be obvious.
If you want a per-version key, then you need to do a RESTORE_TRANSACTIONS and re-validate at the server any time the version changes.
I'd like to suggest another approach - no better, just different. Use a flag to indicate whether to allow or not running the upgrade features. Periodically validate with the in-app billing apis whether the user has purchased the upgrade. If not, reset the flag.
The user can hack the flag, but sooner or later it will be reset, blocking use of the features.
To truely break this method, the user would have to reverse engineer the code and bypass checking the flag. I doubt most people would bother with that, but what do I know?
I would like to publish an Android app with 2-years time support (this is due to API costs). After 2 years, the user has to buy the app again (if he wants).
There are at least 3 problems:
I want it to be easy and effortless for the user: so no "registration form" (if possible).
The app should work on other devices connected with the same Google account (as every payed app).
The app should not work if the user sells his device: so using device's IMEI isn't a very good solution.
I think that the definitive solution would be univocally identifying the user, but the question is: how to do that?
Do you think that AccountManager could be a solution?
Note that the app needs to connect to my server in order to work, so the solution can be implemented both client and/or server side.
You can try to uniquely identify the user using his/her phone number. This is what Wavesecure does.
This does have some implications:
a) your app cannot work on a wifi only tablet.
b) you will have to provide a way for users to migrate phone numbers in case they happen to change phones.
You said that:
The app should work on other devices connected with the same Google account (as every payed app).
Use the google account.
When the app starts have him choose a google account and save the account ID (the email address) server side.
Also make sure the user can change the referenced account, it should not make any difference, as long as you allow just one account per user.
Ideally, as time passes by, you may want to track the active installations for each user, and limit the number of devices (model name, IMEI if available, OS version etc) to prevent fake account sharing. But that's something you can do later.
I have an app on the market. When you start playing your device id is linked to your account so you don't have to log in manually. For some time now a few people had a problem. They started logging in into different accounts. What seems to be the problem is that some devices give a null value when asked for device id. With a few accounts with a null device id, people were logging into different accounts.
I read that some devices will do that. But it seems that there was no problem during account creation and then playing for a while.
I know this is not the best method and google discourages using device ids since they can change on fabric reset.
Can a device for some reason stop giving its id(besides the fabric reset)?
Anyone know of a different way to identify the user with out him needing to put in a login or password?
Yes some phones have bugs in them where they will return NULL for Android ID. I think if you want to continue to use them you'll always need a way to tie that handset to an account, email, username. That way if the Android ID is unrecognized they could login using their email or username, and password to associate them again. You'll always have issues where someone buys a new phone and needs a way recover their account if you don't.
A better option is every Android phone is attached to a Google account. And using the AccountManager class you can use those credentials to authenticate to your software automatically and the user doesn't have to enter username/password. And you'e centralized their identity. Also with this method you don't require the extra permissions to read data that has potential security issues too.
You could create a random UUID after the user has installed your app.
Do not use hardware ids, because not every type of hardware is found in every type of Android device. Another reason not to use them is, if someone sells his phone, the user changes but the device id not! This has serious privacy and usability implications you do not want to have.
See the talk Android Protips (from google io 2011). Tune in at 15:00 to see more reasons and a detailed descriptions on how to use random UUIDs for your usecase.
I am facing the same problem In my case when first install the app it is giving null id . but after that it is giving me all three IMEI, ANDROID_ID and deviceID.
BTW, you can find the ways to identify the devices here
http://innovator.samsungmobile.com/cms/cnts/knowledge.detail.view.do?platformId=1&cntsId=9640
Also some research prototypes try to prevent phones from collecting this information.
Any tips on how to implement a trialware model for Android apps? I plan to release my app as a free app that expires after 30 days unless the user buys the license via an in-app purchase.
I can use the Android Market API to tell if they bought the license, so my main question is how to prevent the user from un-installing and re-installing my app every 30 days? Can I save something to their phone in a permanent and reliable way that will remain on the phone even if they uninstall? I know nothing will stop a determined hacker, I just want to stop the average user.
I am also open to different approaches to going trialware on Android.
Thanks in advance,
Barry
Have you read the documentation on Application Licensing? Specifically, have a look at Implementing a Policy
I also have found this resource very helpful in determining the best way to get a unique ID for any one device. Android - Identifying App Installations -- They discuss pros/cons to the different approaches -- Straight from the developer's mouths!
I would avoid leaving unwanted remains of the application on their phone.
Instead, you can take some unique identifier of the device, and send it to your server, if this ID was not registered before, send it activation code, if it was, don't send it.
Store this activation code in some shared preferences etc. and when the application starts, check if the activation code is there and if it is valid.
They don't even have to uninstall, just clean app data. You can save something to an obscure location on the SD card, but that's also fairly easy to circumvent, even easier if they read this forum :) Your best bet is to have the app call home to your server and check if licensed periodically. That of course comes with it's own problems: do you allow it to run if network connection is never available, etc.
I'm creating an Android application for a fantasy league as part of a college project. It's a paid application, and requires each download to be associated with only one team.
I'm confused as to how best go about it. If a user goes to settings and clears the data from there, all files, settings and databases would be deleted rendering a locally stored indicator for "The app has already run before and hence user is registered" as pointless.
Another option that had come to my mind was to store the IMEI no on a remote database (with SHA1 encryption to protect the data) but the problem with this is that, if a user loses or changes his phone, his further participation would be impossible. Additionally, users understandably don't like to share IMEI numbers and it's acceptable.
The best solution in my mind was to restrict usage of the app to the Google account that was used to download the application. With this, even a change of handsets would allow further participation of the user. However, I've not been able to find a way to obtain the Android Market account (only require E-mail) which resulted in the download.
So, my question is, how do I best go about with the problem that I face? Is there a way to get the Android Market username? Or is there a worthy alternative?
The server-side option is what you want, you can get a unique id from each phone and use that as your identifier.