How Audio Hooking Modules Route and Record Internal System Streams

Audio hooking modules change how sound flows inside Android apps. They can redirect a stream from one output to another, capture the internal audio that normally plays only through speakers, or replace microphone input with a prepared audio file. A developer can verify app audio with a repeatable sample. A creator can feed clean audio into a live app without a studio. A user with hearing needs can route one app to headphones while another stays on the speaker. The technique is powerful, and it is easy to misunderstand, because the result depends on exactly where the hook sits in the audio path.

This guide explains how audio hooking works in real terms: what LSPosed and Xposed hooking can and cannot reach, how playback capture taps a player before the system mixer, how recording hooks change a source or replace buffers, how routing modules move sound between outputs, and how to set up and test a module without breaking your phone. You will get named modules, named settings, named Android classes, and a test routine you can follow. The goal is not to promise a trick that works everywhere. It is to show you where the hook lives, why some apps resist it, and how to tell a careful module from a vague one.

A note on scope before we start: audio capture carries legal and ethical duties that a video filter does not. Recording a conversation without consent may break the law where you live, and recording a stream may break the terms of that service. This guide covers personal testing, accessibility routing, and creative work with content you own or have permission to use. It does not cover hidden recording, and it treats the privacy indicator as a feature to respect, not a hurdle to remove.

What audio hooking modules actually do inside Android

Android audio starts when an app asks for a playback or recording session. A playback app sends audio data to a player, the player hands buffers to the system audio service, and the service mixes streams and sends the mix to speakers or headphones. A recording app asks for a microphone source, a sample rate, and a channel count, and the system connects that request to hardware or to an internal mix. The system manages routing between sources and outputs, handles focus when several apps want audio at once, and ducks the volume when a notification arrives.

An audio hooking module intervenes at the Java API boundary for those sessions. It can change the parameters of a session before it starts, capture buffers as they pass through a player or a recorder, or change where the finished stream goes. The exact point decides what the module can achieve. A hook at the player level sees one app’s audio before mixing, which is ideal for per-app capture. A hook at the mixer level sees a combined stream and loses per-app separation. A hook that only sees control calls, such as play and pause, can log events but cannot capture sound.

That distinction is the first thing to check in any module description. A module that promises internal capture should name the player or recorder class it hooks, the apps it has been tested with, and the Android versions it supports. A description that only says it records internal audio, with no hook point and no tested apps, deserves scepticism. The best modules are specific about their limits, because the authors know where the Java layer ends and native code begins.

Playback, recording and routing: three different audio hooking jobs

Playback capture takes the audio an app plays and writes it to a file, or sends it somewhere else, without going through the microphone. Recording replacement changes what a recording app hears: it swaps the microphone for a file, or for an internal stream, so the app records the prepared audio instead of room sound. Routing changes where audio goes during playback or recording, for example sending music to headphones while navigation stays on the speaker. One module can do one of these jobs well, and a module that claims to do all three equally well is usually doing one of them properly and the others loosely.

Each job has its own failure mode. Playback capture fails when the app plays audio through a native library that the Java hook cannot see. Recording replacement fails when the buffers arrive too fast or too slow and the timing drifts. Routing fails when the change happens mid-stream and the app goes silent until it restarts. Knowing which job you need tells you which failure to test for, and it keeps you from judging a recording module by live-call latency or a live module by recording quality.

Java hooks versus native audio paths in Android

LSPosed and Xposed modules hook Java methods. They can intercept a call to AudioTrack.write, AudioRecord.read, MediaPlayer.start, or ExoPlayer’s player methods, and they can read or replace the data in those calls. That works well when the app uses the standard Android audio APIs in Java or Kotlin. It works poorly when the app uses a native library such as Oboe, AAudio, or a custom native player, because the audio then flows through native code that the Java hook never sees. The Java layer still sees control calls in that case, such as play, pause, and volume changes, but it does not see the sound itself.

That boundary explains most audio module failures. A user installs a module, opens an app, and hears nothing in the capture file, even though the module worked in another app. The second app used a native player, the first used MediaPlayer, and the module only hooks the Java player. The fix is not a different setting in the same module. It is a module that hooks the native path, or a different approach entirely, such as the system AudioPlaybackCapture API on Android 10 and later, which captures at the system level rather than inside the app.

Where a Java hook can see audio buffers in Android

