On this page
Flutter SDK
Add the dependency, call start() once, and the signals below arrive on their own. There is no event taxonomy to design first and no tracking plan to keep up to date.
Published on pub.dev · drengr_flutter_sdk.
Before you start
| Runtime | Flutter 3.16.0 or newer, Dart SDK 3.0.0 up to but not including 4.0.0. |
|---|---|
| Permissions | Nothing beyond what your app already needs to make network calls. |
| Publishable key | Console, under Settings. It is a publishable key, safe to ship in client code: it can only append events. |
Install
flutter pub add drengr_flutter_sdkStart it
In lib/main.dart. Your publishable key is safe to ship in client code: it can only write.
import 'package:drengr_flutter_sdk/drengr_flutter_sdk.dart';void main() { Drengr.start( publishableKey: 'drengr_pk_YOUR_KEY', ingestUrl: 'https://ziryfxrwrvnunwjupgfg.supabase.co/functions/v1/ingest', appPackage: 'com.example.myapp', ); runApp(const MyApp());}// screen_view needs this observer — without it you get taps and network only.// MaterialApp(navigatorObservers: [Drengr.navigatorObserver])Add the navigator observer, or you get no screens
MaterialApp(navigatorObservers: [Drengr.navigatorObserver])What arrives on its own
You do not instrument these. They are captured from the moment start() runs. The third column names the Flutter API behind each one, so you can check the claim against your own app.
| Signal | What it records | Where it comes from |
|---|---|---|
| screen_view | Every screen or route the user lands on | DrengrNavigatorObserver, a RouteObserver on didPush and didPop |
| tap | Taps, with the element's own label when it has one | GestureBinding.instance.pointerRouter.addGlobalRoute |
| net / net_fail | Outgoing requests: host, path, status, duration, size | DrengrHttpOverrides, an HttpOverrides subclass that chains your existing one |
| crash | Uncaught exceptions with their stack | FlutterError.onError plus PlatformDispatcher.instance.onError |
| rage_tap / dead_tap | Repeated taps that did nothing — the friction signal | The same global pointer route as tap |
| rage_scroll / dead_scroll | Scroll thrash and scrolls that moved nothing | The same global pointer route as tap |
| app_foreground / app_background | Lifecycle, which is what sessions are built from | WidgetsBindingObserver.didChangeAppLifecycleState |
| identify | Your own user id, when you choose to send one | Your own call to Drengr.identify() |
IngestSink batches in memory and flushes on background, so a dropped connection costs nothing.
app_package is the identity the console groups by. Use your real bundle id, not a display name.
Labels are redacted and capped on device before they leave the app.
What never leaves the device
Emails, phone numbers, card numbers and government ids are detected and sealed on the device before the first byte is sent. Our servers hold ciphertext they cannot open. Labels and URLs are redacted and length-capped on the device too.
And what is never collected in the first place:
| Not collected | How you can tell |
|---|---|
| Screen recordings, screenshots or DOM snapshots | There is no column for pixels or markup on the events table, and no SDK reads the framebuffer. |
| Keystrokes | Tap capture records that a tap happened and the element's own accessibility label. No SDK attaches a key or text listener. |
| Raw request and response bodies | What is stored is a safe dotted-path projection, redacted and capped at 64 KiB on the device before anything is sent. |
| Authorization headers, cookies and API keys | Masked by name before capture, along with password, pin, cvv, ssn, otp and iban field names. |
| An IP address on the event | The events table has no ip or geo column, so no stored event carries one. |
| Advertising or cross-app identifiers | Identity is a random install_id the SDK generates. No IDFA, no GAID, and no device fingerprint is used for identity. |
Most autocapture tools promise not to look. This is built so we cannot. Full design in Security and Privacy.
Consent and opt-out
Start paused behind a consent gate with Drengr.start(enabled: false), then resume once the user agrees. A persisted opt-out always wins over that argument, so an opted-out install stays paused across restarts.
| Start paused | Drengr.start(enabled: false) |
|---|---|
| Opt out | Drengr.optOut() |
| Opt back in | Drengr.optIn() |
| Where the choice is stored | SharedPreferences (drengr.opt_out), mirrored to a temp marker for the synchronous check at start |
Retention, deletion and what a GDPR or CCPA request maps to are on Privacy controls.
Check it worked
Run the app and use it for a few seconds, then open the console. Overview checks for your first event every 15 seconds on its own, so you do not need to keep reloading.
Nothing showing up
The first five happen on every platform. The rest are specific to Flutter.
| What you see | Why | Fix |
|---|---|---|
| No events at all, and Overview never leaves its empty state | The key belongs to a different organisation, so the writes are accepted against a tenant you are not looking at. | Copy the key again from Settings in the organisation you have open in the console. |
| Events exist but your app is missing from the picker | app_package does not match the scope you are viewing. | Use your real bundle or package id, the same string on every launch. A display name will create a second app. |
| Events appear only after you close the app | Not a bug. The queue batches in memory and flushes on background, which is what makes a dropped connection free. | Background the app once, or wait for the next flush. Nothing is lost in the meantime. |
| Screens are empty but taps and network arrive | Screen capture is the one signal that can be wired separately from start(). | Check the screen hook for your platform in the table above. |
| Nothing arrives after a user opted out | Working as intended. A persisted opt-out outranks the start argument and survives restarts. | Call the opt-in method for your platform. See Privacy controls. |
| Taps and network arrive, screen_view never does | navigatorObservers was not wired, so no route change is observed. | Add Drengr.navigatorObserver to MaterialApp.navigatorObservers, as shown above. |
| A handful of events arrived from someone who had opted out | The durable check is async and start() is not. Opt-out is stored in SharedPreferences and mirrored to a temp marker for the synchronous read at start; if the OS purged that marker, capture runs until the reconcile lands. | Nothing to configure, and the window is short. If you need a guarantee of zero events, gate with start(enabled: false) from your own consent record and opt in after. |
| Requests through package:http are missing | Capture is installed through HttpOverrides, which covers dart:io HttpClient. | Use a client that goes through dart:io, or file an issue with the client you use. |
Where to go next
Once events are arriving, these are the things worth doing, in order.
- Wire up consent and opt-outThe gate, the persisted opt-out, the 180-day window and the deletion call.
- Take the event inventory as JSONThe same signals, hooks and exclusions as a machine-readable contract for your pipeline or review.
- Bring in what you already havePoint an existing Amplitude or Segment pipe at us, or import your history.
- Drengr ActuatorThe separate MCP server that gives an agent eyes and hands on a real device.
Not ready to install anything?
Drop a .har of traffic you already have and see the business events your current analytics is missing. It runs in your browser; nothing is uploaded.
Scan for blind spots →