I need to use a unique ID for an Android app and I thought the serial number for the device would be a good candidate. How do I retrieve the serial number of an Android device in my app ?
67 49 | |||||||||
|
70 |
getSystemService is a method from the Activity class. getDeviceID() will return the MDN or MEID of the device depending on which radio the phone uses (GSM or CDMA). Each device MUST return a unique value here (assuming it's a phone). This should work for any Android device with a sim slot or CDMA radio. You're on your own with that Android powered microwave ;-) | ||||||||||||||||||||
|
46 | As Dave Webb mentions, the Android Developer Blog has an article that covers this. I spoke with someone at Google to get some additional clarification on a few items. Here's what I discovered that's NOT mentioned in the aforementioned blog post:
Based on Google's recommendations, I implemented a class that will generate a unique UUID for each device, using ANDROID_ID as the seed where appropriate, falling back on TelephonyManager.getDeviceId() as necessary, and if that fails, resorting to a randomly generated unique UUID that is persisted across app restarts (but not app re-installations).
| ||||||||||||||||||||
|
24 |
This code returns device serial number using a hidden Android API. | ||||||||||||||||||||
|
13 |
Although, it is not guaranteed that the Android ID will be an unique identifier. | ||||||||||||||||
|
10 | There is an excellent post on the Android Developer's Blog discussing this. It recommends against using Instead you could use one of the following:
The post discusses the pros and cons of each and it's worth reading so you can work out which would be the best for your use. | ||||
|
6 | The IMEI is good but only works on Android devices with phone. You should consider support for Tablets or other Android devices as well, that do not have a phone. You have some alternatives like: Build class members, BT MAC, WLAN MAC, or even better - a combination of all these. I have explained these details in an article on my blog, see: http://www.pocketmagic.net/?p=1662 | ||||
4 | There are problems with all the above approaches. At Google i/o Reto Meier released a robust answer to how to approach this which should meet most developers needs to track users across installations. This approach will give you an anonymous, secure user ID which will be persistent for the user across different devices (including tablets, based on primary Google account) and across installs on the same device. The basic approach is to generate a random user ID and to store this in the apps shared preferences. You then use Google's backup agent to store the shared preferences linked to the Google account in the cloud. Lets go through the full approach. First we need to create a backup for our SharedPreferences using the Android Backup Service. Start by registering your app via this link:http://developer.android.com/google/backup/signup.html Google will give you a backup service key which you need to add to the manifest. You also need to tell the application to use the BackupAgent as follows:
Then you need to create the backup agent and tell it to use the helper agent for sharedpreferences:
To complete the backup you need to create an instance of BackupManager in your main Activity:
Finally create a user ID, if it doesn't already exist, and store it in the SharedPreferences:
This User_ID will now be persistent across installations, even if the user switches devices. For more information on this approach see Reto's talk herehttp://www.google.com/events/io/2011/sessions/android-protips-advanced-topics-for-expert-android-app-developers.html And for full details of how to implement the backup agent see the developer site here:http://developer.android.com/guide/topics/data/backup.html I particularly recommend the section at the bottom on testing as the backup does not happen instantaneously and so to test you have to force the backup. | |||
add comment |
0 | As @haserman says:
But it's necessary including the permission in the manifest file:
| ||
add comment |
0 | Another way is to use /sys/class/android_usb/android0/iSerial in an App with no permissions whatsoever.
To do this in java one would just use a FileInputStream to open the iSerial file and read out the characters. Just be sure you wrap it in an exception handler because not all devices have this file. At least the following devices are known to have this file world-readable:
You can also see my blog post here: http://insitusec.blogspot.com/2013/01/leaking-android-hardware-serial-number.html where I discuss what other files are available for info. | ||||
|
0 | For a simple number that is unique to the device and constant for its lifetime (barring a factoring reset or hacking), use Settings.Secure.ANDROID_ID.
To use the device serial number (the one shown in "System Settings / About / Status") if available and fall back to Android ID:
| |||
add comment |
-1 | I found the example class posted by @emmby above to be a great starting point. But it has a couple of flaws, as mentioned by other posters. The major one is that it persists the UUID to an XML file unnecessarily and thereafter always retrieves it from this file. This lays the class open to an easy hack: anyone with a rooted phone can edit the XML file to give themselves a new UUID. I've updated the code so that it only persists to XML if absolutely necessary (i.e. when using a randomly generated UUID) and re-factored the logic as per @Brill Pappin's answer:
| ||||||||
|