Short answer: In July we wrote that night mode doesn't come with you into video, and that the notable exception — Pixel Night Sight Video — works by uploading your footage to Google's servers. We also flagged that Google was moving the technique on-device, then dismissed it as one unreleased flagship line. That dismissal was the mistake. Google documents two real-time low light boost options that brighten a live stream on the device: a hardware auto-exposure mode from Android 15, and a Google Play services library listing Pixel 6 through Pixel 9 among its supported devices. Neither is a drop-in for a screen-off recorder — one for a reason we can prove, one for a reason we can only flag — and this post covers both, including for our own app.
What we published in July
Our overnight guide, Can an Old Android Phone See in the Dark?, argued that night mode is a still-photo technique — it merges a burst of frames, spending a second or two to produce one of them, and video needs thirty a second while things move. We still think that's right. Then this:
The exceptions prove the point. Google's Night Sight Video on the Pixel 8 Pro and Pixel 9 series works via Video Boost — which uploads your footage to Google's servers and replaces the local file with the processed version hours later. It requires Google Photos and cloud backup to function at all. (Google has been moving this on-device for the Pixel 11's Ultra Low Light mode, which won't need a connection — but that's one flagship line, not "phones.")
Still accurate about Video Boost. But notice the parenthetical: we had already spotted that on-device real-time processing was coming. What we got wrong was its size — not one unreleased flagship line, but a shipped platform AE mode plus a Play services library covering handsets back to 2021, documented for months before we hit publish. We had the direction and missed the scope.
What we missed
Google's Android Developers blog published Brighten Your Real-Time Camera Feeds with Low Light Boost on 17 December 2025 — seven months before our guide:
Unlike Night Mode, which requires a hold-still capture duration, Low Light Boost works instantaneously on your live preview and video recordings.
The docs are organised the same way. Choose the best low light option sorts the space into stills and real-time, and puts low light boost squarely in the second half. So our burst-stacking explanation was a good answer to a question the platform had stopped treating as its sole route.
One qualifier that cuts against the correction, and belongs here rather than buried. Low Light Boost is not a quality feature. Google's framing is "Night Mode aims to improve final image quality, Low Light Boost is intended for usability and interactivity in dark environments", and the comparison guide says plainly that LLB "produces a lower-quality capture than night mode". So our July sentence — "The single best low-light video feature on Android in 2026 works by" sending it off the device — survives this. What does not survive is the idea that off-device is the only processing.
Path 1 — Low Light Boost AE Mode (hardware)
An auto-exposure mode: set CaptureRequest.CONTROL_AE_MODE to ON_LOW_LIGHT_BOOST_BRIGHTNESS_PRIORITY and the camera system takes over in the ISP directly.
Availability is narrow. The blog is blunt: the mode
is supported on devices running Android 15 and newer and requires the OEM to have implemented the support in HAL (currently available on Pixel 10 devices).
Android 15 is a floor, not a ticket: the OEM has to have built it.
The mechanism has a cost you will notice on a static mount. It brightens partly by lengthening exposure rather than cranking gain — Google's phrasing is "adjusts sensor and processing parameters, often including increasing exposure time" — and that is where the win comes from:
This can yield frames with a significantly improved signal-to-noise ratio (SNR) because the extended exposure time, rather than an increase in digital sensor gain (ISO), allows the sensor to capture more light information.
Cleaner frames, not just brighter noise. But the time comes from somewhere:
May result in a lower frame rate in very dark conditions as the sensor needs more time to capture light. The frame rate can drop to as low as 10 FPS in very low light conditions.
For a hallway camera that is often a fair trade. Where a moving subject has to stay legible, it is a real loss.
A caveat the AE-mode guide states and the blog doesn't. The Low Light Boost AE Mode guide documents the mode against the preview — "Low Light Boost AE Mode automatically adjusts the brightness of the Preview stream" — with recording described as recording off that stream. It also warns that "Low Light Boost is not compatible with all camera configurations. For example, high-speed recording doesn't support Low Light Boost AE Mode," which is why it says to read the result back. That preview detail applies to both paths, not just the software one.
Path 2 — Google Low Light Boost (software, and the one with the longer device list)
Google ships a separate, software-based Low Light Boost as an optional module through Google Play services. It needs no HAL support because it works on frames the hardware has already produced — the blog describes it as applying "post-processing to the camera stream." That processing is a learned model, HDRNet, and the blog says where it runs:
This deep learning model analyzes the image at a lower resolution to predict a compact set of parameters (a bilateral grid). This grid then guides the efficient, spatially-varying enhancement of the full-resolution image on the GPU.
On the GPU. On the phone. Then the devices:
Works on a broader range of devices (currently supports Samsung S22 Ultra, S23 Ultra, S24 Ultra, S25 Ultra, and Pixel 6 through Pixel 9) without requiring specific HAL support. Maintains the camera's frame rate as it's a post-processing effect.
Read that against Path 1. The hardware mode wants the newest phone you own; the software mode reaches back to the Pixel 6, a 2021 handset — the reverse of how this usually goes. Worth noting what the list is not, though: nine flagships. A mid-range phone from the same years is not on it, and mid-range is what most drawers contain.
It keeps the frame rate, because it works on frames the sensor already delivered. That is also the ceiling:
As a post-processing method, the quality is limited by the information present in the frames delivered by the sensor. It cannot recover details lost due to extreme darkness at the sensor level.
Two more limits. HDRNet is "trained to brighten and improve image quality in low-light conditions, with a focus on face visibility" — handy for a doorway, less so for a plate. And the concepts page carries a flat exclusion: "Google Low Light Boost does not currently work with HLG10."
Checking your own handset
Hardware first. For a Camera2 app, check whether CameraCharacteristics.CONTROL_AE_AVAILABLE_MODES contains ON_LOW_LIGHT_BOOST_BRIGHTNESS_PRIORITY, then, after requesting the mode, read CaptureResult.CONTROL_AE_MODE back to confirm your configuration didn't reject it. On CameraX the same question is one property:
val cameraInfo = cameraProvider.getCameraInfo(cameraSelector)
val isLlbSupported = cameraInfo.isLowLightBoostSupported
Then the software fallback, which is a Play services module and so must be checked for installation as well as support:
val llbClient = LowLightBoost.getClient(context)
val isSupported = llbClient.isCameraSupported(cameraId).await()
val isInstalled = llbClient.isModuleInstalled().await()
if (isSupported && !isInstalled) {
llbClient.installModule(installCallback).await()
}
Run both — the first per camera selector, the second per camera id — and you get a definite yes/no for that device rather than an inference from its model name.
One step that is easy to skip: requesting the mode does not mean it is running, because the system engages it only when the scene is actually dark. Google's sample watches the state rather than assuming it:
camera?.cameraInfo.lowLightBoostState.asFlow().collectLatest { state ->
updateMoonIcon(state == LowLightBoostState.ACTIVE)
}
(Google's sample as published, safe-call and hard dot included; you will want a real null guard.)
On Camera2 the same question is a capture-result field rather than a flow. The AE-mode guide names it: check CaptureResult.CONTROL_LOW_LIGHT_BOOST_STATE against CameraMetadata.CONTROL_LOW_LIGHT_BOOST_STATE_ACTIVE inside onCaptureCompleted. That is the one that matters for anything built like our recorder, which is a Camera2 session and never touches CameraX.
Why our recorder can't have this and a pinned shutter
Here is the part that costs us something. We published our approach in Camera2 API: Handling Orientation, Focus, and Exposure in Background. Two independent moves. First, we cap the exposure-time ceiling at 1/30s and let ISO ride to compensate — which means setting CONTROL_AE_MODE_OFF, because the cap does not hold with auto-exposure running. The reasoning was blur versus grain: "Grain you can see through. Blur you can't." Second, once a 60-second warmup shows the scene is static, we switch to CONTROL_AF_MODE_OFF and lock the lens at a hand-picked diopter. The session starts on CONTROL_AE_MODE_ON and moves off it, so this is a choice we make at runtime, not a wall.
But it is an exclusive choice. Low Light Boost AE Mode is a value of CONTROL_AE_MODE, and that field holds one value. Google states the consequence directly rather than leaving it to inference:
Low Light Boost is its own auto exposure setting, since other auto exposure settings aren't compatible with the preview brightening performed by Low Light Boost AE Mode.
So it is a real either/or. A pinned shutter buys predictable, comparable frames — every clip from the same mount exposed the same way, which is most of what makes overnight footage reviewable — at the price of grain. Low Light Boost buys a brighter picture and gives back the frame rate and the predictability. That is not obvious enough for us to have picked it for you.
A second question we have not resolved applies to both paths. Both are documented against the Preview stream, and our recorder by design has no preview surface at all — the session's only outputs are a MediaRecorder surface and an ImageReader surface, which is what lets it run for hours with the screen off.
For the AE mode this is genuinely undocumented: the guide says only that the mode "automatically adjusts the brightness of the Preview stream" in low light. For the software path the docs are more encouraging — that session is surface-in, surface-out: "you must give your display Surface to the LowLightBoostSession, and it gives you back a Surface that has the brightening applied", and for Camera2 apps "you can add the resulting Surface with CaptureRequest.Builder.addTarget()". Nothing there requires the surface to be on screen. But that is an argument, not a result. We have not tested it, and we would rather say so than guess.
What none of this fixes
The IR-cut filter bonded into a phone's camera stack does not move and cannot be switched off in software. Neither an AE mode nor a learned model changes that, and an external IR illuminator is still money spent lighting a room for a sensor deliberately blinded to that wavelength.
And the ranking has not shifted: the fix is a lamp, not an app. Light the sensor did not receive is not in the file to recover — which is what "It cannot recover details lost due to extreme darkness at the sensor level" means. A 9W bulb or a motion-triggered lamp still beats every software path in this article and costs less than the phone.
So the check to run is the opposite of what a model year suggests. The hardware path wants the newest phone in the house; the software module was built to reach back to a Pixel 6 — likelier to be the handset actually sitting on a shelf doing camera duty. Run both checks on the phone you mounted rather than the one you read about. And if the software path comes back yes, be clear about what is on offer: not a feature to switch on, but a predictable exposure traded for a brighter one.
FAQ
Does Low Light Boost send my video to Google?
Nothing in the pages linked above describes either path uploading anything, and both are described as running locally: the hardware mode works in the phone's ISP, and the software module's HDRNet does its work "on the GPU" at full frame rate, which is not a network round trip. That is a description of on-device processing, not a privacy audit — Google Low Light Boost is a closed-source Play services module. Video Boost is a different thing and does explicitly upload.
Will it work on my old phone?
Check rather than guess. The software path lists Pixel 6 through Pixel 9 and the Galaxy S22–S25 Ultra; the hardware path needs Android 15 plus OEM support and was Pixel 10 only as of Google's December 2025 post. Both lists are the vendor's and both will move.
Does Background Camera RemoteStream use it?
No. Our published design turns auto-exposure off so an exposure cap holds on a static mount, and Low Light Boost AE Mode is a competing value of the same field. We have not tested the Play services path against a previewless session.
Sources, all first-party and all re-read on 7 September 2026:
- Android Developers' Blog — Brighten Your Real-Time Camera Feeds with Low Light Boost, 17 December 2025
- Android Developers — Choose the best low light option
- Android Developers — Low Light Boost Auto Exposure Mode
- Android Developers — Understand Google Low Light Boost
Quotations are verbatim. Device lists and availability are Google's as published on those dates, and both will move.
Try it: Background Camera RemoteStream on Google Play — record with the screen off, keep footage on the device, watch it over your own network.
Top comments (0)