A Java hook can see audio buffers when the app passes them through a Java class. AudioTrack.write takes a byte array or a ByteBuffer and hands it to the system, and a hook there can copy the buffer before it plays. AudioRecord.read fills a buffer with microphone data, and a hook there can replace the buffer contents before the app reads them. MediaPlayer and ExoPlayer expose their playback through Java methods that a hook can intercept, though ExoPlayer often processes audio in a way that needs a hook at the renderer level rather than at the high-level player. If the app uses one of these classes directly, a Java hook has a clear place to sit.

Where a Java hook only sees control calls and no sound

A Java hook only sees control calls when the app delegates audio to native code. A game that uses Oboe for low-latency audio, a music app that uses a native decoder, or a streaming app that uses a native DRM path will all pass play, pause, and seek through Java while the audio itself stays in native memory. A hook in that situation can log that playback started, and it can change the volume, but it cannot copy the audio. Module authors who are honest about this will list the apps they have tested and say which ones use a native path. Authors who promise capture for every app are promising something the Java layer cannot deliver.

How LSPosed and Xposed hooking works for audio modules

LSPosed is the modern Xposed framework for Android, built on Zygisk in Magisk or on a similar injection path. When an app starts, Zygisk loads the LSPosed framework into the app process, and LSPosed loads each enabled module that lists that app in its scope. The module then hooks the Java methods it cares about, using the Xposed API to run code before, after, or instead of the original method. The hook runs inside the app process, which is why it can see the app’s audio buffers: it shares the same memory as the player or recorder it hooks.

Scope matters. A module should be scoped to the target app only, not to the whole system, because a system-wide audio hook can affect every app and cause crashes in apps the author never tested. In the LSPosed Manager app, open Modules, tap the audio module, and enable it only for the apps you want to capture or route. Restart those apps after you change the scope, because a hook only attaches when the app process starts. A module that is enabled but not scoped to the app will look installed and do nothing, which is the most common setup mistake.

General hook mechanics for this layer appear in material on system hooking inside LSPosed. That background explains Java layer limits, scope, and process loading in clear terms. It also explains why native paths need different tools. Audio work sits exactly on that boundary, and many failures trace to a native path that a Java hook cannot see. Read that background first if you have never used LSPosed, because the audio steps below assume you know how to enable a module and scope it to an app.

Zygisk, LSPosed and scoped module loading for audio

Zygisk is the Magisk feature that injects code into every app process at startup, and LSPosed uses it to load its framework. To use an audio module, you need a rooted phone with Magisk installed, Zygisk enabled in Magisk settings, and LSPosed installed as a Zygisk module. After you install LSPosed, reboot, open LSPosed Manager, and check that the framework version shows as active. If it shows as inactive, the module will not load, and no audio hook will run.

Scoped loading is the safety feature that keeps a bad module from breaking your whole phone. Each module declares which apps it can hook, and you choose the scope in LSPosed Manager. For audio capture, scope the module to the media app you want to capture, such as a music player or a streaming app, and do not scope it to the system framework unless the module author tells you to. A module that needs system scope will say so in its instructions, and it will explain why. If it does not explain why, do not grant system scope.

Hooking AudioTrack, MediaPlayer and ExoPlayer for capture

The three most useful hook points for playback capture are AudioTrack, MediaPlayer, and ExoPlayer. AudioTrack is the low-level class that most players use to send audio to the system, and hooking its write method gives you the raw PCM buffers just before they play. MediaPlayer is the high-level class that many simple apps use, and hooking it gives you control over playback but not always direct buffer access, because MediaPlayer decodes in native code. ExoPlayer is the player used by many streaming apps, and hooking it needs a hook at the audio renderer, where decoded PCM is handed to AudioTrack.

A careful module will hook AudioTrack.write and copy each buffer to a file, tagging it with the sample rate and channel count from the AudioTrack configuration. That gives a clean per-app capture with the original timing intact. A module that hooks only MediaPlayer.start can tell you when playback starts, but it cannot give you the audio. Check the module description for the words AudioTrack, PCM, sample rate, and channel count. Those words signal a module that captures buffers rather than one that only logs events.

Common audio hook points: AudioTrack.write and AudioRecord.read

