㈠ android獲取設備唯一ID（優化方案）
最近，因公司產品及客戶需要，領導讓我研究免存儲設備ID，以及給出一個設備ID最佳的方案（可與存儲相結合）。在研究過瀏覽器的fingerprient2js後，頗有心得，並且看網上似乎木有完美的解決方案，於是寫了這篇文章，僅供需要的開發者參考。（該演算法暫未進行驗證，這里先給出一個jar包，後期我會在SDK中加入調查介面，分兩個jar包（測試版和正式版），希望開發者能支持測試版，穩定後使用正式版。）
在產品中，首先肯定要盡量避免許可權，其次考慮卸載APP後ID不一致的問題，再就是盡量結合存儲，降低卸載或重裝app時，設備ID改變的概率。最後，設計出合理方案，對造成不利的因素進行列舉。
A.android_id:
什麼是android_id呢？當設備在第一次啟動時，系統會隨機產生一個64位的數字，然後以16進制的形式保存在設備上，且API提供了獲取這一參數的方法：
這就是android_id,當設備重新初始化或者刷機的時候，會被重置。
除此以外，android_id還有其他的bug，比如：
1.不同的設備可能會產生相同的android_id。
2.有的廠商設備無法獲取android_id,會返回null。
3.對於CDMA的設備，ANDROID_ID和TelephonyManager.getDeviceId() 的值相同。
4.不同的android系統版本穩定性不同。
B.硬體序列號(SERIAL)
API給的解釋是：
A hardware serial number, if available.（一個硬體的序列碼，如果有效的話）
so，雖然我沒有用幾百台手機測試，也能知道這個值有時候是無效的，說的這么隱晦。
C.指紋
fingerprint:設備的唯一標識。由設備的多個信息拼接合成。
也是在JavaScript才接觸到這個單詞」fingerprint「，這個詞也很生動，意思是能大概的標識一個設備，像指紋一樣，但不排除重復的可能性。
理論上講用這個屬性是可以標識一個設備的，但是其實並不是，兩台一摸一樣的新手機，這個值相同的可能性是很多的。為了更加進一步的精確，後面還會介紹幾個屬性，並把幾個屬性結合在一起，生成一個接近100%的UUID。
D.android系統提供了獲取android系統版本號，生產廠商，固件版本推出時間的API.
E.android系統提供了當前android設備是12或24小時制顯示時間的API，
F.android系統提供了當前android設備的修訂版本列表，顯示屏，主板等等參數。
G.可以允許用戶根據需求用自定義字元串去為FP做貢獻，比如IP地址等
方案：
在不需要用戶許可權的前提下，網上最完美的方案是將android_id和硬體序列號，如果其中任意一種失效就使用另外一種。受FingerPrint2js的啟發，我看了Android獲取系統硬體相關的API，將所有不經常變化且能代表一定用戶群體的屬性都取出來進行MD5運算，包含但不限於依據中所述的信息。准確性還需進一步驗證，但理論上要比FingerPrint2js准確性高，也在網上給出的比較好的方案基礎上進一步縮小了FP可能重復的概率。
1.第一次進入APP時，獲取系統相關配置信息生成FP，存入SP。
2.每次訪問，先從SP取，沒有再通過相關配置信息生成FP，存入SP。
3.封裝成jar，只給用戶暴露出獲取ID的介面、傳遞自定義信息構建FP的介面以及第一次安裝時間戳的介面（或設置標簽調用的介面）
單純對於FP而言，有兩個主要問題需要解決，一是FP重復的問題，相同配置的新設備重復可能性極大，增多給FP貢獻的因素的數量，可以有效降低重復率。二是FP改變的問題，貢獻FP的生成因素的其中一個如果改變，FP就會改變。所以如果FP的貢獻因素數量過多，導致FP改變的概率也就變大，所以說客戶要在兩者之間做一個很好的平衡。
對比：
為android FP做貢獻的各配置參數：（示例以6.0的華為榮耀8為例）
1.Android_ID:Settings.System.getString(context.getContentResolver(), Settings.System.ANDROID_ID) //低版本穩定，高版本不穩定 示例：295a4fbf716094ee
2.Build.SERIAL 設備序列號（有的設備無法獲取） 示例：WTK7N16923005607
3.Build.FINGERPRINT 設備指紋（同樣的新設備該值應該是一樣的） 示例：honor/FRD-AL00/HWFRD:6.0/HUAWEIFRD-AL00/C00B171:user/release-keys
4.Build.TIME 固件推出日期 示例：1477442228000
5.Build.VERSION.INCREMENTAL 源碼控製版本號 示例： C00B171
6.Build.getRadioVersion() 獲取無線電固件版本 示例：21.210.03.00.031,21.210.03.00.031
7.Build.HARDWARE 硬體名稱 示例：hi3650
8.Build.VERSION.SECURITY_PATCH 用戶可見安全補丁level（這里我得到的是日期，可能是補丁修復的時間）示例：2016-10-01
9.當前設備是12/24時制：Settings.System.getString(context.getContentResolver(), Settings.System.TIME_12_24) 示例：null（有的手機可以獲取）
10.Build.VERSION.SDK_INT SDK版本號 （一般講是與系統版本號一一對應的） 示例：23
11.Build.SUPPORTED_32_BIT_ABIS 支持32位ABIs的列表（數值）示例：[armeabi-v7a,armeabi]
12.Build.SUPPORTED_64_BIT_ABIS 支持64位ABIs的列表（數值）示例：[arm64-v8a]
13.Build.BOOTLOADER 系統啟動程序版本號 示例：unknown
14.Build.VERSION.RELEASE 用戶可見版本 示例： 6.0
16.Build.BOARD 主板 示例：FRD-AL00
17.Build.BRAND 系統定製商 示例：honor
21.Build.HOST 示例：huawei-RH2288H-V2-12L
23.Build.MANUFACTURER 產品/硬體的製造商 示例：HUAWEI
25.Build.PRODUCT 產品的名稱 示例：FRD-AL00
26.Build.TAGS 描述Build的標簽（Comma-separated tags describing the build, like "unsigned,debug".） 示例：release-keys
28.Build.USER 描述Build的USER 示例：jslave
31.Build.VERSION.BASE_OS 基帶版本 The base OS build the proct is based on. 示例：空值
32.自定義字元串或自定義數組
㈡ 如何確定一台 Android 設備的唯一性
他的MAC碼和進網許可證之類的就是唯一的，全世界都不相同
㈢ linux系統中，設備以什麼來唯一確定
跟WINDOWS一樣吧。硬碟，光碟，軟盤，可移動磁碟，滑鼠，列印機，網卡,磁碟。。。常見硬體設備在linux中的代號：IDE硬碟/dev/hd[a-d]SCSI硬碟/dev/sd[a-d]光碟機/dev/cdrom軟碟機/dev/fd[0-1]列印機/dev/lp[0-1]滑鼠/dev/mouse磁碟/dev/ht0(IDE)/dev/st0(SCSI)網卡/dev/ethn(n由0開始）
㈣ 在前端方面有哪些識別唯一設備或用戶的方法
UDID的全稱是Unique Device Identifier，顧名思義，它就是蘋果IOS設備的唯一識別碼，它由40個字元的字母和數字組成。在很多需要限制一台設備一個賬號的應用中經常會用到。在iOS5中可以獲取到設備的UDID，後來被蘋果禁止了。
IDFA（identifierForIdentifier）
廣告標示符，適用於對外：例如廣告推廣，換量等跨應用的用戶追蹤等。
是iOS 6中另外一個新的方法，提供了一個方法advertisingIdentifier，通過調用該方法會返回一個NSUUID實例，最後可以獲得一個UUID，由系統存儲著的。不過即使這是由系統存儲的，但是有幾種情況下，會重新生成廣告標示符。如果用戶完全重置系統（(設置程序 -> 通用 -> 還原 -> 還原位置與隱私) ，這個廣告標示符會重新生成。另外如果用戶明確的還原廣告(設置程序-> 通用 -> 關於本機 -> 廣告 -> 還原廣告標示符) ，那麼廣告標示符也會重新生成。關於廣告標示符的還原，有一點需要注意：如果程序在後台運行，此時用戶「還原廣告標示符」，然後再回到程序中，此時獲取廣 告標示符並不會立即獲得還原後的標示符。必須要終止程序，然後再重新啟動程序，才能獲得還原後的廣告標示符。
在同一個設備上的所有App都會取到相同的值，是蘋果專門給各廣告提供商用來追蹤用戶而設的，用戶可以在 設置|隱私|廣告追蹤 里重置此id的值，或限制此id的使用，故此id有可能會取不到值，但好在Apple默認是允許追蹤的，而且一般用戶都不知道有這么個設置，所以基本上用來監測推廣效果，是戳戳有餘了。
注意：由於idfa會出現取不到的情況，故絕不可以作為業務分析的主id，來識別用戶。
IDFV（identifierForVendor）
Vindor標示符，適用於對內：例如分析用戶在應用內的行為等。
是給Vendor標識用戶用的，每個設備在所屬同一個Vender的應用里，都有相同的值。其中的Vender是指應用提供商，但准確點說，是通過BundleID的DNS反轉的前兩部分進行匹配，如果相同就是同一個Vender，例如對於com.somecompany.appone,com.somecompany.apptwo
這兩個BundleID來說，就屬於同一個Vender，共享同一個idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常適合於作為內部用戶行為分析的主id，來標識用戶，替代OpenUDID。
注意：如果用戶將屬於此Vender的所有App卸載，則idfv的值會被重置，即再重裝此Vender的App，idfv的值和之前不同。
㈤ 下列哪些電腦屬性或者組合屬性是唯一的
這里看不到唯一屬性，電腦名都可以修改成相同的，工作組是必須一樣的。
只能通過IP或MAC查看內網唯一屬性
㈥ iOS獲取設備唯一標識的各種方法IDFA，IDFV，UDID分別是什麼含義
UDID的全稱是Unique
Device
Identifier，顧名思義，它就是蘋果IOS設備的唯一識別碼，它由40個字元的字母和數字組成。在很多需要限制一台設備一個賬號的應用中經常會用到。在iOS5中可以獲取到設備的UDID，後來被蘋果禁止了。
IDFA（identifierForIdentifier）
廣告標示符，適用於對外：例如廣告推廣，換量等跨應用的用戶追蹤等。
是iOS
6中另外一個新的方法，提供了一個方法advertisingIdentifier，通過調用該方法會返回一個NSUUID實例，最後可以獲得一個UUID，由系統存儲著的。不過即使這是由系統存儲的，但是有幾種情況下，會重新生成廣告標示符。如果用戶完全重置系統（(設置程序
->
通用
->
還原
->
還原位置與隱私)
，這個廣告標示符會重新生成。另外如果用戶明確的還原廣告(設置程序->
通用
->
關於本機
->
廣告
->
還原廣告標示符)
，那麼廣告標示符也會重新生成。關於廣告標示符的還原，有一點需要注意：如果程序在後台運行，此時用戶「還原廣告標示符」，然後再回到程序中，此時獲取廣
告標示符並不會立即獲得還原後的標示符。必須要終止程序，然後再重新啟動程序，才能獲得還原後的廣告標示符。
在同一個設備上的所有App都會取到相同的值，是蘋果專門給各廣告提供商用來追蹤用戶而設的，用戶可以在
設置|隱私|廣告追蹤
里重置此id的值，或限制此id的使用，故此id有可能會取不到值，但好在Apple默認是允許追蹤的，而且一般用戶都不知道有這么個設置，所以基本上用來監測推廣效果，是戳戳有餘了。
注意：由於idfa會出現取不到的情況，故絕不可以作為業務分析的主id，來識別用戶。
IDFV（identifierForVendor）
Vindor標示符，適用於對內：例如分析用戶在應用內的行為等。
是給Vendor標識用戶用的，每個設備在所屬同一個Vender的應用里，都有相同的值。其中的Vender是指應用提供商，但准確點說，是通過BundleID的DNS反轉的前兩部分進行匹配，如果相同就是同一個Vender，例如對於com.somecompany.appone,com.somecompany.apptwo
這兩個BundleID來說，就屬於同一個Vender，共享同一個idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常適合於作為內部用戶行為分析的主id，來標識用戶，替代OpenUDID。
注意：如果用戶將屬於此Vender的所有App卸載，則idfv的值會被重置，即再重裝此Vender的App，idfv的值和之前不同。
㈦ 手機上有什麼可以作為唯一標識的東西
IMSI國際移動用戶識別碼（IMSI：International Mobile Subscriber Identification Number）是區別移動用戶的標志，儲存在SIM卡中，可用於區別移動用戶的有效信息。IMSI組成如下圖所示，其總長度不超過15位，同樣使用0～9的數字。 其中MCC是移動用戶所屬國家代號，佔3位數字，中國的MCC規定為460；MNC是移動網號碼，最多由兩位數字組成，用於識別移動用戶所歸屬的移動通信網；MSIN是移動用戶識別碼，用以識別某一移動通信網中的移動用戶。)
IMEI(國際移動設備識別碼（IMEI：International Mobile Equipment Identification Number）是區別移動設備的標志，儲存在移動設備中，可用於監控被竊或無效的移動設備。IMEI組成如下圖所示，移動終端設備通過鍵入「*#06#」即可查得。其總長為15位，每位數字僅使用0～9的數字。其中TAC代表型號裝配碼，由歐洲型號標准中心分配；FAC代表裝配廠家號碼；SNR為產品序號，用於區別同一個TAC和FAC中的每台移動設備；SP是備用編碼。
ESN （Electronic Serial Numbers）：電子序列號，在CDMA 系統中，是鑒別一個物理硬體設備唯一的標識。也就是說每個手機都用這個唯一的ID來鑒別自己, 就跟人的身份證一樣。CDMA中的ESN對應於GSM網路中的IMEI。 一個ESN有32 bits, 也就是 32/4 = 8 bytes。隨著CDMA移動設別的增多，ESN已經不夠用了，所以推出了位數更多的MEID。ESN用16進制來表示。)
MEID（Mobile Equipment ID）： 由於CDMA移動設備增多，導致原來8位的ESN不夠用，所以56bits=（56/4=14bytes）的MEID橫空出世。現在的CDMA手機一般ESN/MEID兩者都有。MEID也是用16進制來表示。
㈧ 怎麼認證安卓設備唯一性
前段時間項目需要一個功能，就是在操作完某一個邏輯之後返回給客戶一個紅包，安全校驗團隊需要我們提供android設備的唯一標示，起初直接通過獲取設備的imei號傳給了server端，後台公司雲跡監控發現，有些設備的imei號是0000000000000000，這樣失去了設備唯一性驗證的功能，第二個版本做了一個修復，除了獲取imei號之外還新增了AndrdoiId的處理，不過悲劇的是android 設備實在是太多太雜了，僅僅通過這兩個維度去確定設備的唯一性還是有一些漏洞的，最終我們的解決方案是盡量多的獲取與設備相關的信息，最後做一個MD5數字加簽，基本滿足了這個需求 [java] view plain package com.suning.mobile.epa; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import android.content.Context; import android.os.Build; import android.provider.Settings.Secure; import android.telephony.TelephonyManager; public class DeviceFactoty { // buildId public String m_szDevIDShortMaker() { String m_szDevIDShort = "35"; m_szDevIDShort += Build.BOARD.length() % 10 + Build.BRAND.length() % 10 + Build.CPU_ABI.length() % 10 + Build.DEVICE.length() % 10 + Build.DISPLAY.length() % 10 + Build.HOST.length() % 10 + Build.ID.length() % 10 + Build.MANUFACTURER.length() % 10 + Build.MODEL.length() % 10 + Build.PRODUCT.length() % 10 + Build.TAGS.length() % 10 + Build.TYPE.length() % 10 + Build.USER.length() % 10 + ""; return m_szDevIDShort; } public String currentDeviceMark(Context context) { final TelephonyManager tm = (TelephonyManager) context .getSystemService(Context.TELEPHONY_SERVICE); final String tmDevice, tmSerial, androidId; tmDevice = "" + tm.getDeviceId(); tmSerial = "" + tm.getSimSerialNumber(); androidId = "" + android.provider.Settings.Secure.getString(EPApp.getApp() .getContentResolver(), Secure.ANDROID_ID); String serial = ""; if (Build.VERSION.SDK_INT > Build.VERSION_CODES.FROYO){ serial = Build.SERIAL; } String m_szLongID = tmDevice + tmSerial + androidId + serial + m_szDevIDShortMaker(); MessageDigest m = null; try { m = MessageDigest.getInstance("MD5"); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } m.update(m_szLongID.getBytes(), 0, m_szLongID.length()); // get md5 bytes byte p_md5Data[] = m.digest(); // create a hex string String m_szUniqueID = new String(); for (int i = 0; i < p_md5Data.length; i++) { int b = (0xFF & p_md5Data[i]); // if it is a single digit, make sure it have 0 in front (proper padding) if (b <= 0xF) m_szUniqueID += "0"; // add number to string m_szUniqueID += Integer.toHexString(b); } // hex string to uppercase return m_szUniqueID = m_szUniqueID.toUpperCase(); } }
㈨ 漫談唯一設備ID
設備ID，簡單來說就是一串符號（或者數字），映射現實中硬體設備。
如果這些符號和設備是一一對應的，可稱之為「唯一設備ID（Unique Device Identifier）」
不幸的是，對於Android平台而言，沒有穩定的API可以讓開發者獲取到這樣的設備ID。
開發者通常會遇到這樣的困境：
隨著項目的演進， 越來越多的地方需要用到設備ID；
然而隨著Android版本的升級，獲取設備ID卻越來越難了。
加上Android平台碎片化的問題，獲取設備ID之路，可以說是步履維艱。
關於設備ID的作用，大概可以分為下面幾點：
獲取設備標識的API屈指可數，而且都或多或少有一些問題。
常規的API有以下這些：
IMEI本該最理想的設備ID，具備唯一性，恢復出廠設置不會變化（真正的設備相關）。
然而，獲取IMEI需要 READ_PHONE_STATE 許可權，估計大家也知道這個許可權有多麻煩了。
尤其是Android 6.0以後, 這類許可權要動態申請，很多用戶可能會選擇拒絕授權。
我們看到，有的APP不授權這個許可權就無法使用， 這可能會降低用戶對APP的好感度。
而且，Android 10.0 將徹底禁止第三方應用獲取設備的IMEI, 即使申請了 READ_PHONE_STATE 許可權。
所以，如果是新APP，不建議用IMEI作為設備標識；
如果已經用IMEI作為標識，要趕緊做兼容工作了，尤其是做新設備標識和IMEI的映射。
通過 android.os.Build.SERIAL 獲得，由廠商提供。
如果廠商比較規范的話，設備序列號+Build.MANUFACTURER應該能唯一標識設備。
但現實是並非所有廠商都按規范來，尤其是早期的設備。
最致命的是，Android 8.0 以上，android.os.Build.SERIAL 總返回 「unknown」；
若要獲取序列號，可調用Build.getSerial() ，但是需要申請 READ_PHONE_STATE 許可權。
到了Android 10.0以上，則和IMEI一樣，也被禁止獲取了。
總體來說，設備序列號有點雞肋：食之無味，棄之可惜。
獲取MAC地址也是越來越困難了，
Android 6.0以後通過 WifiManager 獲取到的mac將是固定的：02:00:00:00:00:00 ，
再後來連讀取 /sys/class/net/wlan0/address 也獲取不到了。
如今只剩下面這種方法可以獲取（沒有開啟wifi也可以獲取到）：
再往後說不準這種方法也行不通了，且用且珍惜~
Android ID 是獲取門檻最低的，不需要任何許可權，64bit 的取值范圍，唯一性算是很好的了。
但是不足之處也很明顯：
1、刷機、root、恢復出廠設置等會使得 Android ID 改變；
2、Android 8.0之後，Android ID的規則發生了 變化 ：
兩個規則導致的結果就是：
第一，如果用戶安裝APP設備是8.0以下，後來卸載了，升級到8.0之後又重裝了應用，Android ID不一樣；
第二，不同簽名的APP，獲取到的Android ID不一樣。
其中第二點可能對於廣告聯盟之類的有所影響。
筆者之前寫過一篇文章 《Android設備唯一標識的獲取和構造》 , 文中提到設備ID的兩個概念：唯一性和穩定性。
唯一性：兩台不同的設備獲取到的設備ID不相同；
穩定性：同一台設備在不同的時間, 獲取到設備ID相同。
分析唯一性，我們可以從ID的分配來入手：
左邊第一欄是bit數量，第二欄是對應的取值范圍，再後面是元素個數以及對應的沖突概率。
例如，假如有50000個32bit的隨機數，則這些隨機數中，至少有兩個相同數字的概率為25%；
換一種說法，就是假如有四組數，每組都有50000個隨機數，則大約其中一組會有重復的數字。
32bit有43億的取值范圍，怎麼50000個隨機數就有這么高的出現重復的概率？
如果對此感到困惑，可以了解一下 生日悖論 。
Android ID是長度為16的十六進制字元串，其實就是64bit，我們來分析一下其重復的概率：
假如APP累計激活量達到50億的APP，則每兩個這樣的APP就大約有一個會有重復的Android ID。
不過這里的「重復」不是大量的重復，而是「至少有兩個相同」，也就是，如果設備激活量有50億（很多APP達不到-_-），那麼有可能會有少量的重復的Android ID。
總體而言, Android ID的唯一性還是不錯的。
JDK的randomUUID，大致可以認為是128bit的隨機數（其中有6bit是固定的），即使到達200億的數量，有重復的概率也僅僅是10的負18次方，微乎其微。
穩定性有兩個層面：
無論是統計需求，還是業務需求，都要求設備ID是唯一的，穩定的。
如果設備ID有重復，則活躍統計，用戶畫像，定向推送等統統都不準確了；
其中，影響最深是定向推送，送錯快遞還有可能追回，推送錯了就不好說了，如果推送內容又比較重要，後果不堪設想。
如果設備ID不穩定（ID變化），會影響到活躍統計（會認為是新用戶），對用戶畫像也有較大影響（之前的ID關聯的行為數據無法跟蹤了）。
為此，有必要設計一套方案，提供相對定穩定的，唯一的設備ID。
首先要明確兩個前提條件：
前面分析的設備ID中，在可用的前提下，出現重復的概率較小；
如果一定的頻率去觀察，比如說每天，總體而言，觀察到和昨天不一樣的概率也是較小的。
如何在本來就較小的概率的前提下，繼續降低概率呢？
一種方案是組合設備ID(直接拼接，或者拼接後計算摘要)。
舉個例子，假如出現重復的概率和發生變化的的概率都是千分之一，
則對於兩台不同設備，兩個設備ID同時重復的概率是百萬分之一，兩個設備ID至少有一個發生變化約為千分之二。
也就是，拼接ID的效果是大大提高唯一性，但是一定程度上降低穩定性（只要其中一個要素變化，拼接的ID就變了）。
但事實上，如今能拿到的設備ID，最突出的矛盾是不穩定，所以，我們不能為了提高唯一性而犧牲穩定性。
要提高穩定性，可以引入容錯方案。
容錯方案有很多，比如網路傳輸，用checksum去校驗報文，如果出錯了則重發；
再如磁碟陣列，數據寫入兩個磁碟，只有當兩個磁碟同時出錯時才會丟失數據，從而大大降低丟失數據的概率。
但是對於設備ID，以上兩種方案都不合適，因為上面的方案需要通過checksum來確認原信息是否被修改，設備ID沒有這樣的條件。
所以，可以引入類似虛擬貨幣用到的"拜占庭容錯"方案。
簡單地說，就是要採集三個設備ID到雲端，如果有兩個（包括兩個以上）的設備ID和之前的記錄相同，則認為是同一台設備。
同樣假設出現重復的概率和發生變化的的概率都是千分之一，則：
同一台設備的兩次採集，認不出是同一台設備的條件為「至少兩個設備ID都和上次不一樣」，概率約為百萬分之三。
兩台不同的設備，認為是同一台的條件是為「三個設備ID中，至少有兩個設備ID和另一台設備相同」，概率同樣約為百萬分之三。
所以，用此方案，唯一性和穩定性都能得到提高。
基本思想是：服務端有一張設備 ID 的表，核心的屬性（Column）有：
id | did_1 | did_2 | did_3
客戶請求時，上傳三個設備 ID，服務端檢索:
如果檢索到記錄，其中至少兩個did和上傳的相同，則返回 id;
否則，插入上傳的三個設備 ID，並將新插入記錄的 id 返回。
通常情況下，服務端表的主鍵為自增序列（為了確保插入的有序性），
所以我們不能直接返回表的主鍵，否則容易被他人推測其他的設備 ID，以及知曉用戶數量。
因此，在主鍵 ID 之外，我們需要另外一個唯一 ID。
有兩種思路：
然後就是，需要三個設備ID……
那麼，如果在沒有 READ_PHONE_STATE 許可權的情況下，以及Android 10.0之後，如何處理？
首先，設備序列號還是要採集的，畢竟還有部分舊版本的設備可以獲取到，能區分一點是一點；
然後，採集一些設備相關的信息，機型，硬體信息等（相同的機型，可能有多種配置，所以同時也採集一下硬體信息）。
最終匹配規則如下：
如果沒有匹配的設備，則認為是新設備；
此時，生成新的udid返回，同時插入新設備的相關信息（設備ID，硬體信息）。
關於硬體信息，需滿足一個要求：在設備重啟、恢復出廠設置等操作之後，不會變化。
常規信息有CPU核心數，RAM/ROM大小（以Gb為單位採集，而不是精確到比特，否則容易變化），屏幕解析度和dpi等，結合機型，保守估計有上千甚至上萬種可能性，相對Android ID 的 2^64 當然相差很遠了，但是仍可作為輔助的參考信息。
試想在設備序列號獲取不到，Android ID 和 MAC 地址其中一個發生變化時，檢索到的都是只有Android ID 或者 MAC 其中一個匹配的記錄，茫茫機海，說不準就有一兩台的Android ID 或 MAC是相同的。
這時候選哪一個呢？ 再加上設備信息，或許就區分開了。
常規的設備信息容易遭到篡改，所以，在常規信息之外，我們可以挖掘一些冷門的設備特徵，比如 NetworkInterface 和 感測器 的相關信息。
當常規信息被篡改時，如果冷門的設備信息還沒變，仍可識別出是同一台設備。
至於如何挖掘，那就各顯神通了，通常做手機硬體或者ROM的朋友可能會知道更多的API。
為了方便檢索，我們可以用 MurmurHash 將信息壓縮到64bit(Long的長度）。
再者，在獲取到udid之後，可以定時（比如每隔兩天）就上傳udid和設備信息給雲端，雲端比較一下存儲的信息和上傳的信息，不相同則更新，這樣可以提高udid的穩定性。
比方說，用戶在設備是Android 7.0 的時候卸載了APP，在Android 8.0之後安裝回來，這時候Android ID 是變化了的，但是憑著MAC和設備信息我們可以認出這台設備，同時更新其 Android ID;
如果哪一天輪到MAC獲取不到了，這時候我們仍可以根據 Android ID和設備信息識別出這台設備。
本文介紹了設備ID的用途，現狀，並分析了現有設備ID的特性，最後提出了一套設備ID的構造方案。
按照這幾年的趨勢，各種設備ID的API或許還會越收越緊，僅從客戶端去構造可靠的設備ID是比較困難的，而基於信息採集和雲端綜合計算則相對容易。
具體實現，筆者編寫了一個Demo，已發布的到github，謹供參考。
項目地址： https://github.com/BillyWei001/Udid
參考資料：
https://www.jianshu.com/p/9d828d259270
https://www.jianshu.com/p/ad9756fe21c8
https://blog.csdn.net/andoop/article/details/54633077
https://blog.csdn.net/renlonggg/article/details/78435986
https://developer.android.com/about/versions/oreo/android-8.0-changes?hl=zh-cn
https://en.wikipedia.org/wiki/Birthday_attack
㈩ 蘋果ios多開怎麼識別唯一標識
IOS系統中，獲取設備唯一標識的方法有很多：
一.UDID(Unique Device Identifier)
UDID的全稱是Unique Device Identifier，顧名思義，它就是蘋果IOS設備的唯一識別碼，它由40個字元的字母和數字組成。
二.UUID(Universally Unique Identifier)
UUID是Universally Unique Identifier的縮寫,中文意思是通用唯一識別碼.
三.MAC Address
四.OPEN UDID
五.廣告標示符（IDFA-identifierForIdentifier）
六.Vindor標示符 (IDFV-identifierForVendor)
Vendor是CFBundleIdentifier（反轉DNS格式）的前兩部分。來自同一個運營商的應用運行在同一個設備上，此屬性的值是相同的；不同的運營商應用運行在同一個設備上值不同。
經測試，只要設備上有一個tencent的app，重新安裝後的identifierForVendor值不變，如果tencent的app全部刪除，重新安裝後的identifierForVendor值改變。
但是很不幸，上面所有這些表示設備唯一號的標識，在IOS7中要麼被禁止使用，要麼重新安裝程序後兩次獲取的標識符不一樣。
由於IOS系統存儲的數據都是在sandBox裡面，一旦刪除App，sandBox也不復存在。好在有一個例外，那就是keychain（鑰匙串）。
通常情況下，IOS系統用NSUserDefaults存儲數據信息，但是對於一些私密信息，比如密碼、證書等等，就需要使用更為安全的keychain了。
keychain里保存的信息不會因App被刪除而丟失。所以，可以利用這個keychain這個特點來保存設備唯一標識。
那麼，如何在應用里使用使用keyChain呢，我們需要導入Security.framework ，keychain的操作介面聲明在頭文件SecItem.h里。
直接使用SecItem.h里方法操作keychain，需要寫的代碼較為復雜，我們可以使用已經封裝好了的工具類KeychainItemWrapper來對keychain進行操作。
KeychainItemWrapper是apple官方例子「GenericKeychain」里一個訪問keychain常用操作的封裝類，在官網上下載了GenericKeychain項目後，
只需要把「KeychainItemWrapper.h」和「KeychainItemWrapper.m」拷貝到我們項目，並導入Security.framework 。KeychainItemWrapper的用法：
/** 初始化一個保存用戶帳號的KeychainItemWrapper */
KeychainItemWrapper *wrapper = [[KeychainItemWrapper alloc] initWithIdentifier:@"Account Number"
accessGroup:@"YOUR_APP_ID_HERE.com.yourcompany.AppIdentifier"];
//保存數據
[wrapper setObject:@"<帳號>" forKey:(id)kSecAttrAccount];
[wrapper setObject:@"<帳號密碼>" forKey:(id)kSecValueData];
//從keychain里取出帳號密碼
NSString *password = [wrapper objectForKey:(id)kSecValueData];
//清空設置
[wrapper resetKeychainItem];
其中方法「- (void)setObject:(id)inObject forKey:(id)key;」里參數「forKey」的值應該是Security.framework 里頭文件「SecItem.h」里定義好的key，用其他字元串做key程序會出錯！