Most Android camera apps quietly stop recording the moment you lock the phone. That is not a bug in the app. It is the operating system doing exactly what it was designed to do. I build an Android app whose entire reason to exist is screen-off recording, so I have spent a lot of time losing this fight before winning it. This is the mechanism, not a pitch. First thing to understand: recording video is easy. "Screen off" is the hard part. With your app visible and a preview on screen, the camera hands you frames, you route them to an encoder, you write an MP4. Solved problem. The difficulty appears the instant the display goes dark, because two OS subsystems change behavior at once. One: background execution limits. Since Android 8, an app that is not visible is a background app. Its services get killed, its network restricted, its wakeups batched. A plain Service started from a backgrounded app is a candidate for termination within minutes. Two: Doze. With the device stationary and the screen off, Doze progressively defers background CPU, network and alarms. Great for battery. Catastrophic for something that is supposed to keep working while nothing appears to be happening. So the real question was never "how do I record video." It is "how do I convince the OS that this dark-screen phone is doing legitimate, user-visible work it must not interrupt." The answer is a foreground service, and getting that right in 2026 is more involved than it used to be. A foreground service is Android's way of saying "the user knows this is happening, keep it alive." The persistent notification you cannot swipe away is not decoration. It is the price of admission. In exchange for showing it, the system dramatically lowers the priority with which it will kill your process. Order matters more than people expect. You start the service, and within a few seconds you must call startForeground() with a notification. Miss that window and the system throws ForegroundServiceDidNotStartInTimeException and kills you. Get the notification up BEFORE you touch the camera. Then there is the Android 14 rule that breaks older apps being ported forward: every foreground service must declare a type. For a camera app that is foregroundServiceType="camera", plus the FOREGROUND_SERVICE_CAMERA permission in the manifest. Call startForeground() for a service whose type you never declared and you get MissingForegroundServiceTypeException. No graceful degradation. Declare it or crash. The camera type is specifically what lets that service keep accessing the camera while running in the background. Without it, the moment your app stops being visible, camera access is on borrowed time. Now the part most people get wrong. Camera2 does not require a preview surface. Everyone assumes the camera needs something on screen to render into. It does not. Camera2 delivers frames to whatever output Surfaces you hand the capture session, and those surfaces do not have to be attached to any visible view. So a screen-off session looks like this. Open the camera and hold the CameraDevice. Create your output target: a MediaRecorder surface for the MP4, or a MediaCodec/ImageReader surface for frames you will stream. Neither is a SurfaceView or TextureView. Neither needs the display. Then set a repeating TEMPLATE_RECORD request against those surfaces. Because there is no TextureView anywhere in the pipeline, the screen can go dark and the session keeps producing frames into your encoder. From the camera's perspective the display being off is irrelevant. You were never drawing to it. That decoupling is the whole trick. "Screen off" and "recording" were never actually in tension. The tension was always with the process lifecycle, and the foreground service is what solves that. Two honest caveats. The camera is a single-consumer resource. If another app, or your own preview Activity being destroyed, tears down a surface mid-session, you get a CameraAccessException or a silent stall. Surface teardown has to be a deliberate state machine, not a pile of independent callbacks. And continuous encode is genuinely warm work. A phone doing this on a windowsill wants to be on a charger. Not because the software is inefficient, but because sustained H.264/HEVC encoding plus sensor draw is a real power load. That is hardware, not a bug to optimize away. One last property, because it falls out of the architecture for free. Because the pipeline writes to a local MediaRecorder surface by default, the footage lives on the device rather than in a vendor cloud. "Record with the screen off" and "your video never leaves your phone" turn out to be the same design decision viewed from two angles. The camera was never the hard part. The OS was. Full version with code examples: dev.to/superfunicular/how-an… Try the app: play.google.com/store/apps/d…

14,500 Dahua cameras compromised. The number that matters is 283 - the ones reached with no IP address at all. Just a serial number, through the vendor's own P2P relay.

Pin the camera phone’s address on the router, every guide says. Android’s doc on the randomised MAC: it "remains the same until a factory reset" and "doesn’t get re-randomized if you forget and re-add the Wi-Fi network." The reset breaks the pin, not the rejoin.

Deny notifications to a camera app on a current Android and its recording service still runs. What stops is the entry in the shade, the place people are told to check for proof it is recording. Android keeps that notice in the active-apps list.

A spare phone is not an idle phone. It is what you hand somebody the day theirs goes in a sink or gets taken. Mounting one as a camera spends that, quietly, for as long as the job lasts. The cost is not the phone. It is not having a phone to give.