# VolumeManager sets per-app audio volume with Shizuku and hidden APIs

> VolumeManager is a Kotlin Android app that changes each app's volume independently by writing to the internal volume multiplier of every active audio player, using Shizuku for privileged API access. It suits Android 13 users who want per-stream control, and it differs sharply from screen-recording based alternatives that add latency.

**yume-chan/VolumeManager** — Control each app's volume independently.

- Repository: https://github.com/yume-chan/VolumeManager
- Stars: 593 · Forks: 42
- Language: Kotlin
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/yume-chan-volumemanager

## Volume per app, and the Android version floor

VolumeManager is an Android app whose whole purpose is stated in one line: control each app's volume independently. It is written in Kotlin, it is licensed under GPL-2.0, and it carries a bold work in progress notice at the top of its documentation, which is the first thing to weigh when you are deciding whether to install it. The technical requirement is Android 13, and that floor is a consequence of the mechanism rather than a policy choice, since the app depends on platform APIs that only exist from that release onwards. The distributable package is moe.chensi.volume, and the documentation links it to two app repositories, IzzyOnDroid and an RB shield repository, so it is available outside the Google Play store for anyone who prefers that route. The screenshots in the documentation are explicitly labelled as coming from a beta version, and the author notes that the download for that build is available from action artifacts, which is a candid way of saying the beta is not in a store. The repository itself is a conventional Gradle Android project with an app/ module, fastlane/ for release automation, a baselineProfile/ directory and the standard gradle wrapper files.

## The four-step mechanism, from active players to volume multiplier

The project documents its own mechanism in four steps, and they are the part worth understanding. First, it calls AudioManager.getActivePlaybackConfigurations() to get the list of AudioPlaybackConfiguration objects, where each configuration represents an audio player such as an AudioTrack or a MediaPlayer. Second, it uses ActivityManager.getRunningAppProcesses() together with PackageManager.getApplicationInfo() to map and group the client PID of each configuration back to the applications that own them. Third, and this is the actual write, it takes the player proxy from the configuration and calls IPlayer.setVolume() to update the internal volume multiplier. Fourth, it registers an audio playback callback with AudioManager so that new configurations appearing later get the current volume applied to them, which is what makes the control stick for apps that start playing after you set the level. The third step is the interesting one for anyone auditing the app, because the write goes to an internal multiplier rather than to a public volume control, and that is what allows it to affect applications that normally resist volume changes.

## Shizuku and the accessibility service

The privilege model is where the friction lives. The app uses Shizuku to access privileged APIs, and the documented usage sequence is short. You install and enable Shizuku, launch Volume Manager and request Shizuku permission, and the app then should automatically enable its accessibility service. That last step is worth pausing on. An accessibility service is a powerful grant, because it can observe and interact with the interface of other applications, and the reason this app appears to need one is the volume button interception described below. The alternative to running Shizuku is not available, since the project does not describe a root-based path, so the install for a new user is a two component setup. Shizuku itself is a separate project that keeps a shell-level session with the system through the Android service manager, and the practical consequence is that Shizuku needs to be running when you want VolumeManager to work, which is a consideration on devices that reboot often or use aggressive battery management.

## Four ways to reach the volume controls

Once the permission is in place there are four ways to change an app's volume, and the documentation is clear about which are on by default. The main interface is the first and is always available. The second is pressing any volume button, which is enabled by default and can be switched off either per app or globally in settings, so the app intercepts the hardware volume keys and shows its own picker instead of the system one. The third is a floating button, disabled by default and switched on in settings. The fourth is a Quick Settings tile, which you add, where a tap opens the popup and a long press opens the main interface. The volume button interception is the feature that makes this app feel native rather than bolted on, and it is also the feature that most changes how your phone behaves, which is why the per-app and global switches exist. For a user who wants the system volume keys to keep working normally and only occasionally adjust one app, the main interface alone is enough and nothing else needs to be enabled.

## How this differs from the MediaProjection approach

The documentation includes a direct comparison with SoundMaster from ShizuTools, and the difference is architectural rather than a feature list. VolumeManager uses a hidden API to directly change each audio stream's volume, while SoundMaster uses the MediaProjection API to record audio from each app and apply post effects. That single difference explains the feature table. VolumeManager can control the volume of protected apps and adds zero latency, because it is writing a number rather than capturing and reprocessing a signal. SoundMaster runs on a lower minimum Android version, 10 rather than 13, and can set the output device for each app, change left and right balance, and offer an equalizer, none of which VolumeManager implements. For the two missing features that are not conceptually impossible, the footnotes are candid. There are APIs to set the output device and to change the left-right balance, but they are not implemented in this app. And the protected app control, which VolumeManager has and SoundMaster lacks, can be worked around on the other side by patching the app. So the trade is real and specific: you choose between a low latency volume writer that needs Android 13, and a post-processing chain that can shape the sound.

