I Hijacked Android's Forgotten Audio Sink to Capture System-wide Audio

Tahskajuha — Mon, 15 Jun 2026 18:11:39 +0000

It was early 2024 when I got my Samsung Galaxy Tab A9+ 5G. I still remember rooting it almost instantly while keeping the stock ROM because I am a heavy Samsung DeX user. Being somewhat of an audiophile, I also installed Viper4Android and gradually turned the tablet into my personal media hub for music, podcasts, radio, YouTube, and Twitch.

Thing is, I spend much more of my time on both my laptop and my unrooted phone than on the tablet. Controlling playback is simple enough with VLC's remote control feature and this is the part where I thought to myself:

"Wouldn't it be cool if I could stream the tablet's audio output, after all processing and effects from V4A, to my laptop and phone?"

Initially it sounds like an easy problem. What follows is a record of a project that grew into three separate repositories, and a solution that I still use every day.

Disclaimer: This article documents my personal experimentation on a rooted Samsung Galaxy A9+ 5G (SM-X216B). This is not a guide or a recommendation but rather just a record of what I tried, what broke, what I understood (mostly, what I misunderstood), the compromises I had to accept, and what ended up working for me under specific constraints.

Any code, patches, configuration changes, or binaries mentioned here are provided strictly for reference. If you choose to experiment with similar modifications, you do so entirely on your own risk.

⠀

Let's Start With The Existing Solutions

The most obvious solution was Bluetooth. The problem with it is that it never really fit my workflow. Most of the time my headphones were already connected to either my phone or laptop because that's where I was actually working. A2DP works for streaming audio from the tablet to the laptop which is actually what I used right until I deployed my own solution; but, you can't stream from Android to Android with it. On top of that, I was never particularly fond of the codec compression and general RF congestion that comes with University life.

The next place I looked was Android's own capture APIs. Applications like Zoom and Google Meet can capture both audio and video during screen sharing through the MediaProjection API. Unfortunately, MediaProjection comes with a deliberate limitation as applications can just opt out of being captured by setting FLAG_SECURE. This was suboptimal, especially because A2DP does not have this caveat and I really did not want to downgrade my system to the point where any app could just make my life miserable by adding one line into its code at any point.

The solution needed to be application-agnostic and it was clear that achieving that on this layer was not feasible. I needed to go deeper.

I Might Have Gone a Little Too Deep

Heads Up

This next section is just a bunch of me trying to come up with a very questionable hardware solution and inevitably achieving absolutely nothing useful.

I just included this part for historical accuracy. You can go ahead and skip it entirely without missing anything other than the gradual escalation of my misery.

Alright, given the constraints, I needed to think outside the box. I just decided that the box in this case was the entire tablet. I mean, if the software is gonna stop me from getting a hold of the audio output then I will just take it from where the output is actually supposed to go: the audio jack.

The idea started simple-ish. Take the output from the audio jack, make it look like something a mic would produce and then just send it back through the same jack it came from. Once the output became a physical input, it would no longer be subject to Android's playback capture restrictions.

Unfortunately, the Devil's in the details. Headphone outputs operate at volt-level signals while microphone inputs expect millivolt-level signals, so the signal had to be attenuated, filtered, AC-coupled, and conditioned before it could even be considered safe to connect.

This is what I ended up with after several iterations in LTSpice:

This circuit solves the signal-conditioning part. Unfortunately, microphone detection completely breaks it.

See, modern devices don't just accept microphone input because a signal appears on the microphone pin. They first verify that something resembling a microphone is connected by measuring the resistance presented to the jack. The resistor needed for microphone detection ended up fighting with the already tiny audio signal I was trying to inject.

Surprisingly, I had a moment of lucidity at this point as I realized that the amount of time-and-money required for building a mono hardware solution that wasn't even guaranteed to work had made the cost-to-benefit ratio touch grass.

And hence, the "hardware approach" failed entirely.

It Ain't Over Just Yet

Ok, the hardware route did not work out. That's a long amount of work down the drain but, whatever. There's still a problem to solve. At this point, I had explored both ends from hardware to high level API; the only sensible option left was something in-between. So, I decided to go diving into the Android audio stack. This led me to looking through audio sinks and if any of them could be intercepted. During that, I came across remote_submix.

It's circa Android 4, before MediaProjection API was even conceived. Prime time, if not a little behind its competitors for Android to introduce features such as Miracast, Screen Capture, and other stuff requiring audio output capturing. Back then, to implement that stuff, a special audio sink was designed to act as a pipe that the output could be routed through. Thus, remote_submix was born.

