Repeatable Camera Input for App Testing on Android

Anyone who has tested a camera feature knows the problem: the lens never sees the same thing twice. Light shifts, hands shake, the test card is a little further away. A bug that appeared on Tuesday refuses to show up on Wednesday. For scanners, filters, recording features and anything that analyses frames, that randomness makes testing slow and results hard to trust.

The idea: controlled camera input

With DRVCAM on a rooted test phone, the app you are testing receives a controlled camera source. You choose the clip or image, how it is framed, and how it plays. The source is repeatable, although decoder timing and the target app's own processing can still vary between runs.

What teams use it for

• Scanner and recognition features: feed the same QR code, document or test pattern and check the result every build.
• Recording and upload flows: record a known clip through the app, then compare the saved or uploaded file with the source.
• Filters and effects: run the same scene through each version and compare output side by side.
• Orientation and framing: use rotation, mirror and aspect-ratio controls to cover portrait, landscape and front-camera cases without moving the phone.
• Demos for stakeholders: show a feature working on a predictable scene instead of whatever is on the desk.

A simple test setup

1. Prepare a small set of test media: an asymmetric pattern (so you can spot rotation or mirroring at a glance), a QR code or document image, and a short clip with motion.
2. Import them into DRVCAM's library and save your standard cases as Main and Presets 1 to 4.
3. Select the app under test as the target and tap Enable.
4. Run your test, then switch presets from the floating controller for the next case.

Recorded checks, with boundaries

Setup	Observed result	What it does not prove
OnePlus 12R, Android 16	Selected PNG and moving H.264 frames appeared in the Facebook Live composer.	No Go Live action was performed; this is not a broadcast claim.
OnePlus 12R, Android 16	Selected image and video appeared in YouTube's local creation preview before its account gate.	No upload or stream transmission claim.
Xiaomi M2102J20SI, Android 15	Open Camera preview switched virtual video → physical scene → virtual video.	Only this recorded device/app/camera path.
Rooted emulators, Android 13/15/16	Controlled Camera1, Camera2 and CameraX consumers received replacement frames.	Pipeline evidence, not physical-device or third-party-app compatibility.

This evidence does not prove every app or device; it establishes only the exact combinations shown. Test the same device, Android build, target app and camera path that you plan to ship.

Verify the output, not the preview

This is the most important rule. An app's on-screen preview and what it actually saves or sends can differ: formats, orientation handling, cropping and compression all happen after the preview. A good test checks the real result:

• the photo or video file the app saved,
• the file or stream it uploaded,
• or the result it produced, such as a decoded QR value.

DRVCAM's own preview is there to help you choose and frame media. The app under test is the source of truth.

Things to plan for

• You need a rooted test device with an Xposed framework. Many teams keep one or two dedicated test phones for this.
• Results can vary between camera modes; test the modes your users actually use.
• Some manufacturer camera apps use proprietary camera modes; test your own app, or a standard camera app, rather than a vendor one.

Testing on a PC? See the Android emulator camera guide.

Getting started

If your team wants to try this workflow, download the free version. Image sources, such as a QR code or the test card above, work without a paid plan. Every paid plan includes the app's features, including video sources; test the exact setup you are shipping.

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