## The set-only limitation, and why two apps disagree

The final note in the documentation is the one that changes how you should test the app. This app uses the same API as MIUI's Adjust media sound in multiple apps, and because this API can only set volume and not read it, the volume set by one app will not be reflected in the other one. That is a genuine asymmetry in the underlying platform capability, not a bug in the implementation, and it produces a specific and confusing symptom. If you set a game's stream to 30 percent and then open a music player, the music player keeps whatever volume it had, and if you set the music player to 30 percent the game stays where it was. The value is applied per player rather than tracked in a shared store, so the app has no way to display a consistent picture across apps. Anyone who plans to use this to set up a level once and have it apply everywhere will be disappointed, and anyone who expects the app to show the current level of an app that has been changed elsewhere will see a mismatch.

## Distribution, releases and the state of the project

The download section describes a two channel arrangement that tells you how this project is run. The latest development version can be downloaded from action artifacts of the build workflow, and some hand-picked versions are also available from the releases page. The published releases are v0.2 on 2025-08-17 and v0.1 on 2025-04-18, which is a low version number for a project whose documentation calls it a work in progress, and the last push to the repository was on 2026-10-18, so the tree is being worked on between releases. The repository is not archived. The consequence for a user is that the artifact you install may be newer than the one that was announced as a release, and the beta screenshots in the documentation come from a build available only through action artifacts, so you are effectively testing unreleased code. The project sits under the yume-chan organisation, and the app identifier moe.chensi.volume, the Kotlin codebase and the Gradle layout are all consistent with a solo developer shipping an app for personal use and sharing it in public.

## Conclusion

Adopt VolumeManager if you are on Android 13 or later, you use Shizuku already or are willing to run it, and you want per-app volume control with no added latency, including for apps that protect their volume settings. Do not adopt it if you need output device switching, left and right balance or an equalizer, since the comparison table marks all three as not implemented, and do not adopt it below Android 13, which is the stated minimum. Verify two things first: that the hidden APIs it depends on still behave as expected on your device's Android build, since the project is marked work in progress and the mechanism is undocumented, and that your expectation of per-app volume is really per-player volume, because the note explains that this API can only set volume and not read it, so a volume set in one app is not reflected in another. The practical first step is to install Shizuku, enable it, launch Volume Manager, and request the Shizuku permission, then confirm that the accessibility service is enabled automatically.

## FAQ

### What does VolumeManager do on Android?

It controls each app's volume independently by using hidden APIs to change each audio stream's volume directly, and it uses Shizuku to access privileged APIs. It requires Android 13 or later.

### How do I set up VolumeManager?

Install and enable Shizuku, launch Volume Manager and request Shizuku permission, and the app should automatically enable its accessibility service. After that you can change volumes from the main interface, by pressing a volume button, from the floating button, or from the Quick Settings tile.

### How does VolumeManager differ from SoundMaster?

VolumeManager uses a hidden API to directly change each audio stream's volume, so it adds zero latency and can control protected apps. SoundMaster uses the MediaProjection API to record audio and apply post effects, so it works down to Android 10 and supports output device selection, left-right balance and an equalizer.

### Why does the volume set in one app not show up in another?

Because the underlying API can only set volume and not read it, so the volume set by one app is not reflected in another. The project uses the same API as MIUI's Adjust media sound in multiple apps.

### Can VolumeManager set the output device or an equalizer?

No. The comparison table marks output device selection, left-right balance and the equalizer as not implemented, with footnotes explaining that there are APIs for the first two but they are not implemented in this app.

### Where can I download VolumeManager?

The latest development version is available from the action artifacts of the build workflow, and some hand-picked versions are published as releases. The package is also listed on IzzyOnDroid and an RB shield repository under the identifier moe.chensi.volume.

## Sources

- [Issues](https://github.com/yume-chan/VolumeManager/issues)
- [License: GPL-2.0](https://github.com/yume-chan/VolumeManager/blob/main/LICENSE)
- [README](https://github.com/yume-chan/VolumeManager/blob/main/README.md)
- [Releases](https://github.com/yume-chan/VolumeManager/releases)
- [yume-chan/VolumeManager on GitHub](https://github.com/yume-chan/VolumeManager)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yume-chan-volumemanager