Sonos makes hardware. Their entire product category exists at the intersection of software and hardware integration. If any company should understand device variance, HAL stacks, and the consequences of speculative hardware access, it is Sonos.

Their Android app — the ACR (Acoustic Component Runtime) — force-installed on a CAT S61 running Android 9 and triggered a multi-hour crash-recovery cycle that left the device non-functional for the better part of a working day.

Failure mode

The Sonos app almost certainly probed microphone and sensor APIs on startup for Trueplay acoustic calibration. On the CAT S61's non-standard dual-HAL camera stack, this access destabilised cameraserver. Android's crash recovery attempted to restart the failed service and failed. The exponential backoff timer doubled. This repeated for hours.

• No minSdkVersion enforcement — app installed on Android 9 without rejection
• No uses-feature declarations filtering incompatible hardware configurations
• cameraserver destabilisation confirmed on the CAT S61 dual-HAL stack
• Multi-hour exponential backoff crash cycle — 30s → 60s → 120s → 240s → 480s intervals
• Device returned to normal operation only after waiting out the backoff sequence

Pattern

This is not a novel failure mode for Sonos. The 2020 incident that force-bricked legacy speakers via a forced firmware update. The 2024 app redesign so catastrophically received that the CEO who shipped it eventually resigned. In each case the pattern is identical: a narrow internal test matrix, aggressive deployment, and production users absorbing the cost.

The Sonos app does not need camera access. It has no camera feature. Whatever it was doing on startup, it should not have been doing it without a compatibility gate on a device it had not tested on.

Google Play is the install gate. Every app on this page got through it. That is not incidental — it is the mechanism.

Play's compatibility filtering is entirely dependent on publisher declarations: minSdkVersion, uses-feature, and manual device catalogue exclusions. When a publisher fails to declare requirements, Play has no basis to filter. The device looks compatible because no incompatibility was asserted. The install proceeds. The device breaks.

Google operates the largest device telemetry infrastructure on the planet. They know which devices have non-standard camera stacks. They know which devices are EOL. They have the data to identify high-risk install combinations before the user ever sees an install button. They have chosen not to act on it unilaterally.

What this means in practice

A CAT S61 — a Play-certified Android device with a documented non-standard dual-HAL camera configuration — was allowed to install the Sonos ACR app without a single warning, compatibility advisory, or friction of any kind. The gate exists. It was left open. The user absorbed the cost.

The Play Console device catalogue allows publishers to exclude specific device models. That tool exists because Google knows device-specific exclusion is sometimes necessary. Making it the publisher's problem to know which devices to exclude, rather than Play's problem to flag known-incompatible combinations, is a policy choice.