Traffic Monitoring shield
EVIDENCE-FIRST NETWORK OBSERVABILITY · Android macOS Version →

Know your network usage - and the evidence behind it.

Traffic Monitoring measures how much data an Android device used, when and on which network, while preserving attribution confidence, continuity gaps and explicit Unattributed usage.

AndroidE1 implementedField validation pending
Traffic Monitoring Android

DECIDE

How much network behavior can Android support with trustworthy attribution?

The project separates usage totals from provenance. When attribution context is ambiguous or continuity breaks, the evidence remains explicitly Unattributed instead of being forced into a confident story.

"Measure before claiming. Preserve uncertainty. Make results auditable."

Android network observability should not rely on opaque cloud meters or unverified background assumptions. When attribution context is ambiguous, evidence must stay explicitly Unattributed.

✓ Deterministic attribution✓ Evidence with provenance✓ User-controlled export
PRODUCT PHILOSOPHY

What Makes It Different

Traffic Monitoring separates usage totals from attribution provenance and technical diagnostics.

Question 01

What happened?

How much data did this Android device use, when, and on which Wi-Fi / hotspot / mobile network?

  • Total bytes used, download vs upload breakdown
  • Timeframe filtering (Today, 7d, 30d, This month, Custom)
  • Per-network ranking & peak detection
Question 02

How do we know?

How much of that usage is supported by trustworthy evidence, and where did measurement continuity break down?

  • Deterministic attributed vs unattributed intervals
  • Evidence Coverage percentage calculation
  • Measurement Health states (Good, Limited, Degraded)
  • Continuity gap tracking & discarded interval logs

BUILD

Build provenance into the data pipeline, not only into the UI copy.

Platform signals, raw evidence, deterministic attribution, derived product state and export are separated so the final interface can explain both the usage and how that conclusion was produced.

4-TIER LOCAL ARCHITECTURE

4-Tier Local-First Architecture

Decoupled data pipeline from system callbacks down to user analytics and ZIP export.

Tier 01

Android Platform Signals

Captures interface transitions, device RX/TX counter statistics, process lifecycle events, and coarse safety-net recovery.

ConnectivityManagerInProcessNetworkMonitorPendingIntentNetworkMonitorTrafficStatsWorkManager recovery
Tier 02

Raw Evidence & Attribution Engine

Normalizes network metadata, persists raw un-summarized observations, and computes interval confidence (attributed, unattributed, discarded).

CurrentNetworkReaderValidationDatabase (Room)AttributionEngine
Tier 03

Derived Product State

Allocates accepted attribution intervals into fixed 5-minute time windows and deterministically evaluates Evidence Coverage % and Health.

UsageDatabaseUsageBucketAllocator (5m)EvidenceSummary Evaluator
Tier 04

User Experience & Export Pipeline

Renders Jetpack Compose UI surfaces and packages engineering diagnostic ZIPs or future Evidence Packs.

ProductScreen (Overview/Networks)EvidenceScreenObservabilityDashboardScreenValidationExporter (ZIP)

TEST

Expose uncertainty as a first-class product state.

Overview, Networks, Evidence and Monitor surfaces test whether usage, provenance and engineering diagnostics can remain understandable without collapsing them into one confidence level.

UX BOUNDARY

Product UX Surfaces

A clean, restrained UX boundary separating usage, evidence provenance, and lower-level diagnostics.

Usage UX

Overview

"What is my device network status and top-line usage?"

Current network state, total bytes used, download/upload breakdown, usage trend, peak traffic, top networks, and compact Evidence summary card.

Usage UX

Networks

"Which networks account for usage?"

Ranked list of network contexts with human-readable network names, transport type (Wi-Fi, Hotspot, Cellular), byte percentage, and explicit Unattributed traffic.

Provenance UX

Evidence

"How trustworthy is the attribution data?"

Human-readable provenance screen displaying Evidence Coverage %, Measurement Health status with explicit reasons, attributed vs unattributed breakdown, continuity gaps, and discarded interval summaries.

Diagnostics UX

Monitor

"How did Android measure the network?"

Technical diagnostics console surfacing raw ConnectivityManager callbacks, TrafficStats counter snapshots, attribution intervals, recovery logs, and engineering ZIP export.

MEASURE

Measure attribution coverage and measurement health separately.

Evidence Coverage explains how much accountable usage was attributed; Measurement Health captures continuity and integrity. Field-validation gaps remain explicit in the maturity model.

EVIDENCE ENGINE

Evidence Coverage v1 & Measurement Health

Coverage measures attribution ratio; Health measures measurement continuity and integrity.

EVIDENCE COVERAGE FORMULA
accountedBytes = attributedBytes + unattributedBytes
Evidence Coverage % = attributedBytes / accountedBytes

ℹ️ If there is no accountable usage in the selected period, the app explicitly displays "Not enough data" rather than manufacturing 100% coverage.

Good

Coverage ≥ 95% and zero discarded evidence intervals

