獲取Android設備唯一標識碼

鏈接地址:http://www.cnblogs.com/lvcha/p/3721091.html

DEVICE_ID:

這是Android系統(tǒng)為開發(fā)者提供的用于標識手機設備的串號,也是各種方法中普適性較高的,可以說幾乎所有的設備都可以返回這個串號,并且唯一性良好。

這個DEVICE_ID可以同通過下面的方法獲仍だ印:

TelephonyManager tm = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);StringDEVICE_ID = tm.getDeviceId();

它會根據(jù)不同的手機設備返回IMEI,MEID或者ESN碼,但在使用的過程中有以下問題:

非手機設備:最開始搭載Android系統(tǒng)都手機設備韭赘,而現(xiàn)在也出現(xiàn)了非手機設備:如平板電腦、電子書势就、電視泉瞻、音樂播放器等脉漏。這些設備沒有通話的硬件功能,系統(tǒng)中也就沒有TELEPHONY_SERVICE袖牙,自然也就無法通過上面的方法獲得DEVICE_ID侧巨。

權限問題:獲取DEVICE_ID需要READ_PHONE_STATE權限,如果只是為了獲取DEVICE_ID而沒有用到其他的通話功能鞭达,申請這個權限一來大才小用司忱,二來部分用戶會懷疑軟件的安全性。

廠商定制系統(tǒng)中的Bug:少數(shù)手機設備上畴蹭,由于該實現(xiàn)有漏洞坦仍,會返回垃圾,如:zeros或者asterisks

MAC ADDRESS

可以使用手機Wifi或藍牙的MAC地址作為設備標識叨襟,但是并不推薦這么做繁扎,原因有以下兩點:

硬件限制:并不是所有的設備都有Wifi和藍牙硬件,硬件不存在自然也就得不到這一信息糊闽。

獲取的限制:如果Wifi沒有打開過梳玫,是無法獲取其Mac地址的;而藍牙是只有在打開的時候才能獲取到其Mac地址墓怀。

獲取Wifi Mac地址:

獲取藍牙 Mac地址:

我們也可以通過手機的Wifi或者藍牙設備獲取MAC ADDRESS作為DEVICE ID汽纠,但是并不建議這么做,因為并不是所有的設備都有Wifi傀履,并且虱朵,如果Wifi沒有打開,那硬件設備無法返回MAC ADDRESS.

Sim Serial Number

裝有SIM卡的設備钓账,可以通過下面的方法獲取到Sim Serial Number:

TelephonyManager tm = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);StringSimSerialNumber = tm.getSimSerialNumber();

注意:對于CDMA設備碴犬,返回的是一個空值!

ANDROID_ID

在設備首次啟動時梆暮,系統(tǒng)會隨機生成一個64位的數(shù)字服协,并把這個數(shù)字以16進制字符串的形式保存下來,這個16進制的字符串就是ANDROID_ID啦粹,當設備被wipe后該值會被重置偿荷。可以通過下面的方法獲冗胪帧:

import android.provider.Settings;StringANDROID_ID = Settings.System.getString(getContentResolver(), Settings.System.ANDROID_ID);

ANDROID_ID可以作為設備標識跳纳,但需要注意:

廠商定制系統(tǒng)的Bug:不同的設備可能會產(chǎn)生相同的ANDROID_ID:9774d56d682e549c。

廠商定制系統(tǒng)的Bug:有些設備返回的值為null贪嫂。

設備差異:對于CDMA設備寺庄,ANDROID_ID和TelephonyManager.getDeviceId() 返回相同的值。

ANDROID_ID是設備第一次啟動時產(chǎn)生和存儲的64bit的一個數(shù),當設備被wipe后該數(shù)重置

ANDROID_ID似乎是獲取Device ID的一個好選擇斗塘,但它也有缺陷:

它在Android <=2.1 or Android >=2.3的版本是可靠赢织、穩(wěn)定的,但在2.2的版本并不是100%可靠的

在主流廠商生產(chǎn)的設備上馍盟,有一個很經(jīng)常的bug于置,就是每個設備都會產(chǎn)生相同的ANDROID_ID:9774d56d682e549c

Serial Number

Android系統(tǒng)2.3版本以上可以通過下面的方法得到Serial Number,且非手機設備也可以通過該接口獲取朽合。

StringSerialNumber = android.os.Build.SERIAL;

Installtion ID

以上幾種方式都或多或少存在一定的局限性或者Bug俱两,如果并不是確實需要對硬件本身進行綁定,使用自己生成的UUID也是一個不錯的選擇曹步,因為該方法無需訪問設備的資源宪彩,也跟設備類型無關。