AudioTrack.write is the playback hook point. It receives a byte array or ByteBuffer, a size, and a write mode, and a hook can copy the data before calling the original method. AudioRecord.read is the recording hook point. It fills a buffer with audio data, and a hook can replace that buffer after the original method returns, so the app reads the replacement instead of the microphone data. Both hooks need to handle the buffer format correctly: PCM 16-bit is the most common format, and a hook that assumes the wrong format will produce pitched or noisy audio. A good module reads the format from the AudioTrack or AudioRecord configuration and matches it exactly.

How internal audio capture works step by step

Internal audio capture means recording the sound an app plays without using the microphone. The cleanest way to do it is at the player level, inside the app, before the system mixer combines that app’s audio with notification sounds and other apps. A hook at AudioTrack.write copies each buffer as it passes, and the module writes those buffers to a WAV or PCM file with the right sample rate and channel count. The result is a file that sounds like the original stream, with no room noise and no speaker echo.

The second way is the system AudioPlaybackCapture API, introduced in Android 10. An app with the right permission can request capture of another app’s playback, and the system gives it the audio through an AudioRecord configured with the REMOTE_SUBMIX source or through the MediaProjection capture path. This is a system-level capture, not a hook, and it needs user consent through a media projection prompt. It works for many apps, but it cannot capture apps that opt out of playback capture, and it cannot capture DRM-protected content. A module that uses this API will ask for the media projection permission, and you should expect that prompt.

The third way is the mixer level, where the module hooks the system audio service and captures the mixed output. That gives you everything playing at once, including notifications, which is rarely what you want for per-app capture. Mixer capture is useful for recording a whole device session, such as a game with voice chat and music together, but it loses the separation between apps. Use player-level capture when you want one app, and mixer capture only when you want the whole mix.

Player-level capture before the system mixer

Player-level capture is the preferred method for most users because it isolates one app. The module hooks AudioTrack.write inside the target app, copies each buffer, and writes it to a file in the app’s private storage or in a shared folder the user chooses. The module should also record the AudioAttributes for the session, so it knows whether the stream is music, a voice call, or a notification, and it should skip streams that are not the target. A module that captures every AudioTrack in the app, including notification sounds, will produce a file with extra bleeps that you did not want.

Timing is the detail that separates a good player-level module from a rough one. The module must write buffers in order, without dropping any, and it must keep the sample rate and channel count consistent from the first buffer to the last. If it drops a buffer under load, the recording will have a gap. If it writes buffers out of order, the recording will sound scrambled. Test with a full minute of audio, not a short clip, because timing drift and dropped buffers appear only in longer sessions.

REMOTE_SUBMIX and AudioPlaybackCapture on Android 10 and later

REMOTE_SUBMIX is the AudioSource that the system uses for internal capture. When an app creates an AudioRecord with AudioSource.REMOTE_SUBMIX, it receives the mixed playback output rather than microphone input. That path needs the CAPTURE_AUDIO_OUTPUT permission, which is a system permission that ordinary apps cannot hold, and it is why most users reach for a module or for the MediaProjection-based AudioPlaybackCapture API instead. The MediaProjection path is the one that a screen recorder uses when you enable internal audio: it shows a prompt, you grant it, and the system hands the recorder the playback audio.

AudioPlaybackCapture has limits you should know. The target app can set its playback to disallow capture by setting the allowCapture flag to false in its AudioAttributes, and many streaming apps do that for DRM content. The capture also stops when the MediaProjection session ends, so a recorder that loses its projection will go silent. If a module promises to capture a streaming app that opts out, check whether it uses a hook inside the app rather than the system API, because only the in-app hook can see the audio before the opt-out applies.

Writing buffers to WAV without pitch or sync drift

A WAV file needs a header that states the sample rate, the channel count, and the bit depth, and the module must write that header correctly or the file will play back at the wrong pitch. A module that captures at 48,000 Hz but writes a header saying 44,100 Hz will sound slow and low. A module that captures stereo but writes a mono header will lose half the sound. A good module reads the sample rate from the AudioTrack configuration, writes the header to match, and updates the file size in the header when the recording ends.

Sync drift is the second problem. If the module writes buffers too fast, the recording will sound rushed. If it writes them too slowly, it will sound choppy. The module should pace its writes to real time, using the timestamps from the audio session, and it should not assume that every buffer arrives at a fixed interval. A steady clock and even spacing produce natural sound. Test the result by playing it back on good headphones and comparing it with the original. A side-by-side comparison reveals pitch and timing flaws that memory hides.

