Я думаю, что вы новичок в разработке приложений для Android. Всегда есть какая-то путаница, связанная с уникальным идентификатором устройства в Android. ANDROID_ID был представлен на уровне API 3, и возвращаемое значение время от времени различается.
Ранее Android OS предоставляла уникальный идентификатор устройства. Но новое значение возвращается, если устройство отформатировано или установлена новая пользовательская ОС. Позже значение null
возвращается в некоторых устройствах. После Oreo (Android 8.0) он работает по-другому.
Google предлагает разработчикам приложений отслеживать установки приложений, а не устройства, и это подойдет для большинства случаев использования.
Для отслеживания установки приложения вы можете либо создать уникальный идентификатор, например UUID.randomUUId().toString()
, либо сделать собственный обходной путь.
Вот несколько ссылок, которые могут вам помочь.
Существует ли уникальный идентификатор устройства Android?
https://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID
- https://developer.android.com/training/articles/user-data-ids.html
- https://developer.android.com/reference/java/util/UUID.html#randomUUID()
Некоторые пункты, написанные по рекомендациям :
When working with Android identifiers, follow these best practices:
#1: Avoid using hardware identifiers. In most use cases, you can avoid using hardware identifiers, such as SSAID (Android ID) and IMEI, without limiting required functionality.
#2: Only use an Advertising ID for user profiling or ads use cases. When using an Advertising ID, always respect users' selections regarding ad tracking. Also, ensure that the identifier cannot be connected to personally identifiable information (PII), and avoid bridging Advertising ID resets.
#3: Use an Instance ID or a privately stored GUID whenever possible for all other use cases, except for payment fraud prevention and telephony. For the vast majority of non-ads use cases, an Instance ID or GUID should be sufficient.
#4: Use APIs that are appropriate for your use case to minimize privacy risk. Use the DRM API for high-value content protection and the SafetyNet APIs for abuse protection. The SafetyNet APIs are the easiest way to determine whether a device is genuine without incurring privacy risk.