Project Overview
The Problem: Android security restrictions prevent applications from injecting audio streams directly into active voice calls. The Solution: Bypassing public SDK limits, I developed a root-level telephony automation tool integrating ALSA (Advanced Linux Sound Architecture) to inject PCM audio at the kernel mixer level. The Result: Delivered a resilient call-handling automation system with sub-50ms injection latency and automated recovery safety watchdogs.
Technical Overview
This project required moving from the standard Android SDK into the underlying Linux kernel sound subsystem.
- ALSA Integration: Direct hardware-level audio routing via tinyalsa and shell injection.
- Telephony Internals: Using reflection and system services to manage call states beyond the public API.
- PCM Processing: Real-time conversion of audio assets to 8kHz/16-bit mono streams for telephony compatibility.
- Root-Shell Wrapper: A robust, error-handling wrapper for executing high-privilege system commands.
Visual Showcase
System-level diagnostic flow: verifying root access and ALSA mixer path availability before service initiation.
Preferences engine: managing low-level audio routing parameters (gain, delay, looping) through a modern UI.
Systems Trade-offs
When the public API says 'No', you have to weigh the risks of system-level bypasses.
ALSA vs. AudioLoopback
Android's standard loopback is restricted during voice calls. I chose ALSA because it operates at the kernel level, ensuring that the audio injection remains stable regardless of the OS's attempts to mute background applications.
Root Shell vs. Native C++ Wrapper
For rapid iteration, I initially used root-level shell commands. Once proven, I migrated critical paths to native C++ to reduce the overhead of shell spawning and improve injection latency.
System Integrity
Maintaining system stability while operating with root privileges.
- Watchdog Service: Monitors the ALSA mixer to ensure system audio is restored if the app crashes.
- Permission Escalation: Granular handling of Superuser requests to maintain a minimal security footprint.
- Device Profiling: Automated detection of ALSA mixer paths across different SoC architectures (Qualcomm vs MediaTek).
Results & Impact
Achieved stable audio playback into voice calls across all verified SoC architectures.
Reduced the delay between call-answer and audio-start to near-instantaneous levels.
Guaranteed restoration of system audio paths via the hardware-level watchdog service.
The Problem & Constraints
Standard Android APIs prevent audio injection into calls to prevent eavesdropping and spoofing. My constraint was to enable this for legitimate automation while maintaining system stability on rooted devices.
- Problem: Public AudioManager mutes all app-layer audio during an active voice call.
- Constraint: The solution must work without custom ROMs, relying only on standard root access.
- Challenge: Managing 'Mixer Path' variability across hundreds of different Android device models.
- Risk: Potential for permanent audio-silence if ALSA paths aren't correctly reset after a call.
Conclusion & Reflection
Call Blaze demonstrated my ability to operate at the system level. It required bridging the gap between high-level Kotlin/Compose and the low-level Linux kernel sound subsystem. It's a testament to 'Getting it done' when the platform says it's impossible.
Key Takeaways
- Know the Kernel: Understanding what happens below the SDK is the key to solving 'Impossible' problems.
- Safety First: High-privilege code requires twice the amount of error-handling and recovery logic.
- Abstraction: A clean UI can (and should) hide a massive amount of underlying technical complexity.


