[device_info_plus_tizen] Expose the Samsung DUID (webapis.productinfo.getDuid())

[ELOUFIR]

Context

We are porting a Samsung TV app from a Tizen web app to flutter-tizen. On the web build, our device identity — the key that identifies a TV in our database — was:

webapis.productinfo.getDuid()

On flutter-tizen we switched to device_info_plus_tizen and are using TizenDeviceInfo.tizenId instead. Per the plugin source that maps to the Tizen platform capability:

// tizen/src/device_info_plus_tizen_plugin.cc
{"tizenId", "http://tizen.org/system/tizenid"},

That is a different identifier from the DUID, which leaves us with two questions.

1. Is it possible to expose webapis.productinfo.getDuid() in the plugin?

Is there a native or TizenFX equivalent we've missed, and if so, could device_info_plus_tizen expose it?

2. Does tizenId survive a factory reset or a firmware update?

If the DUID isn't reachable, this decides whether we can use tizenId as our device key at all — if it changes, the TV no longer matches its record in our database.

We couldn't find this documented anywhere. The Tizen system-key docs only describe the value as "a randomly generated value based on the model name", which doesn't say how it behaves across either event.

• Does it survive Settings > Self Diagnosis > Reset (factory reset)?
• Does it survive a firmware update?

A pointer to existing documentation is just as good as an answer.

Thanks for the plugin.
@seungsoo47

[seungsoo47]

Hi @ELOUFIR,
Thank you for reaching out!
We are currently reviewing your inquiry regarding the DUID exposure and tizenId behavior, and we will get back to you with a detailed update as soon as our investigation is complete.

[seungsoo47]

@ELOUFIR,
Based on my testing so far, when a reset is performed, the Duid changes on the native app, whereas the tizenId does not change. The same is true on the web app - getDuid() changes, but tizenId does not. Have you actually checked getDuid() and tizenId yourself on the web app after a reset? I guess that it would be better to use tizenId if you want a unique value. If you do need getDuid(), I can expose it for you.

[ELOUFIR]

@seungsoo47
Thanks a lot for testing this — that's exactly the data point I was missing.

And to answer your question honestly: no, I haven't tested a reset myself. That's precisely why I asked rather than assuming. On our legacy web app we never had to find out, because we kept the Ethernet MAC address as a fallback unique key — that was our safety net.

So if tizenId is the more stable than Duid, that's good news for us and we're happy to build on it without fallback.
The one thing that still makes me cautious is this line in the documentation:

Key	Type	Description
http://tizen.org/system/tizenid	String	The platform returns TizenID. TizenID is a value that is generated based on the pseudo-random generator.

"generated based on the pseudo-random generator" reads as though the value is produced rather than derived from hardware, which raises three follow-ups:

• Where is it persisted, and what would cause it to be regenerated?
• Does it also survive a firmware update applied from USB (the full re-flash path), not just Settings > Self Diagnosis > Reset?
• Is it guaranteed unique per unit? If the generator were seeded identically on two units of the same model they would collide, and we'd have no way to detect that in the field.

If you can confirm those, we'll standardise on tizenId.

On webapis.productinfo.getDuid(): given your findings it's no longer blocking for us. It would still be nice to have — it's the value a user can read back to us from Support > About TV > Unique ID, which is handy for support.

Thanks again.

[seungsoo47]

@ELOUFIR
After checking internally, tizenId is documented as a "resettable ID", so it's not a fully reliable option either. Given that, using the mac_address, similar to the fallback you already had in your legacy web app, seems like the better approach here, especially on TV.

To get the mac_address in flutter-tizen, you can use tizen_interop (https://github.com/flutter-tizen/tizen_interop). It lets you call native Tizen APIs directly from Dart, such as connection_get_mac_address() or wifi_manager_get_mac_address(), so feel free to use whichever fits your case best.

Let us know if you have any further questions. Thanks!

[ELOUFIR]

@seungsoo47

Thank you for checking internally — that's the definitive answer I was after, and it saves us from building on the wrong identifier. We'll go with the MAC address then.

One last request, if the offer is still open: exposing getDuid() would genuinely help us. Our legacy web app keyed every device record by DUID, so being able to read the same value from the native app would let us match a TV to its existing record when users move over — right now we have no way to link the two. It's also the value a user can read back to us from Support > About TV > Unique ID, which is useful for support.

Completely understand if it's not a priority, but if it's cheap to add we'd definitely use it.
if the DUID happens to be reachable through tizen_interop the same way the MAC address is, that works just as well — just point me at the right native API or header and I'll wire it up myself. I did look, but couldn't find a native entry point for it.

Thanks again for all the help on this.

[seungsoo47]

@ELOUFIR

I am sorry for the late reply.
PR #1106 has been merged in device_info_plus_tizen 1.4.3, which adds a duid getter that exposes the DUID (equivalent to webapis.productinfo.getDuid()).
Note this is only available on TV profile devices - it returns an empty string on other profiles, and null if the vconf key can't be read.

[ELOUFIR]

Thank you for the update @seungsoo47.
Really appreciate your work on this!