As of present day, on modern Android, remote_submix has been almost entirely phased out in favor of the MediaProjection API. But it is still just sitting there as a free audio sink. In fact, android actually still allows access to it if you use either root or ADB shell, as long as you still use the MediaProjection API as the entry point to interact with (which is an oversimplification of what scrcpy does to capture audio).

First things first, I wanted to see what would happen if I made remote_submix always available. So, I pulled /vendor/etc/r_submix_audio_policy_configuration.xml to modify and make a Magisk patch out of it. All I had to do was just add one line really:

<module name="r_submix" halVersion="2.0">

    <attachedDevices>
    <item>Remote Submix In</item>
+   <item>Remote Submix Out</item>
    </attachedDevices>

    <mixPorts>
        <mixPort name="r_submix output" role="source">
            <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                     samplingRates="48000"
                     channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
        </mixPort>

        <mixPort name="r_submix input" role="sink">
           <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                    samplingRates="48000"
                    channelMasks="AUDIO_CHANNEL_IN_STEREO"/>
        </mixPort>
   </mixPorts>
.
.
.

I applied the patch and realized that things had worked a bit too well.

See, remote_submix is special in a way that it is the only virtual sink that does not interface with any hardware on a device. A benefit of that is several times faster initialization compared to any other audio sink. Since Magisk patches are applied at boot which also happens to be the time when Android decides priority of every audio output, remote_submix always wins and becomes default.

Not an issue since I can probably use Tasker or just a basic shell script to change which audio sink to use as long as it is available. I am also personally not the type to complain when my beer is too cold.

So, let's go forward and try to capture audio from it using an the AudioRecord API to see if this sink can be captured. And, this is what I got:

permission denied: capture not allowed

So even remote_submix was a subject to Android's capture restrictions. I suppose it was a bit naive of me to expect otherwise. Now, I am just back to square one.

I Am Really Starting to Get Sick of This

Time to directly tackle the layer causing all of this. While the sink configuration is defined in an XML file, all the policy is enforced via binaries written in C++. If I were on a Pixel device, I would have gone directly to AOSP long ago. Unfortunately, OneUI source, while derived from AOSP is proprietary. I have no idea what changes are made to the binaries I want to target.

With no other option left, I decided to open up Ghidra. I pulled /system/lib64/libaudiopolicyservice.so from the tablet and imported it into the program. I then searched for the string "permission denied: capture not allowed" and found this:

This looked promising at first, but what really convinced me I had found the correct enforcement point was the Knox branch sitting right underneath the capture checks.

Knox is Samsung's enterprise security framework. A dedicated whitelist being implemented here strongly suggested that this was the most optimal spot to do so.

But something was off. There is a specific case for remote_submix and even though I am using it, that is not the branch I am hitting. At that point, though I just decided to patch both branches and call it a day. I just had to apply this minor change in both branches:

- 00150c84 88 06 00 37        tbnz       w8,#0x0,switchD_00150ac8::caseD_0
+ 00150c84 88 06 00 37        b       switchD_00150ac8::caseD_0

Then I rebuilt the library, updated the Magisk module and tested AudioRecord again.

And it worked! AudioRecord started running without errors and printed PCM data that actually looked valid!

Just as a sort of recap, let's go through what I had at this point. For starters, what I did not have was the time I spent on this entire ordeal spanning across 2 years. What I gained in return however, was the ability to capture, modify or stream my tablet's output post V4A, completely app-agnostic.

There was one caveat here too though: I had patched both branches enforcing the rules. This allowed me to also be able to capture audio from every other audio sink on the device as the switch-case was basically entirely neutered.

Basically, in my quest to reroute audio without restrictions, I had scorched earth and opened the Pandora's Box of security concerns. Honestly though, I didn't even care as this was something you would have to write custom code for if you wanted to attack it and as far as I know I am not on someone's hit list... yet...

So, I won. This is the part where I get to live happily ever after, right? Except...

I Got Curious

Ok, that switch-case was clearly modified Samsung and not created by them. I had to know if I could find it in AOSP just because I really wanted to know what was going on.

So, I got my hands on the av repository from AOSP, did some digging and found that my tablet's software version corresponded to the android-platform-14.0.0_r24 branch. After that I again just searched for the "permission denied: capture not allowed" string (God bless ripgrep) and found the implementation in AudioPolicyInterfaceImpl.cpp. Using that I was able to map the decompiled cases and important variables back to their original meanings:

