First, define the control
The Bilateral investigation began with a narrow question: can the left and right wireless earbuds be controlled independently from an ordinary Android application? The existing project note and hand-drawn path sketch record that question. They do not prove a working app, a tested device, or a universal point in AudioFlinger where every pair of earbuds can be adjusted.
“Left/right volume” hides three different problems. An app can alter audio it produces. A system balance setting can bias playback to one side. A device-specific control would change the gain of one physical earbud independently, including audio from other apps. Those are not interchangeable capabilities. This article maps the boundaries rather than claiming that the third one has been implemented.
Evidence labels used below: OBSERVED means present in the existing Bilateral project material; DOCUMENTED means supported by Android’s published APIs or AOSP documentation; INFERRED is a design implication; NOT TESTED means no implementation or device measurement was available.
What an application can own
DOCUMENTED: Android’s AudioTrack reference includes a historical setStereoVolume(leftGain, rightGain) method. It changes gain on that track and is deprecated; Android recommends the general setVolume method for current app playback. Even where separate track-channel gain works, it does not grant an application control over every other app’s sound or over two Bluetooth devices as independent endpoints.
DOCUMENTED: AudioManager exposes stream-volume operations. A stream-volume index answers a different question from independent left and right physical-earbud gain. Likewise, an accessibility balance control, where a device offers one, should not be described as two arbitrary per-earbud volume sliders without testing its exact behavior.
That distinction changed how I framed the problem. A demo that plays a stereo test signal under its own control could be useful, but it would not establish a system-wide product. The required permission and routing model must be established before promising a universal audio utility.
Follow the path past the app
DOCUMENTED: Android’s audio architecture includes application-facing framework APIs, native audio services such as AudioFlinger, audio policy, and a hardware abstraction layer. The Audio HAL documentation describes the interface between higher-level audio services and the hardware implementation, including routing and playback responsibilities.
OBSERVED: the Bilateral sketch labels an application, framework, AudioSystem, AudioFlinger, and left/right outputs. It is a research map of places to inspect, not a verified signal-flow diagram for a particular Android version, Bluetooth codec, or earbud model. In particular, two arrows drawn from a control point do not establish two exposed, independently addressable Bluetooth sinks.
INFERRED: if the goal is gain applied to all playback just before a specific wireless device renders it, the answer may depend on system privileges, device routing, and vendor processing. The AOSP layering tells us where to look; it does not by itself identify a portable public API that every third-party app can use. Android’s non-SDK interface restrictions are another reason a hidden method is not a sound product foundation.
What the current evidence does not establish
NOT TESTED: I found no Android implementation, device log, firmware trace, paired-earbud experiment, or before/after acoustic measurement in the available project material. Therefore this article does not claim that Bilateral can alter another app’s audio, that AudioFlinger exposes a stable independent-earbud control, or that OEM cooperation is always required.
A proper test would name the Android release, device and earbud model, connection mode, and audio source. It would compare an app-owned stereo signal with audio from a second app, then distinguish a global balance setting from physical per-earbud gain. Repeating the same test on more than one device would reveal whether the behavior is platform-wide or device-specific. Until those results exist, a “viable control surface” is a hypothesis, not a shipped capability.
The useful conclusion of an investigation can be a boundary: track-level control is documented; portable, system-wide control of two earbuds remains unproven here.
Sources and scope
- Bilateral project note and its working diagram for the original question.
- Android AudioTrack API and AudioManager API for application-level controls.
- AOSP audio architecture, Audio HAL documentation, and non-SDK interface guidance for the system boundary.