Privacy & user consent

Since SDK 2.3.0, Kotzilla ships a universal consent gate for integrators who must obtain user opt‑in before any telemetry leaves the device (GDPR, ATT‑style prompts, kids‑category apps, and similar requirements).

Off by default: no behavioural change on upgrade

The consent gate is opt‑in. If you do not set consentRequired = true, the SDK behaves exactly as in 2.2.x and starts collecting immediately. Existing integrators see no change when upgrading to 2.3.0.

Enable the gate

Turn the gate on in your app / shared / ComposeApp module's kotzilla {} block:

kotzilla {
    consentRequired = true
}

With the gate armed, the SDK buffers telemetry locally and sends nothing until you record a consent decision. This works on every platform (Android, iOS, JVM, JS/WASM) and on the early‑start (auto‑boot) path.

The consent API

All methods are available on KotzillaSDK (Android) and KotzillaCoreSDK (KMP / other platforms). You can call them from any thread.

Method	Purpose
setConsent(KotzillaConsent.GRANTED)	User opted in: buffered telemetry is replayed and collection continues live.
setConsent(KotzillaConsent.NOT_GRANTED)	User declined: buffered telemetry is wiped, in‑flight uploads cancelled, collection stops.
getConsent()	Returns the current decision.
isConsentRequired()	Returns whether the build armed the gate.
forgetMe()	Local wipe: clears all stored data, sets NOT_GRANTED, drops in‑flight uploads and native crash files.

// After your consent dialog resolves:
if (userAccepted) {
    KotzillaSDK.setConsent(KotzillaConsent.GRANTED)
} else {
    KotzillaSDK.setConsent(KotzillaConsent.NOT_GRANTED)
}

Synchronous‑durable at the seam

setConsent(...) and forgetMe() are durable when they return: the decision is persisted, the platform storage seam has flushed (Android commit(), JVM Java Preferences, JS/WASM localStorage, iOS NSUserDefaults.synchronize()), and any required local wipe is complete. forgetMe() never throws: privacy primitives always appear to succeed, and boot recovery re‑completes any interrupted wipe on the next launch.

How the gate behaves

The public API is binary (GRANTED / NOT_GRANTED), but internally the SDK tracks the moment before the user has decided:

State	When	Behaviour
Disabled	consentRequired = false (default)	Collects immediately, as in 2.2.x.
Pending	consentRequired = true, no decision yet	Telemetry is collected and buffered locally; nothing is sent.
Granted	setConsent(GRANTED)	Buffered telemetry is replayed, then live collection continues.
Not granted	setConsent(NOT_GRANTED)	Storage is wiped, in‑flight uploads cancelled, native crash files purged. No request body reaches the backend after the call.

• Pre‑boot calls are queued. setConsent / forgetMe / setUserId invoked before the SDK finishes booting are recorded in order and replayed once boot completes, so you never have to worry about timing.
• setUserId is consent‑aware. Under Pending, the identifier is held in memory and only written to disk on the transition to Granted. Under Not granted it is a silent no‑op: the user ID never touches disk pre‑grant.
• Mid‑session revoke is immediate. setConsent(NOT_GRANTED) during a live session flips the gate before HTTP teardown, drops the event buffer, wipes storage, and purges native crash files in one synchronous sequence.

Android backup exclusion

When the gate is enabled, kotzilla-sdk-android-startup contributes manifest entries that exclude Kotzilla's storage (KotzillaPrefs.xml) from Android Auto Backup and Device Transfer, so a restore to a new device or user account cannot carry over a stale consent decision or any pre‑grant buffered data.

Manifest merger conflict if you ship your own backup rules

If your app already declares android:dataExtractionRules or android:fullBackupContent, AGP will report a manifest‑merger conflict at build time. Resolve it by mirroring these two lines into your own rules file:

<exclude domain="sharedpref" path="KotzillaPrefs.xml"/>

The conflict is intentional: Kotzilla will not silently overwrite your backup configuration.

Downgrade safety

Pre‑consent buffered events and crashes are stored under storage keys that older SDK versions cannot read. If you hot‑rollback from a 2.3.x build to a 2.2.x build, a batch buffered before consent was granted will not be transmitted by the older SDK.