I want to allocate unique ID to each user as soon as he installs the application so that whenever the app contacts the server I know who is contacting.
For this purpose, I thought that on first time installation, the app contacts the server and gets unique ID. But I don't know where to store it permanently so that next time when app is started, it knows what its ID is rather than contacting server.
Sorry if that is some obvious question as I am newbie.
This question has been asked many times on Stack Overflow.
In short: Android has always supported a unique ID. However, prior to Android 2.2, the ID was not always identical on certain kinds of phones. Since 2.2 is pretty ubiquitous by now, I would use that ID.
The Android Developer Blog has a good article about this.
And as Joachim said - you may want to consider a different approach altogether. Android's unique ID is good and persistent across factory resets, but not across a device upgrade. Also keep in mind that many people have several devices (like a phone and a tablet). You may want to use the Google account instead, the AccountManager can help you there.
Use SharedPreferences to store the unique id.
Here is an example:
Android SharedPreferences
For more complex data, you can use SQlite.
For unique id, you can use IMEI of device on which application is going to install. Refer this link for how to get IMEI number. Then stored that IMEI number in shared preference. Refer Guillermo lobar's link for that. You need to check for that unique id in preference when you application starts. At very first time, save that in preference. So when next time it checks for that id, app find it in preference and hence no need to connecting server. :)
You could get the IMEI of the device. As of API 26, getDeviceId() is deprecated. If you need to get the IMEI of the device, use the following:
String deviceId = "";
if (Build.VERSION.SDK_INT >= 26) {
deviceId = getSystemService(TelephonyManager.class).getImei();
}else{
deviceId = getSystemService(TelephonyManager.class).getDeviceId();
}
Related
Imagine an application that consists of loads of clients and one server. The clients should be able to use the application without the need to register a username for e.g. (Therefore getting the feeling of anonymously using the app)
What unique data in a smartphone could be use to identify "anonymous" users and seperate them uniquely, so that each user would have its own personal data.
Could one use the IMEI id?
Is this possible?
At I/O 15 Google announced the 'instance ID' which uniquely identifies an app installation, and can be used for a veriety of other purposes as well.
I give more detail in an answer to an existing, similar question here:
https://stackoverflow.com/a/30948111/150016
Yes You can use the IMEI, but then you need a permission...or you could give every User a Unique ID on the server side
I think a long type variable is enough so the first one that connects you give him the ID 1 the app gets the ID and so on and so forth
You can use a built in feature here:
import android.provider.Settings.Secure;
private String uniqueIdentifier = Secure.getString(getContext().getContentResolver(),
Secure.ANDROID_ID);
where Secure.ANDROID_ID is presented as "A 64-bit number (as a hex string) that is randomly generated when the user first sets up the device and should remain constant for the lifetime of the user's device."
This is exactly the use case for the new Instance ID: getting a unique ID that you can use to identify even a not logged in user to your server.
This works on both phones and tablets (something IMEI does not) and avoid issues with ANDROID_ID (such as a few manufacturers always using the same ANDROID_ID on all devices).
You don't want to use the IMEI, as it will only apply to devices that have cell phones in them. There are plenty of wifi only devices out there in the wild.
Also, to get the IMEI, you need to ask for extra permission in your manifest.
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
You'd be better off either generating your own random GUID and storing it in your app's SQLite database, or use the Android ID field.
Android ID will give you extra benefits like providing a different identifier for different user profiles within a device.
Another answer here mentioned using Instance ID, but the big caveat there is it requires Google Play Services, so your app wouldn't work on AOSP / forked devices (i.e. Amazon's tablets). I'd have just inserted this as a comment to that answer, but my rep won't let me comment yet.
I am planning on storing a unique identifier after a user logs in for the first time on an Android and Apple app. This will make sure that the user can only access data from one device if they try to login through another device as I will flag then as having access. I will save this unique identifier in the devices preferences and use it for requests to get this private data.
With that being said I know the preferences can be deleted or removed. This piece of data isnt needed long term and in emergencies we can reset the users account back as if they never got access yet like for a factory reset or deleted app.
My question is, are there any issues with this? These arent developers so somehow getting access to the user preferences to find that unique identifier and using it elsewhere shouldnt be an issue.
for IOS:
You shouldn't concern your self with that cause there is no need to store the identifiers to user prefs (and it is not a good practice).
You just use:
[[[UIDevice currentDevice] identifierForVendor] UUIDString];
It will return the same value as long as it is called from the same device and same vendor. This is explained in:
http://www.doubleencore.com/2013/04/unique-identifiers/
Hello I am working on an application in which we are tracking our app installation using device unique ID.
We are doing right now like this as https://stackoverflow.com/a/2785493/2455259
private String android_id = Secure.getString(getContext().getContentResolver(),
Secure.ANDROID_ID);
I got to know that from android 4.2 it can have different for different users https://stackoverflow.com/a/27013749/2455259.
Now I can't take mac address of wifi or bluetooth because it requires to make it turn on then fetch. Even I can't take IMEI because some tables don't have call feature so they don't have IMEI.
Now what are the option to uniquely identify android device ?
Now what are the option to uniquely identify android device ?
I am afraid assigning own unique number is most effective approach, because ANDROID_ID is broken (the answer you link to is incorrect - see comments there too), relying on it is quite futile as it can sometimes be the same for many devices or null, so anything but unique, therefore using it is pointless as it adds more troubles than helps. There's post on Android blog about this topic "Identifying App Installations" that you may want to get thru as well.
I know this is old and the OP might have already moved on but with the introduction of Instance ID, we can use it to identify a unique installation.
The associated code is pretty straightforward too.
String iid = InstanceID.getInstance(context).getId();
The benefits include not having to specify permissions for Android Marshmallow and above. This seems to be a plus for developers who would need a unique id at the outset and cannot rely on user provided permission model for the same.
In one of my App, I would like to give a feature as a trial for only 20 attempts. Once the user wants to access the feature for the 21st attempt, he/she will be prompted for in-App purchase.
My question is how can I make this variable persistent so that even if the user uninstalls the app and re-installs, the counter does not reset and takes the last value before the uninstall.
Please help.
The easiest way is to use Backup API and backup your data online. It is very easy to use and here is tutorial:
http://developer.android.com/training/cloudsync/backupapi.html
The disadvantage of this method is that user can disable backups in phone's settings.
Another method requires you to send data to server. I would suggest to use parse.com since it does not require you to write any server code, they have very easy-to-use library for Android and their free plan is very generous. Here is a little tutorial:
https://parse.com/tutorials/get-started-with-android
You can send some sort of unique id (device or account specific) and counter to the cloud every time user triggers your trial feature. Also you can query your counter from the cloud when application launches the first time.
To create that unique id you can approach with few methods:
Try to obtain 64-bit unique number, which is generated when device first boots:
String androidID = Secure.getString(getContext().getContentResolver(), Secure.ANDROID_ID);
Note that it was reported that for some device this value might be null. You can verify your androidID variable and if it is null, you can try another method that will allow you to access user's primary e-mail (you probably want to hash it prior to sending it your server).
Also make sure to add android.permission.GET_ACCOUNTS permissions to your manifest file:
final Account[] accounts = AccountManager.get(context).getAccounts();
for (final Account account : accounts) {
if (Patterns.EMAIL_ADDRESS.matcher(account.name).matches()) {
final String email = account.name;
// hash email and use it
}
}
if email cannot be obtained - you might also want to try to get device id from telephony manager:
// For CDMA phone getDeviceId() is equal to value request for Secure.ANDROID_ID
final TelephonyManager telMgr = (TelephonyManager)getBaseContext().getSystemService(Context.TELEPHONY_SERVICE);
final String deviceId = telMgr.getDeviceId();
(don't forget to add android.permission.READ_PHONE_STATE permission to your manifest)
Hope that it gave you enough information to add trial functionality into your code.
Also if your in-app purchase is actually a subscription, then Google already implemented trial functionality for you:
http://developer.android.com/google/play/billing/billing_subscriptions.html
(search for free trial)
You have no way of maintaining anything locally for the user if they uninstall or reinstall the application.
If you need the uninstall/re-install requirement, this is counter that will need to be logged on your back-end rather than on the device. You can do this by storing the device's id on your server and incrementing your ticker when appropriate.
I simply define a serializable Expiration object that I store to SD with a dot in front of it to make it hidden.
The object contains time of creation and other metadata.
When the app starts, it checks whether Expiration exists, if not it is create. This way I always know the exact time when the app was installed, despite uninstall/reinstalls.
The downside to this method is that it requires some sort of external storage as we want to go outside of the standard app folder of the internal storage, which is wiped upon uninstall.
To circumvent this, you could look for some way of getting/giving a device a unique id, that remains the same after reinstall, and upload the data to a server. This has the benefit that the user cannot reset the expiration by wiping the SD either.
How can I get a unique Id for the current user who is using my application?
I don't want to retrieve the device UDID (for my users privacy concerns).
I saw once that in the latest API versions (4.0+) there is such method to generate a unique
id for the current android user, but I cannot find it now.
This is the official statement from Google
http://android-developers.blogspot.be/2011/03/identifying-app-installations.html
You should really read it.
I guess you are using some kind of backend, so maybe you can create an endpoint that return a unique token that you save in the shared preferences.