Sample rate, channel count and buffer size matching

Sample rate is the number of audio samples per second, and 44,100 Hz and 48,000 Hz are the most common values on Android. Channel count is usually one for mono or two for stereo, and a module that drops a channel will lose stereo width. Buffer size is the chunk of audio the app hands to the system at once: a small buffer means low latency but more work, and a large buffer means higher latency but fewer interruptions. A module should read all three values from the session and match them exactly in capture and replacement. It should never impose a fixed rate on every app, because a fixed rate will sound wrong in an app that uses a different rate.

How microphone replacement works in recording apps

Microphone replacement changes what a recording app hears. Instead of the microphone, the app receives a prepared audio file, or an internal stream, as if it came from the microphone. A tester can feed a known voice sample into a call app repeatedly and check how the app handles it. A creator can play prepared audio into a live app without a studio. A user with a broken microphone can still use a voice app with a prepared sample, though that is a workaround rather than a fix.

There are two ways to replace the microphone. The first is to change the requested source before the session starts: the hook intercepts the AudioRecord constructor or the MediaRecorder setAudioSource call and changes the source from MIC to a file or to an internal stream. The second is to replace the buffers after they arrive: the hook lets the AudioRecord read from the microphone, then overwrites the buffer with prepared audio before the app reads it. The first method is cleaner, because the app never opens the microphone at all. The second method is more compatible, because it works even when the app checks the source it requested.

Both methods need careful timing. The prepared audio must be delivered at the same sample rate and channel count as the recording session, and it must be paced to real time. Buffers delivered too fast will sound rushed or clipped. Buffers delivered too slowly will sound choppy, with gaps that the app may interpret as silence. Timestamp handling matters here just as it does in video work, and a steady clock with even spacing is what makes the replacement sound natural.

Changing the AudioSource before the session starts

Changing the source before the session starts is the cleanest replacement method. The module hooks the AudioRecord constructor, reads the AudioSource the app requested, and changes it to the source the user chose, such as a file or an internal stream. The app then opens the new source as if it had requested it itself, and the system connects the session to that source. The advantage is that the microphone never opens, so there is no room noise to leak through. The disadvantage is that some apps check the source after they create the recorder and refuse to continue if it does not match what they asked for.

To use this method, open the module settings, choose the target app, and set the replacement source to the file you want to feed in. Choose a WAV file at the same sample rate as the app expects, usually 48,000 Hz for voice apps, and test with a short clip first. If the app refuses the source, try the buffer replacement method below, which is less likely to trigger a source check.

Replacing buffers after AudioRecord.read returns

Buffer replacement is the more compatible method. The module hooks AudioRecord.read, lets the original method fill the buffer with microphone data, then overwrites the buffer with prepared audio from a file. The app reads the buffer and hears the prepared audio, even though the microphone is still open in the background. The microphone data is discarded, so no room sound leaks into the recording, but the microphone indicator will still show, because the app still holds a recording session from the system’s view. That is correct behaviour, and a module that hides the indicator is a module to avoid.

The module must pace the replacement to match the recording session. It should read the prepared file at the same rate the app reads buffers, and it should loop the file or stop cleanly when the file ends, rather than repeating the last buffer or sending silence without warning. Test with a full minute of audio, because timing drift appears only in longer sessions. Listen for a steady voice with no rushing, no gaps, and no pitch change.

Keeping timing natural with a steady clock in audio replacement

Timing is the hardest part of microphone replacement. Real microphone audio arrives at a steady rate, one buffer after another, with no gaps and no bursts. Prepared audio delivered in bursts will sound rushed, and prepared audio delivered with gaps will sound choppy. A good module uses a steady clock, often based on the audio session timestamps or on System.nanoTime, and it spaces its buffer writes evenly. It also handles the end of the file cleanly, either by looping with a short fade or by stopping and letting the app hear silence, rather than by repeating a single buffer.

Test timing with a spoken sentence you know well. Record a minute through the module, play it back, and listen for words that run together or stretch apart. Compare the recording with the original file played directly. If the timing is right, the two should match in length and in pacing. If the recording is shorter or longer than the original by more than a second in a minute, the module is drifting, and it will sound wrong in a live call.

How audio routing modules move sound between outputs

