ANDROID_ID(SSAID)设备标识

从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这个权限的定义

为拥有系统签名的应用或者privileged应用（apk内置至system-priv目录）才可以访问，即第三方应用无法访问

影响到的接口（Android 官网）
Affected methods include the following:

Build
- getSerial()
TelephonyManager
- getImei()
- getDeviceId()
- getMeid()
- getSimSerialNumber()
- getSubscriberId()

查看一下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 SecurityException occurs.
If your app targets Android 9 (API level 28) or lower, the method returns null or placeholder data if the app has the READ_PHONE_STATE permission. Otherwise, a SecurityException occurs.

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

ANDROID_ID(SSAID)设备标识

Android Q(Android 10变更）

Android ID（Settings.Secure.ANDROID_ID 或 SSAID）

Privacy

解决办法？如何获取唯一标识？

你可能感兴趣的:(ANDROID_ID(SSAID)设备标识)