从Android Q即Android 10开始，第三方已经无法获取到手机的唯一设备了，包括IMEI和序列号。
故重新梳理一下相关
Android Q(Android 10变更）
Android 官网关于隐私与安全这一节有详细介绍
https://developer.android.com/about/versions/10/privacy/changes
"Starting in Android 10, apps must have the READ_PRIVILEGED_PHONE_STATE privileged permission in order to access the device's non-resettable identifiers, which include both IMEI and serial number."
意思从Android 10开始，为了加强Android安全性（个人隐私相关），应用必须拥有READ_PRIVILEGED_PHONE_STATE隐私才可以访问设备唯一标识（包括IMEI和序列号）
而READ_PRIVILEGED_PHONE_STATE这个权限的定义
<!-- @SystemApi Allows read access to privileged phone state.
@hide Used internally. -->
<permission android:name="android.permission.READ_PRIVILEGED_PHONE_STATE"
android:protectionLevel="signature|privileged" />
为拥有系统签名的应用或者privileged应用（apk内置至system-priv目录）才可以访问，即第三方应用无法访问
影响到的接口（Android 官网）
Affected methods include the following:
-
Build -
TelephonyManager
查看一下TelephonyManager相关代码（如getDeviceId）,增加了具体的注释说明：
@Deprecated
@SuppressAutoDoc // No support for device / profile owner or carrier privileges (b/72967236).
@RequiresPermission(android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE)
public String getDeviceId() {
try {
ITelephony telephony = getITelephony();
if (telephony == null)
return null;
return telephony.getDeviceId(mContext.getOpPackageName());
} catch (RemoteException ex) {
return null;
} catch (NullPointerException ex) {
return null;
}
}
再看一下具体的权限控制，最终调用到 TelephonyPermissions类进行检查，关键代码在
checkReadDeviceIdentifiers与reportAccessDeniedToReadIdentifiers两个接口，具体可看代码，最终符合
以下规则 ：
- If your app targets Android 10 or higher, a
SecurityExceptionoccurs. - If your app targets Android 9 (API level 28) or lower, the method returns
nullor placeholder data if the app has theREAD_PHONE_STATEpermission. Otherwise, aSecurityExceptionoccurs.
Android ID（Settings.Secure.ANDROID_ID 或 SSAID）
Android ID目前是Android系统提供给应用容易访问的设备ID，也叫SSAID（Settings.Secure.ANDROID_ID缩写），这个ID主要与应用/设备相关
Android ID最大的变化是从Android8.0开始:
https://developer.android.com/about/versions/oreo/android-8.0-changes
它有以下特性：
Privacy
Android 8.0 (API level 26) makes the following privacy-related changes to the platform.
- The platform now handles identifiers differently.
For apps that were installed prior to an OTA to a version of Android 8.0 (API level 26) (API level 26), the value of
[ANDROID_ID]remains the same unless uninstalled and then reinstalled after the OTA. To preserve values across uninstalls after OTA, developers can associate the old and new values by using Key/Value Backup.
系统OTA升级至Android 8.0版本后，这里指的是不清除数据升级，应用APP获取到的ANDROID_ID不会变化，卸载后重新安装会导致变化（按照8.0新的逻辑生成 ，规则看下一条）For apps installed on a device running Android 8.0, the value of
[ANDROID_ID]is now scoped per app signing key, as well as per user. The value of[ANDROID_ID])is unique for each combination of app-signing key, user, and device. As a result, apps with different signing keys running on the same device no longer see the same Android ID (even for the same user).
对于在Android 8.0上面新安装的应用，将会按照新的规则生成ANDROID_ID,生成算法因子包括应用签名，系统用户ID（这个用户ID一般为0，即主用户，而且不同手机的主用户ID是一样的为0,访问模式或其它模式的用户ID为10等其它值），设备。生成逻辑可以看后面的代码分析The value of
[ANDROID_ID]does not change on package uninstall or reinstall, as long as the signing key is the same (and the app was not installed prior to an OTA to a version of Android 8.0).
ANDROID_ID的值在应用卸载后安装/重新安装后不变，因为看上面第二条生成规则便清楚，签名不变即不会变化The value of
[ANDROID_ID]does not change even if a system update causes the package signing key to change.
系统OTA升级后应用对应的ANDROID_ID的值也不会变化，甚至某个应用的签名变化了也不会变化，这是为啥？因为与ANDROID_ID的存储与获取逻辑相关，存储的时候是以包名为key,获取的时候发现之前已经存在了就返回了。但是如果这个应用卸载重新安装了就会变化了-
On devices shipping with Google Play services and Advertising ID, you must use Advertising ID. A simple, standard system to monetize apps, Advertising ID is a unique, user-resettable ID for advertising. It is provided by Google Play services.
最佳实践相关，官方提供标准的Advertising ID方案Other device manufacturers should continue to provide
[ANDROID_ID].
根据上述的规则，来看一下代码逻辑是如何实现的：
public Setting generateSsaidLocked(PackageInfo callingPkg, int userId) {
// Read the user's key from the ssaid table.
Setting userKeySetting = getSettingLocked(SETTINGS_TYPE_SSAID, userId, SSAID_USER_KEY);
if (userKeySetting == null || userKeySetting.isNull()
|| userKeySetting.getValue() == null) {
// Lazy initialize and store the user key.
generateUserKeyLocked(userId);
userKeySetting = getSettingLocked(SETTINGS_TYPE_SSAID, userId, SSAID_USER_KEY);
if (userKeySetting == null || userKeySetting.isNull()
|| userKeySetting.getValue() == null) {
throw new IllegalStateException("User key not accessible");
}
}
final String userKey = userKeySetting.getValue();
// Convert the user's key back to a byte array.
final byte[] keyBytes = ByteStringUtils.fromHexToByteArray(userKey);
// Validate that the key is of expected length.
// Keys are currently 32 bytes, but were once 16 bytes during Android O development.
if (keyBytes == null || (keyBytes.length != 16 && keyBytes.length != 32)) {
throw new IllegalStateException("User key invalid");
}
final Mac m;
try {
m = Mac.getInstance("HmacSHA256");
m.init(new SecretKeySpec(keyBytes, m.getAlgorithm()));
} catch (NoSuchAlgorithmException e) {
throw new IllegalStateException("HmacSHA256 is not available", e);
} catch (InvalidKeyException e) {
throw new IllegalStateException("Key is corrupted", e);
}
// Mac each of the developer signatures.
for (int i = 0; i < callingPkg.signatures.length; i++) {
byte[] sig = callingPkg.signatures[i].toByteArray();
m.update(getLengthPrefix(sig), 0, 4);
m.update(sig);
}
// Convert result to a string for storage in settings table. Only want first 64 bits.
final String ssaid = ByteStringUtils.toHexString(m.doFinal()).substring(0, 16)
.toLowerCase(Locale.US);
// Save the ssaid in the ssaid table.
final String uid = Integer.toString(callingPkg.applicationInfo.uid);
final SettingsState ssaidSettings = getSettingsLocked(SETTINGS_TYPE_SSAID, userId);
final boolean success = ssaidSettings.insertSettingLocked(uid, ssaid, null, true,
callingPkg.packageName);
if (!success) {
throw new IllegalStateException("Ssaid settings not accessible");
}
return getSettingLocked(SETTINGS_TYPE_SSAID, userId, uid);
}
以上生成ANDROID_ID(SSAID)主要分为三个步骤：
1.userKey生成
这里说一下，userkey生成对上述说到生成规则的用户ID和设备相关，用户ID为0,设备ID根据逻辑来说其实是一个随机数生成 ，这个随机数保证同一个应用在不同的设备生成的ANDROID_ID是不一样的
2.Hmac算法根据userkey,应用签名生成ssid
- 截取16位与存储
解决办法？如何获取唯一标识？
Android官网给出了最佳实践，没有仔细研究（跟google套件相关或海外更适合？）
https://developer.android.com/training/articles/user-data-ids
国内目前由工信部牵头实现了一套移动智能终端补充标识体系，大多数国内手机厂商已经支持
，但是对于第三方来说，也无法获取唯一ID了，这样对于开发者的各类功能/业务来说挑战不小
http://msalliance.icoc.bz/col.jsp?id=120
