P2PSDK derives a stable device identity for each application installation. Consent acceptance is scoped to that identity, so identity changes can require a new decision.
Default behavior
Section titled “Default behavior”| Platform | Default identity source |
|---|---|
| Android | ANDROID_ID when available, otherwise a generated install seed in SharedPreferences |
| iOS | Generated ios-install-* seed persisted in UserDefaults |
| Node.js / Electron | Versioned JSON seed file protected by locking and atomic rename |
| Windows .NET | Versioned JSON seed under application data or configured identity path |
| Linux C ABI | Application supplies and persists an approved stable seed |
When to override identity
Section titled “When to override identity”Provide a custom stable seed only when your product already owns a non-secret, per-install identifier and can preserve it across launches. Do not use a user email, advertising identifier, hardware serial, API key, or value shared by multiple devices.
Consequences of changing identity
Section titled “Consequences of changing identity”- A different device ID is derived.
- An existing accepted decision no longer matches.
- Revoke must target the identity associated with the current instance.
- Backend reporting sees a new logical installation.
Storage requirements
Section titled “Storage requirements”Keep generated identity files in persistent application data, not temporary or cache directories. Preserve file locking and atomic rename behavior when packaging desktop wrappers. Do not copy one installation's identity into another.
Reinstall behavior
Section titled “Reinstall behavior”Whether an operating-system reinstall or app reinstall preserves identity depends on platform storage behavior. Design rewards and account reconciliation so a new installation can safely complete consent again.