privacysuraksha_consent 0.1.1

DPDP consent notice for Flutter apps — the Flutter shell of the Compliant mobile SDK.

privacysuraksha_consent

The Flutter shell of the Compliant mobile consent SDK. It shows the same DPDP notice a website visitor sees — the same compiled bundle, not a re-implementation — inside a webview_flutter WebView.

Install

dependencies:
  privacysuraksha_consent: ^0.1.0

Use

void main() {
  CompliantConsent.onError = (e) => debugPrint('$e');
  CompliantConsent.start(CompliantConfiguration(
    siteKey: 'pk_live_...',
    apiBase: Uri.parse('https://api.privacysuraksha.com'),
    appKey: 'app_...',
    signalWriter: (signals) => yourAnalytics.setConsent(signals),
  ));
  runApp(const MyApp());
}

Call start() once, from main(). A second call is refused and reported through onError.

For an in-app privacy entry point: CompliantConsent.show(CompliantView.prefs).

Mount the surface once — never conditionally

The WebView's lifetime is the session's, not the notice's. A successful consent POST sends a second update carrying the server-assigned record id, and it can arrive after the notice has already hidden. If you build the consent surface conditionally, that update is lost and your consent records lose their server id, with no visible symptom. Mount it once and hide it with Offstage.

Storage

storage defaults to SecureCompliantStorage (Keychain on iOS, EncryptedSharedPreferences on Android). Supply your own CompliantStorage to use an existing secure store. Never supply one backed by unencrypted storage.

On Android, EncryptedSharedPreferences is included in cloud backup while the key that decrypts it is not, so restoring a backup onto a different device produces a payload this SDK cannot read. It treats that as "no stored decision": a fresh identifier, and the notice shows again. That is the same thing a reinstall does.

What this does and does not prove

The app key ships inside your app bundle and can be extracted from it. A consent record from your app is therefore attributable to a registered app surface for your site — not to a verified genuine install of your app. State the weaker claim. Device attestation is tracked separately.

A reinstall produces a new identifier and the notice shows again. That is correct behaviour, not a bug.

Measurements

Every latency figure this SDK reports comes from an emulator or a simulator. None of it was measured on physical hardware, and none of it may be quoted as a device SLA.