Companion architecture

The Uber Driver app vs.
our companion tracker

What the official app actually contains, the sealed boundary around it, and what our own app legitimately observes on the company phone — then reports back.
← System map
The honest mechanism: our app does not read the Uber app. It answers a different, allowed question — “which app is on top of the screen right now?” — and pairs that with Uber's own official trip feed. No hooking, no scraping, no ban risk.
Sealed · not ours

The Uber Driver app

com.ubercab.driver · v4.580.10000 · what it contains (from static analysis)
⚙︎Kotlin Multiplatform + Uber RIBs
Bazel-built, 24 DEX, 118 activities
◷Trip-state engine
offline → online → enroute → pickup → on_trip → dropoff (synced to Uber servers)
◈Maps & navigation
ubermaps-gl, H3 geospatial, Cronet network stack
⛉Identity / KYC & payments
doc scan, selfie liveness, card OCR, 3-D Secure, tap-and-pay
☎In-app voice & messaging
Twilio voice (embedded WebRTC)
🛡 Self-defense: in-house RASP (libse / libeef0 — root, Frida, Xposed, emulator detection) + Play Integrity + SafetyNet. Its live state lives in private memory + Uber's servers. Tampering ⇒ driver account ban.
✗ memory reads ✗ hooking ✗ screen scrape
Android sandbox + RASP — opaque
Ours · on the company phone

Our companion app

Android Enterprise COSU device agent (Kotlin) — runs alongside, never inside, Uber
▦Foreground-app watcher
UsageStatsManager: which app is on top + for how long — incl. “is Uber foreground?”
◉Monitor-only — no hard block
we record which app is on top during shifts; apps are never blocked, closed, or prevented
↥Batched reporter
POST {deviceId, driverId, ts, foregroundPackage, durationMs} — package name only
✕No Uber-app reads
cannot & does not read trip data, taps, or screen content from Uber
✕No content / audio
no keystrokes, messages, mic or camera; working-hours only
How it “tracks” Uber: it sees that the Uber app is (or isn't) the foreground app, and which app replaced it — never what's inside it.
The only on-device observation surface Android legitimately exposes
Foreground app + duration
UsageStatsManager — the TikTok-detection signal
App launches / usage
observed during shifts — never blocked
Device integrity & location
rooted? + on-shift GPS (redundant with Uber's)
Uber notification text
technically readable, but brittle + Uber-ToS-risky — we don't
Uber screen content / trip data
not exposed — comes from Uber's API instead
…and how it reports back
on the phone

Companion agent

“Uber is foreground” / “TikTok is now on top” + duration
device usage
our backend

Correlation engine

joins two inputs ↓ — flags “distracting app while on_trip”
Uber Supplier webhook
true trip state, server-side
coaching flag
human in the loop

Owner dashboard

coaching queue → schooling & training, not auto-discipline

Key: the true trip state (is a passenger on board?) comes from Uber's official Supplier Platform webhook — not from the phone. The phone only contributes which app is on screen. Neither source touches the Uber app's internals.