local_434 -> inputType
case 0 -> AudioPolicyInterface::API_INPUT_LEGACY
case 1 -> AudioPolicyInterface::API_INPUT_MIX_CAPTURE
case 2 -> AudioPolicyInterface::API_INPUT_MIX_EXT_POLICY_REROUTE
case 3 -> AudioPolicyInterface::API_INPUT_MIX_PUBLIC_CAPTURE_PLAYBACK

But things still weren't adding up. I was using remote_submix but I wasn't hitting AudioPolicyInterface::API_INPUT_MIX_EXT_POLICY_REROUTE.

So, I decided to look deeper by tracing inputType to where it was being assigned. I found what I was looking for in AudioPolicyManager.cpp:

status_t AudioPolicyManager::getInputForAttr(const audio_attributes_t *attr,
                                             audio_io_handle_t *input,
                                             audio_unique_id_t riid,
                                             audio_session_t session,
                                             const AttributionSourceState& attributionSource,
                                             audio_config_base_t *config,
                                             audio_input_flags_t flags,
                                             audio_port_handle_t *selectedDeviceId,
                                             input_type_t *inputType,
                                             audio_port_handle_t *portId)
{
.
.
.
    *input = AUDIO_IO_HANDLE_NONE;
    *inputType = API_INPUT_INVALID;

    if (attributes.source == AUDIO_SOURCE_REMOTE_SUBMIX &&
            extractAddressFromAudioAttributes(attributes).has_value()) {
        status = mPolicyMixes.getInputMixForAttr(attributes, &policyMix);
        if (status != NO_ERROR) {
            ALOGW("%s could not find input mix for attr %s",
                    __func__, toString(attributes).c_str());
            goto error;
        }
        device = mAvailableInputDevices.getDevice(AUDIO_DEVICE_IN_REMOTE_SUBMIX,
                                                  String8(attr->tags + strlen("addr=")),
                                                  AUDIO_FORMAT_DEFAULT);
        if (device == nullptr) {
            ALOGW("%s could not find in Remote Submix device for source %d, tags %s",
                    __func__, attributes.source, attributes.tags);
            status = BAD_VALUE;
            goto error;
        }

        if (is_mix_loopback_render(policyMix->mRouteFlags)) {
            *inputType = API_INPUT_MIX_PUBLIC_CAPTURE_PLAYBACK;
        } else {
            *inputType = API_INPUT_MIX_EXT_POLICY_REROUTE;
        }
    } else {
        if (explicitRoutingDevice != nullptr) {
            device = explicitRoutingDevice;
        } else {
            // Prevent from storing invalid requested device id in clients
            requestedDeviceId = AUDIO_PORT_HANDLE_NONE;
            device = mEngine->getInputDeviceForAttributes(attributes, uid, session, &policyMix);
            ALOGV_IF(device != nullptr, "%s found device type is 0x%X",
                __FUNCTION__, device->type());
        }
        if (device == nullptr) {
            ALOGW("getInputForAttr() could not find device for source %d", attributes.source);
            status = BAD_VALUE;
            goto error;
        }
        if (device->type() == AUDIO_DEVICE_IN_ECHO_REFERENCE) {
            *inputType = API_INPUT_MIX_CAPTURE;
        } else if (policyMix) {
            ALOG_ASSERT(policyMix->mMixType == MIX_TYPE_RECORDERS, "Invalid Mix Type");
            // there is an external policy, but this input is attached to a mix of recorders,
            // meaning it receives audio injected into the framework, so the recorder doesn't
            // know about it and is therefore considered "legacy"
            *inputType = API_INPUT_LEGACY;
        } else if (audio_is_remote_submix_device(device->type())) {
            *inputType = API_INPUT_MIX_CAPTURE;
        } else if (device->type() == AUDIO_DEVICE_IN_TELEPHONY_RX) {
            *inputType = API_INPUT_TELEPHONY_RX;
        } else {
            *inputType = API_INPUT_LEGACY;
        }
.
.
.
}

So, if the source is remote_submix, Android also expects an address describing where the other end of the pipe is. In retrospect, this makes perfect sense. remote_submix was designed as a routing mechanism rather than a standalone endpoint. If no destination is declared, Android effectively treats the pipe as terminating immediately and falls back to the generic capture path.

The problem is that making remote_submix always available since boot means I don't get to provide an address. Besides, providing an address seems to be possible only via the MediaProjection API and I am so not dealing with that.

So, instead of dealing with the address handling, I decided to just patch this library similar to how I had patched the other library such that the source = remote_submix && address == NULL path assigns *inputType = API_INPUT_MIX_EXT_POLICY_REROUTE. This way I can leave the API_INPUT_MIX_CAPTURE branch untouched, thus significantly reducing the blast radius to just the remote_submix pipe rather than weakening capture restrictions across the entire system. Like using TNT instead of a nuke to get the job done!

Here We Go Again

This time I pulled /system/lib64/libaudiopolicymanagerdefault.so from my tablet and imported it into Ghidra. While there was no clean string to search for this time, I did manage to find the function by its name:

/* android::AudioPolicyManager::getInputForAttr(audio_attributes_t const*, int*, int,
   audio_session_t, android::content::AttributionSourceState const&, audio_config_base*,
   audio_input_flags_t, int*, android::AudioPolicyInterface::input_type_t*, int*) */

ulong __thiscall
android::AudioPolicyManager::getInputForAttr
          (AudioPolicyManager *this,audio_attributes_t *param_1,int *param_2,undefined4 param_3,
          undefined4 param_5,long param_6,int *param_7,uint param_8,uint *param_9,int *param_10,
          int *param_11)

{
.
.
.
}

Now, all I needed to find was everywhere param_10 was being assigned in the function. Then I filtered those to find only the assignments where param_10 was being assigned to 1 and this is what I got:

.
.
.
001c9f24 28 00 80 52        mov        w8,#0x1
.
.
.
001ca228 28 00 80 52        mov        w8,#0x1
.
.
.

Now truthfully, at this point I just decided to just change each one at a time and see if that works and wouldn't you know it, patching the second one to assign the value 2 worked perfectly alongside the new libaudiopolicyservice.so that only had its API_INPUT_MIX_EXT_POLICY_REROUTE branch altered!

Well, I actually have a proof of concept now: a controlled and reliable way to capture and reroute system audio post-processing without relying on fragile APIs or hardware hacks. It isn't scalable to every device out there or even safe enough to do so but it is surprisingly elegant for personal use.

Now all I need is something to actually capture and send the audio over the network and something to receive it that can work both on Android and Linux.

Building The Actual Streaming Stack

Alright, since basically no app out there assumes unfettered access to remote_submix, I had to write my own app that used the AudioRecord API to capture raw PCM, then encode it and send it over the network. This is the part where I decided to create a second repository separate from the Magisk module.

I decided to keep the streamer app intentionally boring: OPUS encoding, RTP over UDP transfer to whatever IP and Port is specified by the user, and defaults that made sense. You can check out the app and its specs here.

As for the receiver part: while I could have gone with WebRTC or GStreamer, I suppose; I wanted something lightweight, cross-platform and something that gave me control over stuff like latency, stuttering, buffer-sizes, etc. More importantly, I wanted something I could just run in the background and forget no matter if it receives packets to decode or not. I decided to therefore make a third repository: a configurable receiver library that any audio framework could call and get raw PCM from. I decided to write it in C and later JNI wrap it to run on Android.

It's currently pretty buggy and won't exactly be competing with the existing giants in this lifetime; but, in my case it gets the job done. In case anyone's interested, you can check the library out here.

Talking about the performance, the current implementation streams stereo 48 kHz audio encoded with OPUS using fixed 20 ms frames.

CPU usage has been negligible in daily use. On Linux, the receiver generally consumes less CPU than applications I routinely keep open anyway, such as Firefox or Hyprland.

Latency depends mostly on the buffering required to avoid underruns. In practice I observe approximately 120-150 ms over USB tethering and roughly 1 second over Tailscale.

I guess a final architecture diagram is in order:

Epilogue

Well, I finally have everything I set out to achieve here. I have been using the entire pipeline for over a month as of writing this. Was it worth it? From a practical perspective, probably not.

Honestly, I am not gonna end this by pretending it was actually about understanding Android better. NOPE. Bluetooth A2DP is still as horrible as when I started this journey, and I am glad to never have to deal with that curse ever again!

I'm off!

PS: for the sake of making this piece of writing somewhat bearable, I decided to cut out and compress several details that I felt weren't relevant. You can find an abridged, albeit slightly outdated at the end version of this thing along with the Magisk module and LTSpice schematic here.

DEV Community: Tahskajuha