Routing modules change where audio goes during playback or recording. A module might force one app to use headphones while other apps use speakers. It might send a call to a Bluetooth device while media stays on the phone speaker. It might keep navigation voice on the speaker while music stays on headphones. Android routing rules normally apply system-wide per stream type, so per-app routing breaks that global rule in a useful way. It lets you build a personal audio layout for multitasking, travel, and work.

Routing hooks work best when they change routing parameters at session start. The module hooks the AudioManager or the player setup, reads the output device the app requested, and changes it to the device the user chose. The app then opens its session on the new device and plays cleanly from the start. Changing routing mid-stream is harder, because the app may need to rebuild its audio session after the change, and a module that does not handle that rebuild will leave the app silent until it restarts.

Test routing changes during active playback to reveal this weakness. Switch outputs while audio plays and listen for gaps. A clean switch sounds like a brief fade, a short dip, and then the audio resumes on the new device. A broken switch sounds like silence until the app restarts. That test separates good modules from fragile ones quickly, and it is worth running before you rely on a routing module for a live session.

Per-app routing versus system-wide AudioManager rules

Android’s AudioManager sets routing per stream type: music, call, alarm, notification, and system sounds each have their own routing rules. A Bluetooth headset usually takes music and calls together, and the speaker takes the rest. Per-app routing breaks that rule by giving one app a different output than other apps using the same stream type. The module does that by hooking the session setup for the target app and changing the device before the session opens.

The module needs to know which app to route and which device to use. In the module settings, choose the target app, choose the output device, and set whether the routing applies to playback, recording, or both. Some modules also let you set a different output for calls and for media within the same app, which is useful for a live app that plays music and handles a voice call at the same time. Keep the settings simple at first: one app, one output, and test it before you add a second app.

Bluetooth, speaker and headphone splits that actually work

The most useful split is music on headphones and navigation on the speaker. That lets you hear directions while you listen to music privately, and it works well because navigation uses a different stream type than music. The second useful split is a call on a Bluetooth headset while media stays on the phone speaker, which lets you take a call without stopping the music for everyone else in the room. The third useful split is a live app on headphones while system sounds stay on the speaker, which keeps notifications from leaking into a stream.

Not every split works on every phone. Some Bluetooth headsets take over all audio when they connect, and no module can split a stream that the headset itself merges. Some phones route all media to Bluetooth once it is connected, regardless of the module setting. Test each split with the exact headset and phone you will use, and do not assume a split that worked on one headset will work on another. The headset’s own routing behaviour is part of the result.

Why a mid-stream routing change can drop out

A mid-stream routing change can drop out because the app’s audio session is tied to the device it opened with. When the device changes, the session must be torn down and rebuilt on the new device, and the app must handle that rebuild without losing its place. A good module triggers the rebuild cleanly, often by briefly pausing and resuming playback, and the user hears a short fade. A poor module changes the device without rebuilding the session, and the audio has nowhere to go, so the app goes silent. If your routing module leaves an app silent after a switch, restart the app and change the routing before playback starts next time.

Setting up an audio hooking module: a practical walkthrough

Setting up an audio module takes about twenty minutes if you follow the steps in order and test after each one. Do not skip the test steps: a module that looks installed but is not scoped to the app will do nothing, and a module that is scoped but not restarted will also do nothing. The steps below use LSPosed, Magisk, and a generic audio module as the example, because those are the tools most users will have. The exact menu names may vary by module, but the order stays the same: root, framework, module, scope, settings, test.

Before you start, back up your phone. A bad audio module can cause boot loops or crashes in the apps it hooks, and a backup lets you recover without losing data. Use your phone’s built-in backup, or a TWRP backup if you have a custom recovery, and write down the module version you install so you can roll back if an update breaks it.

Step 1: confirm root, Magisk and Zygisk are working

Open Magisk, check that the Magisk version shows as installed and that Zygisk is enabled in Settings. If Zygisk is off, turn it on and reboot. Open a root checker app and confirm that root access works. If root does not work, fix that before you install any audio module, because LSPosed needs root to load its framework. Do not install LSPosed on a phone without working root and expect it to run.

Step 2: install LSPosed and check the framework is active

Download the LSPosed Zygisk module from the official LSPosed release page, install it in Magisk, and reboot. Open LSPosed Manager and check that the framework version shows as active. If it shows as inactive, reinstall the module and reboot again. Do not install an audio module until LSPosed shows as active, because the module will not load without the framework.

