Android SDK should autogenerate Users

[winsmith]

When no clientUser is specified, the Kotlin SDK should autogenerate a user ID randomly and use that. The user ID should saved on device so it is always the same. On iOS, we use identifierForVendor for this, but AFAIK there is no such thing on Android, right? So we'd have to implement our own using e.g. SharedPreference or other applicable tech.

[guillaume-tgl]

@winsmith would you be open to a PR on that? How about storing the generated user ID in a SharedPreference specific to TelemetryDeck, similarly to what's done in the Swift library?

[kkostov]

There are several types of identifiers provided by the OS for different uses (e.g. ANDROID_ID, Advertising ID etc). Based on https://developer.android.com/identity/user-data-ids and the fact we support API 21, it seems best if we generate and persist a stable identifier ourselves.

For example, a new UserIdentityProvider will check:

• if TelemetryDeck has received a custom identifier via configuration or the signal directly.
• If not, it will look for a File named telemetrydeckid in the application's files folder which contains the user identifier.
• If telemetrydeckid is not found, it will be created.

Note: SharedPreferences is also a possible solution but as it is an Android-specific API it may make it more complex to support Kotlin Multiplatform. A File based approach seems more straightforward.

What we get to:

• Apps adopting the KotlinSDK do not need to opt for special identifier permissions.
• The identifier will be removed when a user uninstalls an app (The KotlinSDK will not "bridge" the user's identity between installations).
• Users can reset the identifier at any time by using the "Clear Data" action in Settings of their device.
• The solution works even on devices without Google Play Services.
• Adopting apps can provide their own implementation of UserIdentityProvider for more flexibility.

Notes on version support:

• For the current TelemetryDeck client introduced in v3, UserIdentityProvider will be configurable via the builder.
• For the deprecated (pre-GrandRename) TelemetryDeckManager, UserIdentityProvider will not be exposed.

Let me know if you have any thoughts or comments @winsmith @Jeehut

[Jeehut]

@kkostov I like the suggested approach, it seems similar to what is done in the Swift SDK today. And I find it important that the solution works without Google Play Services – TelemetryDeck should not require Google, a company known for tracking lots of data.

The only difference for users seems to be that they can delete the data via the "Clear Data" action in their app settings, which doesn't exist on iOS. Do you have any knowledge about how common it is that users do this? Are there apps that "optimize" things for users that can do this as well which some users are using in an automated way? Or do users always have to manually do this through settings?

[winsmith]

Sounds fantastic!

[kkostov]

Do you have any knowledge about how common it is that users do this? Are there apps that "optimize" things for users that can do this as well which some users are using in an automated way? Or do users always have to manually do this through settings?

Users may choose to do this if they want to reset an app to it's "factory" settings, or to free disk space on their device. Some OS may offer tools to perform this automatically, but I'm not aware of this being very common.