PATTERN Cited by 1 source
ML-based device eligibility¶
Use production telemetry and machine learning to classify device capability, rather than heuristic rules (memory, release year, OS version) that don't generalize across the Android device landscape.
Structure¶
- Instrument — Collect low-level runtime performance metrics from devices during real feature usage (encoding latency, decode timing, power draw, frame drops, etc.) via a logging pipeline.
- Train — Feed device-level aggregated metrics into an ML model that outputs a capability score (e.g.,
rtc_score). - Gate — Use the score to decide feature enablement per device model: full enable, partial enable (decode-only), or disable.
- Iterate — As more traffic flows through enabled devices, the training dataset grows more representative, enabling further expansion. Self-reinforcing loop.
When to apply¶
- Feature requires specific hardware/software performance (codec, rendering, compute).
- The device landscape is highly fragmented (thousands of Android models).
- Heuristic rules produce too many false positives (freezes, crashes) or false negatives (capable devices excluded).
- You can collect runtime metrics at scale from early adopters.
Canonical instance¶
Meta's AV1 RTC deployment (Source: sources/2026-06-22-meta-adopting-av1-for-real-time-communication-rtc-at-scale): - V1.1 model (August 2025) — broadened AV1 traffic, generated dedicated AV1-only dataset. - V2 model — two-tier approach differentiating higher-end vs lower-end devices. - Result: substantial expansion of AV1 enablement across the Android device landscape.
Seen in¶
Related¶
- concepts/device-eligibility-ml — concept page
- patterns/adaptive-encoder-preset — runtime complement to static eligibility
- patterns/latency-aware-codec-switching — escalation when eligibility classification was too optimistic