這種方式的原理是在程序安裝后第一次運行時生成一個ID讲婚,該方式和設備唯一標識不一樣尿孔,不同的應用程序會產(chǎn)生不同的ID,同一個程序重新安裝也會不同筹麸。所以這不是設備的唯一ID活合,但是可以保證每個用戶的ID是不同的∥锔希可以說是用來標識每一份應用程序的唯一ID(即Installtion ID)白指,可以用來跟蹤應用的安裝數(shù)量等。

Google Developer Blog提供了這樣的一個框架:

public class Installation {

private static String sID = null;

private static final String INSTALLATION = "INSTALLATION";

public synchronized static String id(Context context) {

if (sID == null) {

File installation = new File(context.getFilesDir(), INSTALLATION);

try {

if (!installation.exists())

writeInstallationFile(installation);

sID = readInstallationFile(installation);

} catch (Exception e) {

throw new RuntimeException(e);

}

}

return sID;

}

private static String readInstallationFile(File installation) throws IOException {

RandomAccessFile f = new RandomAccessFile(installation, "r");

byte[] bytes = new byte[(int) f.length()];

f.readFully(bytes);

f.close();

return new String(bytes);

}

private static void writeInstallationFile(File installation) throws IOException {

FileOutputStream out = new FileOutputStream(installation);

String id = UUID.randomUUID().toString();

out.write(id.getBytes());

out.close();

}

}

設備唯一ID

上文可以看出酵紫,Android系統(tǒng)中并沒有可以可靠獲取所有廠商設備唯一ID的方法告嘲,各個方法都有自己的使用范圍和局限性,這也是目前流行的Android系統(tǒng)版本過多奖地,設備也是來自不同廠商橄唬,且沒有統(tǒng)一標準等原因造成的。

從目前發(fā)展來看参歹,Android系統(tǒng)多版本共存還會持續(xù)較長的時間仰楚,而Android系統(tǒng)也不會被某個設備生產(chǎn)廠商壟斷,長遠看Android基礎系統(tǒng)將會趨于穩(wěn)定犬庇,設備標識也將會作為系統(tǒng)基礎部分而標準化僧界,屆時這一問題才有望徹底解決。

目前的解決辦法臭挽,比較可行的是一一適配捎泻,在保證大多數(shù)設備方便的前提下,如果獲取不到埋哟,使用其他備選信息作為標識,即自己再封裝一個設備ID出來,通過內(nèi)部算法保證盡量和設備硬件信息相關赤赊,以及標識的唯一性闯狱。

總結

綜合以上所述,為了實現(xiàn)在設備上更通用的獲取設備唯一標識抛计,我們可以實現(xiàn)這樣的一個類哄孤,為每個設備產(chǎn)生唯一的UUID,以ANDROID_ID為基礎吹截,在獲取失敗時以TelephonyManager.getDeviceId()為備選方法瘦陈,如果再失敗,使用UUID的生成策略波俄。

重申下晨逝,以下方法是生成Device ID,在大多數(shù)情況下Installtion ID能夠滿足我們的需求懦铺,但是如果確實需要用到Device ID捉貌,那可以通過以下方式實現(xiàn):

packagecom.example.androidmac;

importandroid.content.Context;

importandroid.content.SharedPreferences;

importandroid.provider.Settings.Secure;

importandroid.telephony.TelephonyManager;

importjava.io.UnsupportedEncodingException;

importjava.util.UUID;