Step 3: install the audio module and scope it to one app

Install the audio module APK, open LSPosed Manager, tap Modules, tap the audio module, and enable it only for the app you want to capture or route. Start with one app, such as a music player you know well, and do not scope the module to the system framework unless the author tells you to. Restart the target app after you change the scope, because the hook only attaches when the app process starts. Force-stop the app in Settings, Apps, then open it again.

Step 4: set the capture, replacement or routing options

Open the audio module app, choose the job you want: capture, replacement, or routing. For capture, choose the output folder and the file format, usually WAV, and set the sample rate to match the app, usually 48,000 Hz. For replacement, choose the WAV file you want to feed in and set it to loop or to stop at the end. For routing, choose the target app and the output device. Save the settings and restart the target app again, because some modules only read their settings at startup.

Step 5: run a one-minute test and check the result

Play a known reference sound for one minute through the target app, with the module enabled. For capture, open the output folder and check that a file was created, that its size matches a minute of audio at the chosen sample rate, and that it plays back cleanly on headphones. For replacement, record a minute in the target app and play the recording back. For routing, switch outputs during playback and listen for a clean fade rather than silence. If the test fails, check the scope first, then the settings, then the module version, in that order.

Testing audio hooking modules thoroughly before you rely on them

Audio testing needs a structured routine because ears adapt quickly. A module that sounds fine for ten seconds can drift, drop buffers, or lose stereo over a minute, and only a longer test will catch it. Build a routine you can repeat after every app update, module update, and system update, because audio sessions rebuild on each launch and a module that worked yesterday can fail after an update to either layer.

Start with a known reference sound that you recognise well. Use a short music clip with clear high and low notes, and a spoken sentence with clear words. Capture or route that sound through the module, play the result back on good headphones, and listen for distortion, dropouts, pitch changes, and stereo loss. Compare the result with the original reference directly, side by side, because memory hides flaws that a direct comparison reveals. Repeat the test at low volume and at high volume, because some flaws appear only at one extreme.

Test across app restarts and device reboots as well. Audio sessions rebuild on each launch, and a module that works on first launch may fail after a restart. A module that works after a restart may fail after a system update. Keep a reference file that you use for every test, so the same reference makes comparisons fair across versions. Write down the result of each test, including the app version, the module version, and the Android version, so you can spot a gradual decline before it becomes a failure.

Reference clip test for audio capture quality

Choose a music clip of about thirty seconds with a clear vocal and a clear bass line, and a spoken sentence of about ten seconds with words that are easy to mishear. Capture both through the module, then play the capture back on headphones and compare it with the original. Listen for distortion on loud notes, dropouts where the sound cuts out briefly, pitch changes where the voice sounds higher or lower, and stereo loss where the sound collapses to the centre. A clean capture should sound like the original, with no added noise and no missing notes.

Long-session timing test for audio replacement and routing

Run a full minute of audio through the module, not just a short clip. For replacement, feed a one-minute spoken sample into a recording app and check that the recording is one minute long, with no rushing and no gaps. For routing, play music for a minute, switch outputs halfway through, and check that the audio resumes cleanly on the new device. Timing drift appears only in longer sessions, and a module that drifts by two seconds in a minute will sound wrong in a live call, even if a ten-second test sounded fine.

Retest after app restarts, reboots and system updates

Retest after every change to the app, the module, or the system. Force-stop the target app and open it again, then run the reference clip test. Reboot the phone and run it again. After a system update, run it again before you rely on the module for a live session. A module that survives all three retests is a module you can trust. A module that fails one of them needs a settings check, a scope check, or a newer version from the author.

When audio hooking fits and when it does not

Audio hooking fits personal testing and accessibility workflows well. A developer can verify audio behaviour with repeatable samples. A user with hearing needs can route audio to a preferred device per app. A creator can build a controlled audio feed for a stream using content they own. These uses benefit from precision and repeatability, they involve content the user owns or tests with permission, and they respect other participants and service rules. That combination makes audio hooking a valuable tool.

Audio hooking fits poorly when the goal is to bypass a service restriction, to capture others without consent, or to capture an app that uses a native path the hook cannot reach. In those cases a different tool or a different approach serves better. A direct download with permission may beat a fragile hook. A system audio feature, such as the built-in screen recorder with internal audio, may beat a module for a simple routing need. Check stock Android features first before adding a hook, because stock features carry no module maintenance burden and they survive updates without author intervention.

