📜 ⬆️ ⬇️

Android device identification pitfalls


Some developers may need to identify their users' Android devices. Most often this is done not to recognize the device, but to determine the specific installation of the application. I also met several cases when it was necessary, if the developer had several applications and he wanted to understand that they work in the same environment.

Google says that identifying a device is easy. But we're talking about Android :)

This article is focused on applications or libraries that do not want to be attached to Google services.
')
So let's dive into this wonderful adventure of getting a unique device id.

Here we see several ways:



It looks so far not bad, is it? As many as five ways to get a unique identifier for your Android device. I’m sure that if you still surf the net, you’ll probably find a couple of other ways, but here I’ve made the most popular ones. So let's go in order.

Advertising id


This is a unique ad user identifier provided by Google Play services. It is necessary for advertising to work, so that Google understands which ads can be shown to a specific user and which ads have already been shown using advertising banners embedded in applications. And it also means that you will lose this identifier if your application is downloaded, for example, from Amazon, and besides that you have to drag Google libraries into your application.

dependencies { compile 'com.android.support:appcompat-v7:21.0.3' compile 'com.google.android.gms:play-services:6.5.87' } 

Conclusion: we do not identify the device in all cases.

But we want for sure, right? Then we go further.

IMEI


This is an international mobile equipment identifier used on GSM phones. The IMEI number is used by networks to identify smartphones and block access to a network of devices that have been stolen or blacklisted. But unfortunately with IMEI there may be a number of problems:


 <uses-permission android:name="android.permission.READ_PHONE_STATE" /> 

 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { String imei = telephonyMgr.getImei(); } else { String imei = telephonyMgr.getDeviceId(); } 

Conclusion: we do not identify the device in all cases and can still deceive us: C

MAC address


Not reliably 100%. Google itself speaks about this , but, unfortunately, I did meet a couple of applications that relied on the MAC-address of the device. Do not do this.
It may be possible to retrieve a Mac address from a device's WiFi or Bluetooth hardware. We recommend not identifying. To start with, not all devices have WiFi. Also, it’s not a problem.

Serial Number


It is considered the unique serial number of the device, which remains with it until the “very end”. You can get it in this way:

 //Until Android 7.1 (SDK 25) Build.SERIAL //Android 8 (SDK 26) ++ Build.getSerial() 

And now about the problems. First, to obtain the serial number, you will need to request the user permission READ_PHONE_STATE , and the user may refuse. Secondly, the serial number can be changed .

Conclusion: we do not identify the device in all cases, we have to ask permission from the user, who are cheating them up and can still deceive us.

Android ID


- Here it is! - we have to scream. - The solution to all our troubles!

Android ID is also a unique device identifier. It is a 64-bit value that is generated and stored when the device is first loaded.
You can get it like this:

 Secure.getString(getContentResolver(), Secure.ANDROID_ID); 

It would seem that such a short line relieves us of the headache of identifying the device. Even the guys from google use Android_ID for LVL in the example.

And here our hopes are crumbling and nothing will be the same. After upgrading to Android 8, Android_ID has now become unique for each installed application. But, besides this, Google cares about us, so applications that were installed before the update will remain with the same identical identifiers that Google stores with the help of a specially written for this service . But if the application is removed and then reinstalled, the Android_ID will be different. In order for this not to happen, you need to use KeyValueBackup.


But this backup service needs to be registered, also specify the package name. Moreover, the documentation says that it may not work for any reason. And who is to blame? Nobody, just like that.

General conclusion


If you have a good backend, then simply collect a snapshot of the device (installed applications, services, any data about the device that you can get) and compare the parameters already there, consider a percentage of changes acceptable.

PS I publish all the collections as always in the telegrams on the @paradisecurity channel, and the link can be found in my profile, or found in the search for telegrams by name.

Holiday greetings:)

Source: https://habr.com/ru/post/434726/


All Articles