[Discussion] `getUniqueID` for Android should use another implementation

getUniqueID function for android returns the constant ANDROID_ID. Based on an official post from Google at the android developers blog, the ANDROID_ID is not reliable.

ANDROID_ID seems a good choice for a unique device identifier. There are downsides: First, it is not 100% reliable on releases of Android prior to 2.2 (“Froyo”). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID.

In another document from google, they suggest to identify the app create a UUID and store it at the internal storage.

In cases where an Instance ID isn’t practical, custom globally unique IDs (GUIDs) can also be used to uniquely identify an app instance. The simplest way to do so is by generating your own GUID using the following code.

They also recommend to not use the ANDROID_ID.

#1: Avoid using hardware identifiers. Hardware identifiers such as SSAID (Android ID) and IMEI can be avoided in most use-cases without limiting required functionality.

My suggestion is change the getUniqueID function to return a previously generate UUID. If there is no one available, generate it, store it and return that value. Basically is to implement the google’s suggestion.

WDYT? I am offering to implement this.

\cc @machour

Refs: https://github.com/rebeccahughes/react-native-device-info/issues/60

[schumannd]

When will this be merged? I can see the current behavior causing bugs for people, as it did for me. Not only does the android getUniqueID() not produce a hex number of length 32 like the iOS version does, it doesn’t even reliably produce a 16 length hex. Some models (maybe even all?) drop leading zeroes. Sure, it was my fault for assuming it didn’t do that, but I can see this happening to other people as well. Having to manually pad the output of getUniqueID also seems unnecessary.

So +1 to this PR!

[SandroMachado]

I think that we should keep this on native side, to take the advantage of the apple/iOS api, that is really well designed.

On Android, like I said before, I can make a PR to update this API to match the iOS behaviour (removing the vendor logic) since they have an API to generate UUID (UUID.randomUUID().toString();). WDYT?

Also, to generate a UUID on JS side, from my search, I didn’t find any solution that does not relays on the random string generation method, that is not the most desirable solution since it can lead to collisions and that should not happens.