publicclassDeviceUuidFactory {

protectedstaticfinalStringPREFS_FILE="device_id.xml";

protectedstaticfinalStringPREFS_DEVICE_ID="device_id";

protectedstaticUUIDuuid;

publicDeviceUuidFactory(Context context) {

if(uuid==null) {

synchronized(DeviceUuidFactory.class) {

if(uuid==null) {

finalSharedPreferences prefs = context.getSharedPreferences(PREFS_FILE, 0);

finalString id = prefs.getString(PREFS_DEVICE_ID,null);

if(id !=null) {

// Use theidspreviously computed and stored in theprefsfile

uuid= UUID.fromString(id);

}else{

finalString androidId = Secure.getString(context.getContentResolver(), Secure.ANDROID_ID);

// Use the Android ID unless it's broken, in which casefallbackon deviceId,

// unless it's not available, thenfallbackon a random number which we store

// to aprefsfile

try{

if(!"9774d56d682e549c".equals(androidId)) {

uuid= UUID.nameUUIDFromBytes(androidId.getBytes("utf8"));

}else{

finalString deviceId = ((TelephonyManager) context.getSystemService( Context.TELEPHONY_SERVICE)).getDeviceId();

uuid= deviceId!=null? UUID.nameUUIDFromBytes(deviceId.getBytes("utf8")) : UUID.randomUUID();

}

}catch(UnsupportedEncodingException e) {

thrownewRuntimeException(e);

}

// Write the value out to theprefsfile

prefs.edit().putString(PREFS_DEVICE_ID,uuid.toString() ).commit();

}

}

}

}

}

/**

* Returns a unique UUID for the current android device.? As with all UUIDs, this unique ID is "very highly likely"

* to be unique across all Android devices.? Much more so than ANDROID_ID is.

*

* The UUID is generated by using ANDROID_ID as the base key if appropriate, falling back on

* TelephonyManager.getDeviceID() if ANDROID_ID is known to be incorrect, and finally falling back

* on a random UUID that's persisted to SharedPreferences if getDeviceID() does not return a

* usable value.

*

* In some rare circumstances, this ID may change.? In particular, if the device is factory reset a new device ID

* may be generated.? In addition, if a user upgrades their phone from certain buggy implementations of Android 2.2

* to a newer, non-buggy version of Android, the device ID may change.? Or, if a useruninstallsyourappon

* a device that has neither a proper Android ID nor a Device ID, this ID may change onreinstallation.

*

* Note that if the code falls back on using TelephonyManager.getDeviceId(), the resulting ID will NOT

* change after a factory reset.? Something to be aware of.

*

* Works around a bug in Android 2.2 for many devices when using ANDROID_ID directly.

*

*@seehttp://code.google.com/p/android/issues/detail?id=10603

*

*@returna UUID that may be used to uniquely identify your device for most purposes.

*/

public?UUID getDeviceUuid() {

return?uuid;

}

}

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市冬念,隨后出現(xiàn)的幾起案子趁窃,更是在濱河造成了極大的恐慌,老刑警劉巖急前,帶你破解...
    沈念sama閱讀 206,482評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件醒陆,死亡現(xiàn)場離奇詭異,居然都是意外死亡裆针,警方通過查閱死者的電腦和手機刨摩,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,377評論 2 382
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來据块,“玉大人码邻,你說我怎么就攤上這事×砑伲” “怎么了像屋?”我有些...
    開封第一講書人閱讀 152,762評論 0 342
  • 文/不壞的土叔 我叫張陵,是天一觀的道長边篮。 經(jīng)常有香客問我己莺,道長,這世上最難降的妖魔是什么戈轿? 我笑而不...
    開封第一講書人閱讀 55,273評論 1 279
  • 正文 為了忘掉前任凌受,我火速辦了婚禮,結果婚禮上思杯,老公的妹妹穿的比我還像新娘胜蛉。我一直安慰自己挠进,他們只是感情好,可當我...
    茶點故事閱讀 64,289評論 5 373
  • 文/花漫 我一把揭開白布誊册。 她就那樣靜靜地躺著领突,像睡著了一般。 火紅的嫁衣襯著肌膚如雪案怯。 梳的紋絲不亂的頭發(fā)上君旦,一...
    開封第一講書人閱讀 49,046評論 1 285
  • 那天,我揣著相機與錄音嘲碱,去河邊找鬼金砍。 笑死,一個胖子當著我的面吹牛麦锯,可吹牛的內(nèi)容都是我干的恕稠。 我是一名探鬼主播,決...
    沈念sama閱讀 38,351評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼离咐,長吁一口氣:“原來是場噩夢啊……” “哼谱俭!你這毒婦竟也來了?” 一聲冷哼從身側響起宵蛀,我...
    開封第一講書人閱讀 36,988評論 0 259
  • 序言:老撾萬榮一對情侶失蹤昆著,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后术陶,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體凑懂,經(jīng)...
    沈念sama閱讀 43,476評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,948評論 2 324
  • 正文 我和宋清朗相戀三年梧宫,在試婚紗的時候發(fā)現(xiàn)自己被綠了接谨。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,064評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡塘匣,死狀恐怖脓豪,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情忌卤,我是刑警寧澤扫夜,帶...
    沈念sama閱讀 33,712評論 4 323
  • 正文 年R本政府宣布,位于F島的核電站驰徊,受9級特大地震影響笤闯,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜棍厂,卻給世界環(huán)境...
    茶點故事閱讀 39,261評論 3 307
  • 文/蒙蒙 一颗味、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧牺弹,春花似錦浦马、人聲如沸时呀。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,264評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽退唠。三九已至,卻和暖如春荤胁,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背屎债。 一陣腳步聲響...
    開封第一講書人閱讀 31,486評論 1 262
  • 我被黑心中介騙來泰國打工仅政, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人盆驹。 一個月前我還...
    沈念sama閱讀 45,511評論 2 354
  • 正文 我出身青樓圆丹,卻偏偏與公主長得像,于是被迫代替她去往敵國和親躯喇。 傳聞我的和親對象是個殘疾皇子辫封,可洞房花燭夜當晚...
    茶點故事閱讀 42,802評論 2 345

推薦閱讀更多精彩內(nèi)容