Use of SharedPreferences means id is not preserved across installs...
Closed this issue · 5 comments
The general idea with this plugin is that you get a unique device id that persists across app installs. Since SharedPreferences are removed along with the app on uninstall, this means that the UDID changes every time you install the app, effectively negating this plugins value. Anyone can generate a uuid and store it somewhere when they first initialize their app.
Is there a way to ensure that the UDID persists across app installs?
No, without seeking the phone & call permission (because this), I couldn't find a way to do so i.e. ensuring that UDID persists across app installs.
Anyone can generate a uuid and store it somewhere when they first initialize their app.
For the same way, we stopped using this plugin at all and since we were already using Firebase, we started using Firebase instance id to get a unique id (which of course is not same across app installs).
But if your app's business requirement truly wants the UDID to be the same across app installs, you can still use the original plugin and appeal (or submit a form) to Google with the reason of requirement of call permission.
And then cross your fingers if Google accepts your reason and allow your app. 😄
Feel free to reply back to discuss. I'm going to achieve this repository.
Why could we not just use the Secure.ANDROID_ID, and just run a hash on it to produce a full guid? While I understand there are edge cases, for most use Secure.ANDROID_ID in and of itself should be sufficient for a persistent unique identifier. I don't believe you need to use the TelephonyManager for this...so you wouldn't need the permission to make calls. (Why Android stuffs the device info underneath the TM I'll never understand...)
The device.uuid from the Cordova device plugin uses the same Secure.ANDROID_ID which can be also used.
https://medium.com/@ssaurel/how-to-retrieve-an-unique-id-to-identify-android-devices-6f99fd5369eb
Why Android stuffs the device info underneath the TM I'll never understand...
I too had the same question since the start 😄
Hmm...I am not sure device.uuid is actually constant across installs. I was originally using that, and it seemed to change frequently, which is why I moved to using unique device id, which originally seemed to be consistent across installs (although it has that darn telephony dependency).
If Secure.ANDROID_ID is not consistent then I guess there may well not be any way to generate a truly unique id per device... How the heck can that be so hard... O_o