Sampark · the SDK

The detection layer. Nothing more, nothing less.

Your behavior change program needs three things scored on every trip — phone use, hard braking, and rapid acceleration. Sampark is the part that makes sure all three are captured, on the devices your drivers actually carry, without a trip getting missed.

Phone use · Braking · AccelerationThree signals, scored per trip
iOS & AndroidOne SDK, same behaviour on both
Realme · Xiaomi · POCOThe devices your fleet uses
15,000 kmLogged and validated in the field
What Sampark detects

Three behaviors. The ones that precede most accidents.

Three signals that behavioral research and field data consistently identify as accident precursors. Accuracy on a narrow target beats guesswork across a broad one.

ML model · live

Phone use

ML on-device identifies active phone use — texting, scrolling, calling without hands-free — and separates it from incidental handling. No network required. A fleet manager can’t coach a driver on something they can’t see. This makes it visible.

Validated · live

Hard braking

Detected from accelerometer and gyroscope, time-aligned with GPS. Threshold calibrated to your fleet before the program goes live — a delivery van on a slope is not a motorcycle at speed. Hard braking responds to coaching faster than any other signal.

Validated · live

Rapid acceleration

Same sensor pipeline as hard braking. Aggressive acceleration after stops predicts hard braking later in the same trip — they’re behaviorally paired. Drivers who score high on both are the highest-priority intervention targets.

Speeding is the next signal we are adding to the pipeline. We are not claiming it until the model is validated. That is the standard we hold for everything on this page.

The devices your fleet uses

Tested on the phones that break every other SDK.

Most SDKs are tested on flagship devices. Most fleets run on Realme, Xiaomi, and POCO — the OEMs whose process killers break background detection within weeks of deployment. We built Sampark on those devices first.

OEM · flagship killer Logged Status What we work around
Realme Realme UI 4 / 5 · 8 / 9 / 11 series
5,200 km Calibrated

Realme Game Space and Phone Manager kill background apps within 10 minutes of inactivity. We use foreground service + AR transitions to survive both.

Xiaomi / Redmi MIUI 13 / 14 / HyperOS · deep doze
4,800 km Calibrated

MIUI auto-start permission, battery saver lockout, and HyperOS background restriction. Our install flow walks the user through three explicit toggles.

POCO MIUI / HyperOS variants
3,600 km Calibrated

Inherits MIUI’s aggressive memory policy with stricter app-lock defaults. Same fix pattern as Xiaomi, with one extra prompt for App Lock unbinding.

Pixel · iPhone Reference behaviour
1,400 km Reference

Stock Android and iOS — the easy case. Used as the calibration reference; if it fails here, we don’t ship.

Vivo / OPPO FuntouchOS / ColorOS · iManager
in pilot Pilot

Currently calibrating against pilot fleet. iManager has its own background-restriction layer above the Android one; expected to ship calibrated by Q3 2026.

Why it holds up

Trips that don’t get missed.

Every behavioral profile is built from trips. A missed trip is a gap in the coaching conversation. Here’s how we ensure trips complete.

01

When drivers quit the app, detection recovers.

Force-quit recovery within seconds. The driver doesn’t reopen the app — the trip completes.

Automatic recovery No driver action Trip always completes
02

All three signals, one trip.

One integration, three signals, every trip — not partial data, not separate SDKs to combine.

Per trip All three signals iOS and Android
03

Calibrated to your fleet, not ours.

Thresholds calibrated against your pilot data — your devices, your geography, your drivers. Not the number that looked good in the demo.

Your devices Your geography Your drivers
04

Data arrives, even without connectivity.

Stored on-device, uploaded when signal returns. Rural areas, tunnels, low-signal zones — no trip is lost.

On-device storage Uploads when ready No gaps
Integration

One init. Same shape on iOS and Android.

One init call, same API surface on iOS and Android. If your team has integrated CMT or Zendrive before, the shape will be familiar. The code samples below are the actual integration — not a simplified version.

  • Single entry point. No subclassing, no service registration, no manifest gymnastics. Sampark.configure(...) is everything.
  • Identical signatures. If you’ve done iOS, the Kotlin reads like a translation. Same callbacks, same field names, same semantics.
  • Strongly typed events. Trip, score, sensor health, permission state. Every callback ships a versioned payload your code can pattern-match on.
  • Backend-agnostic. Use our backend or yours. The SDK just emits signed JSON to whichever endpoint you configure.
// iOS · Swift
import Sampark

let sampark = Sampark.configure(
    tenant: "acme-insurance",
    region: .in_south,
    onTripStart: { trip in
        analytics.log("trip.start", trip.id)
    },
    onTripEnd: { trip in
        backend.submit(trip)
    }
)

sampark.setUser(id: currentDriver.id)
sampark.start()
// Android · Kotlin
import com.sastram.sampark.Sampark

val sampark = Sampark.configure(
    tenant = "acme-insurance",
    region = Region.IN_SOUTH,
    onTripStart = { trip ->
        analytics.log("trip.start", trip.id)
    },
    onTripEnd = { trip ->
        backend.submit(trip)
    }
)

sampark.setUser(currentDriver.id)
sampark.start()
// Backend · trip.completed payload
{
  "version": "2",
  "event": "trip.completed",
  "trip": {
    "id": "trip_01HZ8X7K4M...",
    "user_id": "drv_aaa111",
    "start_at": "2026-05-03T08:42:11Z",
    "end_at": "2026-05-03T09:05:38Z",
    "distance_km": 12.4,
    "score": { "overall": 82,
                "smoothness": 88,
                "focus": 76 },
    "placement": "mounted",
    "transport": "car"
  },
  "signature": "sha256=..."
}
Honest envelope

What we admit. What we fix.

A detection gap is a profile gap. Every SDK has failure modes. Vendors that don’t name them haven’t shipped at scale.

Will degrade

Airplane mode for two weeks.

We buffer locally with checkpointing, but at some point disk pressure or OS cleanup wins. Trips after day 14 may be partially lost on aggressive devices.

Fix: Lower-frequency local heartbeat & explicit user prompt at day 7.

Heavy use envelope

Heavy commute users see more drain.

Idle CPU is 0%. But a 90-minute daily commute with hard maneuvers will use measurable battery — on the order of 3-5% per hour of active driving.

Fix: We show you the per-driver envelope on call, not a marketing average.

Solved

Force-kill.

The big one. Most SDKs lose detection when the user swipes the app away. Sampark uses geofence wake-up and AR transitions to recover within 30-90 seconds of motion.

Fix: Layered recovery, validated across 15,000 km of real-world data.

Get integration access

Ready to see what it detects on your fleet?

30 minutes with the engineer who’d own your integration. Bring your device list — we’ll tell you exactly what to expect, including where the SDK will degrade.

Book a 30-minute call