Measurement was continuous with verified network identity and clean counter deltas.

Limited

Incomplete coverage or some discarded evidence intervals

Some unmonitored gaps occurred or minor counter wrap-arounds required discarding.

Degraded

Coverage < 80%, a gap ≥ 30 minutes, or ≥ 3 discarded intervals

Significant gaps or background interruptions degraded overall attribution confidence.

PRIVACY & TRUST BOUNDARY

Android Privacy & Trust Boundaries

What Stays Protected & Local

  • Operates 100% on-device without cloud dependencies.
  • Records NO packet contents, payloads, or message text.
  • Records NO DNS queries, URLs, or browsing history.
  • Requires NO local VPN traffic interception for v1.
  • Uses event-driven PendingIntent callbacks rather than a forced permanent Foreground Service.

What Is NOT Claimed Today

  • Does not claim 100% background reliability across all Android OEM custom ROMs prior to M5 field runs.
  • Does not claim per-app network locality attribution in v1.
  • Does not transform missing evidence into a PASS privacy verdict.
CURRENT MATURITY & VALIDATION GAPS

Current Project Maturity

Relationship to Android Local LLM Harness

Harness explores reusable on-device AI inference execution on Android. Traffic Monitoring explores how Android can document network conditions and attribution uncertainty around local software. Neither project requires the other to remain useful.

LOCAL AI PILLAR

Android Local LLM Harness

On-device LLM inference runtime, GGUF/llama.cpp execution, and memory/thermal profiling.

EVIDENCE PILLAR

Traffic Monitoring Android

Device network usage measurement, attribution confidence, Evidence Coverage, and diagnostic export.

✓ Implemented Capabilities

  • Persistence & export pipeline (M1A)
  • Counters & in-process evidence engine (M1B)
  • Deterministic attribution & 5-minute bucket store (M3)
  • Product UX (Overview, Networks, Evidence, Monitor) (M4)
  • Evidence Coverage v1 & Measurement Health (E1)

⏳ Field Validation Pending

  • PendingIntent background behavior when process absent (M1C)
  • 48–72h Standard-mode physical device run (M1E)
  • Deterministic attribution replay acceptance (M2)
  • Multi-OEM device matrix validation (M5)

🔮 Planned Milestones

  • Human-readable Evidence Timeline & Evidence Pack (E2)
  • Experiment Mode for bounded hypothesis runs (E3)
  • Deterministic Assertions (PASS / FAIL / INCONCLUSIVE) (E4)

DECIDE AGAIN

Do not turn emulator success into a field-reliability claim.

The next decision is constrained by physical-device evidence: core attribution and Evidence Coverage are implemented, while background behavior, long-duration runs and multi-OEM reliability still require field validation.

CURRENT DECISION

Preserve uncertainty until Android field evidence closes the gap.

Traffic Monitoring Android already implements deterministic attribution, 5-minute buckets, product surfaces and Evidence Coverage. PendingIntent background behavior, 48–72h physical-device runs and a multi-OEM matrix remain validation work, so the project does not claim universal background reliability or transform missing evidence into a PASS verdict.

  • Core evidence model and product UX are implemented
  • Physical-device background validation is still required
  • Missing evidence remains Unattributed or inconclusive, never silently promoted
PARALLEL DEVELOPMENT TRACKS

Two Parallel Development Tracks

Separate roadmaps track Android system measurement reliability (M) and evidence product capability (E).

M ROADMAP

Android Measurement Reliability

M1APASS on emulator

Persistence & Export

Room persistence and engineering validation ZIP export pipeline.

M1BPASS on emulator

Counters & In-Process Evidence

TrafficStats byte delta reader & live in-process callbacks.

M1CImplemented · Field validation pending

PendingIntent Background Monitoring

Manifest BroadcastReceiver & PendingIntent background network availability.

M1EReady · Physical run pending

48–72h Field Protocol

Standard-mode physical device run across sleep, doze, and network transitions.

M5Implemented · OEM matrix pending

Multi-OEM Device Matrix

Validation across AOSP/Pixel, Samsung, and aggressive-background OEM devices.

E ROADMAP

Evidence-First Product Roadmap

E0Documented

Positioning & Semantics

Evidence-first positioning, scope, and truthfulness contract.

E1Implemented · UX ready

Coverage & Health

Evidence Coverage v1 %, Measurement Health evaluation, and explicit Unattributed state.

E2Next milestone

Human-Readable Evidence Pack

Human-readable Evidence Timeline & verifiable portable Evidence Pack.

E3Planned

Experiment Mode

Bounded evaluation runs for testing local software network behavior claims.

E4Planned

Deterministic Assertions

Truthful test outcomes: PASS, FAIL, or INCONCLUSIVE based on evidence threshold.

TRAFFIC MONITORING FOR ANDROID

Measure the usage. Preserve how you know.

Explore the implementation, run the emulator debug script, or contribute physical device evidence across Android and OEM conditions.