Articles ·
Why a Virtual Camera Will Not Work on Android or iPhone
Android and iOS give apps no way to register a virtual camera. Why the platforms block it, what root and jailbreak cost, and a remote desktop fix.
We make CamLooper, one of the tools this article recommends. Why we write these guides.
This is one of the most common questions about fake cams and it has an unusually flat answer: on a stock Android phone or any iPhone, you cannot install a virtual camera that other apps will see. Not because nobody has written one, and not because you have missed a setting. The extension point that makes virtual cameras possible on desktop does not exist on mobile, and its absence is deliberate.
That is worth understanding properly rather than working around badly, because the workarounds people find in app stores mostly do not do what their listings imply.
Why can desktops do this but phones cannot?
Every desktop operating system publishes a documented way for software to add a capture device to the list that other applications see. That is the whole mechanism — a virtual camera is just software using it.
| Platform | Can an installed app add a camera? |
|---|---|
| Windows | Yes — register a DirectShow filter under a CLSID. |
| Linux | Yes — load the v4l2loopback kernel module. |
| macOS | Yes — ship a signed Core Media I/O camera extension. |
| Android | No public API. The camera list comes from the device's hardware layer. |
| iOS | No. AVFoundation enumerates hardware capture devices only. |
On Android, the cameras an app can open are the ones the device's hardware abstraction layer reports. That layer is part of the system image, built by the manufacturer. An installed application cannot add an entry to it. Android does have virtual device and app-streaming machinery, but it is reserved for privileged system roles, not for anything you can download.
iOS is stricter still. There are no loadable kernel extensions, no third-party camera
extensions, and AVFoundation hands an app the hardware devices and nothing else.
Core Media I/O camera extensions — the macOS mechanism — have no iOS equivalent.
The sandbox is the other half of the problem
Even if you could produce frames, you would have nowhere to put them. On a desktop the virtual camera is a system-wide device: one app creates it, every other app can open it. On mobile, each app's camera session belongs to that app. There is no shared device list for an outside process to insert itself into, and one app cannot reach into another's video pipeline. That is the sandbox working as designed, and it is the same boundary that stops an app reading your messages.
The camera indicator is a promise the OS has to keep
Both platforms show an indicator whenever the camera is live — the green dot on iOS, the indicator pill on Android. That signal is only meaningful if it is tied to actual hardware access. A user-installable virtual camera would make it possible for an app to present video while the indicator says the camera is off, or the reverse, and the guarantee would be worth nothing.
Both stores also prohibit apps that misrepresent the camera, so even a technically clever approach has no distribution route. This is not a gap the platforms intend to close.
What about root or jailbreak?
On Android it is genuinely possible. Modules exist that hook the camera layer below the app and feed it a video file, and they work. The cost is the problem:
- Unlocking the bootloader wipes the device and, on many models, is either vendor-locked or permanently flags the hardware.
- Integrity checks fail afterwards. Banking apps, payment wallets and some streaming services detect the modified system and refuse to run. Conferencing apps increasingly check too — so the app you wanted to fool may be the one that stops working.
- It is per-device and fragile. These modules target specific chipsets and Android versions, and system updates routinely break them.
On iOS the question is close to moot: jailbreaks for current hardware and iOS versions are not realistically available to ordinary users.
For a one-off video call, trading your phone's banking apps for a looped webcam feed is a bad deal.
Why the app stores are full of things that look like this
Searching for a fake cam on a phone returns three unrelated categories, none of which is a virtual camera:
- Prank and fake security camera apps — novelty apps that show a fake CCTV interface. These dominate the search results and are the main reason the term is confusing.
- Phone-as-webcam apps such as DroidCam or Iriun. These run in the opposite direction: they turn your phone into a camera for your PC. Useful, but the reverse of what you are looking for.
- In-app filter and replacement tools that alter video inside their own app only. Nothing they produce is visible to Zoom or Teams.
If a listing claims to replace your camera system-wide on a stock phone, it is describing something the operating system does not permit.
What actually works: run the call on a desktop
The reliable answer is to move the call to a machine where virtual cameras are a supported feature. A laptop with CamLooper installed will do it in a couple of minutes: point it at a video file, start the camera, then pick CamLooper Virtual Camera in Zoom, Teams, Meet or Discord. The setup guide covers each app, and the Windows guide covers the traps specific to that platform.
Driving that desktop from your phone with RDP or VNC
If the reason you wanted this on mobile was that you will not be sitting at the desk, you do not need a mobile virtual camera — you need remote control of the machine that has one. Leave a desktop running CamLooper and the conferencing app, and connect to it from your phone with a remote desktop client.
To be clear about what this is: CamLooper has no remote control feature of its own. This is an ordinary remote desktop setup pointed at the machine running it, using tools that already exist.
| Tool | Protocol | Notes |
|---|---|---|
| Windows App / Microsoft Remote Desktop | RDP | Needs Windows Pro or Enterprise on the host. Best audio and microphone redirection. |
| Chrome Remote Desktop | Proprietary | Easiest to set up, free, works across Windows, macOS and Linux. |
| RustDesk | Proprietary | Open source, self-hostable, no account required. |
| RealVNC, TightVNC | VNC | Cross-platform and dependable, but VNC carries no audio. |
The setup is straightforward — but there are four things that decide whether it actually works on the day, and all four catch people out:
- The desktop is the participant, not your phone. The call runs on the desktop. Your phone is a control surface. That machine has to stay powered, awake, and online for the whole call.
- Work out audio before you rely on it. Your phone's microphone is not automatically the call's microphone. RDP clients can redirect the client device's audio and microphone; plain VNC carries no audio at all, so you would need a microphone at the desktop. Test this before it matters.
- Stop the host from locking or sleeping. A display that sleeps, a screensaver, or a session that locks can interrupt the camera or leave you looking at a lock screen. Disable sleep on the host. Note that connecting over RDP locks the physical console by design, which can disturb anything already running in that session — VNC and Chrome Remote Desktop attach to the existing desktop instead and are gentler here.
- Expect latency. Remote control over a phone connection is fine for pressing buttons and watching a preview. It is not good for anything time-sensitive.
In practice you touch CamLooper once. Start the loop before the call, confirm the preview, and the remote session is only there in case something needs fixing. That is a much smaller job than it sounds, and it is the difference between a setup that is genuinely mobile and one that is not.
The simplest version of all
Before building any of this, check whether you need remote control at all. A virtual camera keeps running once started. If the desktop is somewhere you can reach, starting the loop before the call and leaving it alone is usually the whole solution — no remote client, no audio routing, no lock screen surprises.
Whichever route you take, encode the source video at 1280×720 so every app accepts it — see the settings guide. And if the call is one where a live camera is expected of you, it is worth reading what actually gives a looped video away first.