CameraView

Last reviewed Sep 13, 2026 · 899 words

CameraView is a Gradle dependency, not something you install. There is no Docker image, no web UI, and no APK; it is an Android library from natario1 that wraps the miserable Camera1 and Camera2 APIs behind one <CameraView> widget so an app can take pictures, record video, and read raw frames without 2,000 lines of boilerplate. It appears in a self-hosting directory because a class of people use it to turn old phones into surveillance cameras for their own video surveillance stack. If you are not writing an Android app, you do not need it, and the last section says what to use instead.

What it actually handles for you

Drop the view into a layout, add the dependency, and you get a live preview with pinch-to-zoom, tap-to-focus, and exposure gestures configured as XML attributes. Picture capture supports a full-resolution mode and a fast snapshot mode that grabs the preview frame in a few milliseconds. Video recording works in a similar pair of modes, with settings for codec, bitrate, max duration, and file size. The part relevant to camera projects is the frame processor: a callback that hands you every preview frame as bytes with rotation and format metadata, which is what you feed into a barcode reader, an ML Kit face detector, a motion-diff routine, or an encoder. There is also a real-time filter pipeline on the OpenGL preview, so you can render a grayscale or edge-detect view without touching the frames yourself.

The catalogue's "well documented" is fair; the docs site walks through every option, and the 5,130 stars came from Android developers who were tired of Camera2's state machine, not from the self-hosting community.

What it does not do, which is the part that matters here

CameraView captures. It does not stream. There is no RTSP server, no RTMP push, no WebRTC, no MJPEG endpoint. To make a phone show up in Frigate or go2rtc as a camera, you have to take the frames CameraView hands you, push them through Android's MediaCodec for H.264, and serve the result over RTSP with a separate library or your own socket code. That is a solid week of work for someone who has done Android media before and a lost month for someone who has not. CameraView also does nothing about the operational side of a phone-as-camera: keeping the screen off while the camera runs, surviving Doze mode, restarting after a crash, and dealing with the battery swelling when a phone sits on a charger for 2 years.

It is also Android only, Java with Kotlin-friendly APIs, and it targets the older camera APIs. Google's own CameraX library has become the standard answer for new apps, and CameraView's release pace has been slow for a while; I would check the repo's recent activity before starting a new project on it.

The self-hoster's realistic options

If the goal is "old phone on a shelf pointed at the driveway," the answer is an existing app, not a library. IP Webcam on Android has served RTSP and MJPEG for over a decade and go2rtc has a documented source type for it. DroidCam and similar apps do the same for a desk. Both take 5 minutes and cost nothing or a few dollars for the paid tier. A used PoE camera with proper RTSP costs 30 to 60 dollars and has no battery to swell.

CameraView earns its place when you are building the app: a custom kiosk camera, a self-hosted photo booth, a barcode scanner that posts to your own inventory server, a wildlife trap that uploads to your Nextcloud on a motion trigger. In those projects the frame processor and the capture modes save real time, and the streaming gap does not matter because you are uploading files or events, not serving live video.

How it pairs with the rest of a stack

The pattern I have seen work: CameraView captures a snapshot or a short clip on some trigger, the app POSTs it to a self-hosted endpoint (a small Go or Python service, an n8n webhook, a WebDAV folder), and the server side does the storage and notification. The phone stays dumb. Motion detection can be done on-device with a cheap frame difference in the frame processor, keeping uploads to the interesting seconds. For anything that needs real-time viewing, put a go2rtc in the middle and let it do the protocol work; CameraView never has to know RTSP exists.

What I'd do

If I wanted a phone as a security camera, I would install IP Webcam, add it to go2rtc, and be done in the time it takes to read this. If I were writing an Android app that needed the camera for a self-hosted project, I would evaluate CameraX first because it is the library Google maintains, and reach for CameraView when I specifically wanted its gesture handling, filter pipeline, and simpler API and could accept a slower-moving dependency. I would not build a streaming camera app on top of it without a separate RTSP library already picked out, and I would not expect it to carry an MIT-licensed project past the point where the maintainer's time runs out.