I have an app that creates an account for a web app, which is basically sending and receiving SMS messages from the web. This is how it works (not released yet, nearing the end of the first-release features I had planned):
The user purchases the app.
The user enters their name, email, and password.
The account is created on the server-end, and the final view is shown telling the user where to access the web app.
The background processes are opened (C2DM and ContentObserver for SMS).
All goes well. The android part of this app all works flawlessly, but I'm scared of people making multiple accounts from one purchase. How could I stop this from happening? I am clueless when it comes to this subject. First of all, when the final view is shown, a user could just hit back and then recreate another account. How can I prevent them from going to that form ever again? I am thinking I can just set a SharedPreference, but then all the user has to do to make another account is uninstall the app and then reinstall it, and bam another account is made.
I need a way, so once the user registers for the first time, there is in no possible way they can register again, on that specific phone (or specific Google account). Is there any real way to accomplish this? Any help is appreciated, I am stuck when it comes to this topic.
Since SIM identification functions (getSimSerialNumber) return null on CDMA devices and *ANDROID_ID* is said to be the same value on CDMA devices; with addition of tablets which do not have either of them, I highly suggest implementing your own unique identifier in your database and matching it with user's Google Account.
However, since a poweruser can always reset their app data storage and clear their identification from device (thus making your app session on device brand new on app launch) this approach has it's caveats.
You may want to check this blogpost for ideas about generating your unique id
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
I would make it a check on the server side.
Every device has a unique identifier. If you save this on the webserver side during the account creation, you check whether or not an account has already been made on this device. Also add the same check for the Google ID, just in case.
String android_id = Secure.getString(getBaseContext().getContentResolver(),
Secure.ANDROID_ID);
Might be worth a try. Your safest bet will always be something on the server side, since the device side is easily tempered with if people really wanted to.
Related
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.
I'm making an app, which I will distribute via playstore. However, though the app can be installed by anyone in the world, it can only run for selected users who I know.
Below are the possible ways I have figured out,
Check the account E-Mail ids on the phone and if that matches with the one's saved within the app code.
Check the mobile number on the phone and see if that matches with the one's saved within the app code.
When the app runs for the first time, it will send an SMS to my phone. I will reply to that SMS either saying YES or NO. If I reply YES then only the app will run for that user, else it will not.
I would like your feedback on these mechanisms. If there are other ways let me know about that too.
Thanks...
I think your best options are:
Make users log-in using an e-mail and a password (you could ask the user to register and if he uses an e-mail that is known to you, send a password to that e-mail [make the user change it later though])
Beta testing - This allow you to choose wich users will be able to install your app by creating a community on Google+ to beta test your app.
Maybe both.
I have an Android application I am working on in which the client wants a promotional page in which the first 100 people who download the app get a 10% discount on their order. From what I researched I understand that Google Play doesn't have a very user-friendly way to do this, but for my work-around I wanted to have a "not used coupon" and a "used coupon" image that the waitress could see and type in a short verification code to permanently change the coupon on the app to "used."
From what I read I can use the SharedPreferences to make this happen, but what if the person uninstalls the application and then reinstalls it to get a fresh coupon? Is there anyway in Android to prevent this from happening?
There's actually a very simple API for backing up and a specific helper for SharedPreferences. You don't need to have your own server for this.
http://developer.android.com/training/cloudsync/backupapi.html
footnote:
Never use device ID. Use the account ID to identify the user and the ANDROID_ID to identify the device. If you use IMEI, MAC, serial number or anything that stays the same when device ownership changes, you're gonna have a bad time.
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.