For neighbouring media topics, explore virtual camera modules for live feeds and camera filters inside live stream apps. Those reads show how video and audio hooks combine in live apps, and where each pipeline reaches its limit. A complete media setup needs both sides understood, and you should test video and audio together for any live workflow, because separate tests can hide sync problems that only appear when both run at once.

Legitimate uses for audio hooking modules

Legitimate uses include testing an app’s audio with a known sample, routing audio per app for accessibility, capturing your own music or voice for personal notes, and building a controlled feed for a stream you own. In each case, the content belongs to you or you have permission to use it, the other participants know what is happening, and the module respects the privacy indicator. Those conditions are the test for whether a use is legitimate, and they are worth checking before you start.

Consent, privacy indicators and service terms for audio capture

Recording a conversation without consent may break the law in many places, and recording a stream may break the terms of that service. Check local law before you capture any audio that involves other people, and respect the service terms for content you do not own. Announce recording when others are involved, and keep the microphone indicator visible. A module that promises to hide the indicator is a module that serves deception, not legitimate testing, and the community should reject it. A technical ability does not create a legal right, and a responsible user checks consent and ownership before capture starts.

Frequently asked questions about audio hooking modules

What is the difference between internal audio capture and microphone recording?

Internal audio capture takes the sound an app plays directly from its player, before it reaches the speaker, so the file has no room noise and no echo. Microphone recording captures sound after it leaves the speaker and travels through the air, so it picks up room noise, echo, and any other sound in the room. Internal capture is cleaner, but it needs a hook or a system API, while microphone recording works with any app and any phone. Use internal capture when you need clean audio from one app, and use the microphone when you need to record a room or a conversation with consent.

Why does my audio module work in one app and not in another?

The most likely reason is the native path. The first app uses a Java player such as MediaPlayer or ExoPlayer, which the module can hook. The second app uses a native library such as Oboe or AAudio, which the Java hook cannot see. Check the module description for the apps it has been tested with, and check whether the failing app uses a native player. A module that hooks AudioTrack will work in apps that use AudioTrack, and it will not work in apps that bypass it. That is a limit of the Java layer, not a settings mistake.

Can an audio hooking module record a call without the other person knowing?

Technically, a module can capture audio from a call app, but doing so without consent may break the law where you live, and it breaks the trust of the other person. Android also shows a privacy indicator when an app records, and a legitimate module preserves that indicator. Do not use a module to record people who believe they are in a private conversation. If you need a record of a call, ask for consent first, announce the recording, and check the law in your area before you start.

Do I need root to use an audio hooking module?

Most LSPosed audio modules need root, because LSPosed itself needs root through Magisk and Zygisk. There are system-level alternatives that do not need root, such as the built-in screen recorder with internal audio on Android 10 and later, and the AudioPlaybackCapture API used by some recorder apps. Those alternatives work for many apps, but they cannot capture apps that opt out, and they cannot replace microphone input. If you need per-app capture or replacement inside a specific app, root and LSPosed are usually the way to get it.

How do I fix an audio module that goes silent after a routing change?

First, restart the target app and change the routing before playback starts, because a mid-stream change can leave the session without a device. Second, check the module scope in LSPosed Manager and confirm the app is still scoped after an update. Third, check that the output device is still connected and that the headset or speaker has not taken over all audio. If the problem persists, try a different output device to rule out a headset issue, then check for a module update from the author. A module that goes silent on every routing change is a module with a rebuild bug, and it needs an update rather than a new setting.

What to do next with audio hooking modules

Start with one app and one job. Pick a music player you know well, scope a capture module to that app, and run the one-minute reference clip test. If the capture sounds clean, try a routing split with headphones and the speaker. If you need replacement, feed a known voice sample into a test app and check the timing over a full minute. Write down the app version, the module version, and the result, so you can retest after the next update.

Then widen slowly. Add a second app only after the first one works reliably across restarts and reboots. Read the module author’s instructions before you capture audio from a new app, because each app has its own player and its own limits. Keep the privacy indicator visible, check consent before you record anyone else, and use stock Android features when they do the job without a module. A careful setup, tested one app at a time, will give you clean internal audio without the crashes and silent captures that come from rushing the setup.