Hi, I was wondering about Unique Identifier Best P...

# android

[Archie]

Hi, I was wondering about Unique Identifier Best Practices.

I've seen implmentations where,

Settings.Secure.getString(context.contentResolver, Settings.Secure.ANDROID_ID)

is used as a "Unique Identifier" but this prompts a warning in Lint saying, that it is not recommend. With the message:

Using these device identifiers is not recommended other than for high value fraud prevention and advanced telephony Using these device identifiers is not recommended other than for high value fraud prevention and advanced telephony use-cases. For advertising use-cases, use AdvertisingIdClient$Info#getId and for analytics, use InstanceId#getId

I'm not quite sure if my use-case falls under the use of this value.

I also wonder why this isn't mention in Best practices for unique identifiers. And so by reading the Documentation, I found out about DRM API and was wondering if this is a better alternative to the one above.

I'd really appreciate any feedback. Please share your thoughts. Thank you very much.

[okarm]

What is the use case you have in mind?

[Archie]

We need to identify the device + authenticated user but when then user uninstalls and reinstall the app and logs in again (same user), we need to have the same identifier.

[Paul Jervis]

@kosmologist Android don’t like that. That ANDROID_ID doesn’t guarantee that the ID would be consistent. What I’ve done in the past is utilised cloud storage to persist an ID but, obviously, if someone cares enough, they’ll be able to bypass it. Android used to allow collection of certain information like MAC addresses but now it returns 000000:00. There is also inconsistent implementation between vendors. The other option is the Advertising ID but that is slightly easier to reset than the ANDROID_ID. My last usage of these things was for fraud prevention and we had to accept the in-build limitations.

[Paul Jervis]

also this isn’t really a Kotlin question so would be better placed on Stack Overflow 😄

[Archie]

@Paul Jervis have you tried the DRM approach?

[Paul Jervis]

I haven’t used the MediaDRM (DrmManagerClient has been deprecated) because the ID can be reset the same as the ANDROID_ID one. It is more about concurrent use or sharing a file between devices so if a new PROPERTY_DEVICE_UNIQUE_ID is created, it is only a detriment to the user with regards to DRM. If you’re just trying to track the user then that’s going to become harder and harder. If you want to message me directly with more context I may be able to give a hand but this discussion isn’t about Kotlin.

[Tom Hermann]

Keeping track of hardware identifiers is strongly discouraged. I’m still a bit confused of the use-case keeping track of hardware, especially if there is a user identity that you can determine when they log back in on a clean install.

[Archie]

The app could be used without signing in..

[Tom Hermann]

Depending on why you want to track the user I’d have a different suggestion on ways to accomplish the task, so that’s why I ask.

Personally, I would avoid ANDROID_ID or anything hardware related, especially if this is an app you’re distributing in the Play Store. You might get away with it, but Play Protect does scan for people doing sketchy things, and I have had apps pulled because of it. (Luckily they let us fix it!)

A few options:

You could just embrace a fresh install as fresh, and start them back off from square one.

You could ask to write to external storage and look for an optional file: https://developer.android.com/training/data-storage

You could use the advertising id, if you follow their requirements (and if you expect play services to be present on your target devices / resetting the ID doesn’t totally break an important workflow)

You could force them to log in and/or use something like smart lock to streamline the authentication process.

[Archie]

This isnt our usecase, but how about for fraud protection? Being able to detect if the same device is used everytime... would this justify the use of android id?

[Paul Jervis]

Android ID renews after Factory Reset, so it won’t protect against the hardcore fraudsters. Combining Android ID with a file stored in Google Backups (or whatever it’s called) means if they sign in with the same Google account it will likely pull that same ID back in, but if someone is factory resetting their device to commit fraud, they are also likely making burner accounts. Depends what you’re trying to defend against.