Virtual Camera Not Working on Android? 10-Minute Fix Guide

A virtual camera module on a rooted phone is a chain of small parts: root, a Zygisk-capable setup, an Xposed-style framework, the module itself, and the app you want it to feed. When the picture does not show up, one link in that chain is broken. This guide walks through the chain in order, so you can find the broken link in about ten minutes. It applies to any root-based virtual camera module that works through an Xposed-style framework such as LSPosed or Vector, not just one product.

Step 1: Confirm root really works

Everything else depends on root, so test it first. Open your root manager and check that it reports root as active, not just installed.

• Magisk: the home screen should show an installed version, and the Superuser tab should list the apps you have allowed.
• KernelSU: the manager should show the working state, and root is granted per app in its Superuser list.
• APatch: the manager should show the patch as active after the patched boot image is flashed.

If the manager says root is not active, nothing below will help until that is fixed. See Magisk vs KernelSU vs APatch for how the three differ, and the official Magisk documentation for installation details.

Step 2: Framework, module and scope

An Xposed-style module only runs inside apps that are in its scope. Check three things in order:

1. Zygisk is on. In Magisk it is a switch in Settings and needs a reboot to take effect. On KernelSU and APatch you use a Zygisk module instead.
2. The framework is active. Open the LSPosed or Vector manager. It should say it is active after a reboot. Installing it and not rebooting is the most common reason a module does nothing.
3. The module is enabled and the target app is ticked in its scope. An enabled module with an empty scope affects no app.

If you are setting this up for the first time, How to Install DRVCAM on Rooted Android covers the full order of steps.

Step 3: Restart the target app

A hook is applied when an app process starts. An app that was already open when you enabled the module keeps running without it. Force stop the app from Android settings (or swipe it away from recents), open it again and test. If that does nothing, reboot the phone once, then open the app fresh.

Step 4: Read the symptom

Most failures show up as one of a few symptoms. This table maps each one to the usual cause and the first thing to try.

Symptom	Likely cause	First fix
"Launch failed" or the module will not start	Root not granted to the module, or the framework not active	Allow the module in the root manager, confirm the framework is active, reboot
Real camera still shows	App not in scope, or app was already running	Tick the app in scope, force stop it, reopen
Black screen	Source file unreadable, or the app opened the camera before the module was ready	Check the file still exists and is readable, close the camera in the app, reopen
Green screen or blank first frame	Pixel format or timing issue on the first frame	Close the camera in the app and open it again
Frozen frame	Playback paused, or source stopped after a switch	Press play, restart the source, restart the app
Image rotated or mirrored	The app rotates or mirrors the front camera on its own	Use the module's rotate and mirror controls until it looks right on the receiving side
Wrong aspect, stretched or cropped	Source ratio differs from the camera frame	Set framing to match the camera frame or a fixed ratio, or use media in the ratio the app expects
Preview works, still photo fails	Still capture uses a different path from preview	Test live preview and video instead, or try another app
Works after reboot, stops later	Another module or battery manager kills the helper	Disable conflicting modules, exempt the module from battery optimisation
App closes or refuses to run	The app does not allow rooted devices	Not a bug to fix. See the section on apps that detect root

Step 5: Camera2, CameraX or the app's own capture

Android apps reach the camera in different ways. Camera2 is the framework API, and CameraX is a Jetpack library that sits on top of it and is simpler for developers. Some apps, especially those with special camera modes, use their own capture code or vendor-specific paths. A module can handle one path and not another, which is why the same module may work in one app and fail in the next.

Three quick tests narrow it down:

• Preview versus still photo. If live preview works and a still photo fails, the app uses a separate still-capture path.
• Front versus back camera. Try both. Some apps mirror the front camera, and a module may treat the two differently.
• A second app. If a different camera app works, the module is fine and the first app uses a path it does not cover.

Step 6: Permissions, SELinux and storage paths

Newer Android versions restrict how apps read files from shared storage, and the rules changed several times between Android 10 and Android 16. A module that reads your photo or video from a folder can fail if that folder is not readable by the process that needs it. Signs are a black screen with a correct environment check, or a source that works until you move or rename the file.

• Keep the source file in a plain, stable location and do not move it while the module is running.
• Check the module's own storage and file permissions in Android settings.
• If a root manager log shows an SELinux denial, note it down for support rather than changing SELinux mode yourself. Switching SELinux to permissive weakens the device and is rarely the right fix.

Step 7: Apps that detect root or hooks

Some apps check whether a device is rooted or modified and refuse to work, or close right after opening. Banking, payment, government and identity apps do this deliberately to protect users. That is a security decision by the app's developer, not a fault in your setup.

This guide does not cover getting around those checks, and you should not try to bypass the security of banking, government or verification apps. If an app you rely on needs an unmodified device, use it on a device that has not been rooted. For the general picture of how Android integrity checks relate to root, see our Play Integrity and root guide.

Step 8: Module conflicts

Two modules that hook the camera at the same time can interfere with each other. If you have more than one camera-related module installed, disable all but one, reboot and test again. The same advice applies to other framework modules that hook the target app. Turn modules off one at a time to find the one that causes the problem, instead of removing everything at once.

Step 9: When to switch tools

Keep troubleshooting if you can see a clear cause. Consider another tool when:

• The module you use has not been updated for years and your Android version is newer than anything it was tested on.
• The failure is in an app that needs a capture path the module does not cover.
• You have gone through the checklist below twice and the root manager, framework and scope all look correct.

Our comparison of virtual camera apps for Android in 2026 lists the options and which ones are still maintained.

A 10-minute checklist

1. Open the root manager and confirm root is active.
2. Confirm Zygisk is on (Magisk) or a Zygisk module is installed (KernelSU, APatch).
3. Open the LSPosed or Vector manager and confirm it is active.
4. Confirm the virtual camera module is enabled.
5. Confirm the target app is ticked in the module's scope.
6. Allow the module in the root manager's superuser list.
7. Force stop the target app and reopen it.
8. Check the source file still exists and plays.
9. Disable any other camera-related modules, reboot, test again.
10. Test a second camera app, front and back, preview and still, then note what differs.

How DRVCAM handles this

DRVCAM is our own virtual camera for rooted Android, and it has built-in checks that follow the same order as this guide. One build covers Android 9 and newer.

• Run the diagnostic. Go to Settings, Diagnostics, Check Environment, Run. The sheet shows Root Access (Ready), DRVCAM Module (Active) and Overlay Permission (Granted, needed only for the floating controller), plus how many apps are in Selected App Scopes. A line that is not green points to the broken link, and the DRVCAM user manual has a troubleshooting section for each one.
• Selected-App Diagnostics. Settings, Selected-App Diagnostics, Read shows the state of the apps you selected. It is useful to have open when you contact support.
• Camera Source switch. On Home it switches between your virtual media and the phone's real camera, so you can tell whether a problem is the app or the module. This is a paid-plan feature, as are the floating controller and presets.
• Rotate and Mirror. Quick Controls on Home fix the rotated or mirrored picture some apps produce on the front camera.
• Remote Diagnose. Under Support in Settings, this switch lets our support connect to your device to look at the problem. Leave it off unless support asks you to turn it on.

The manual also notes two known limits: some phones' built-in camera apps use special camera modes that are not supported yet, and taking a still photo inside a camera app can fail while live preview and video recording work. If you are stuck, contact us on Telegram, WhatsApp or by email with the app name, phone model, Android version and what you see.

DRVCAM is a tool. You are solely responsible for how you use it, and DroidRooter is not responsible for any illegal use.