Short answer: On Android, a front-camera preview is mirrored and the video file written from that same camera is not. That is not a bug and it is not one setting misapplied. They are two separate settings with two different defaults, and Google's own CameraX guide says so in as many words. Until this month only one of the two had a public switch; a CameraX release dated August 12, 2026 gave the other one a setter and dropped the experimental marker from both. If you have ever put a phone somewhere, watched the live view, and later described the saved clip to somebody from memory, this is the difference between left of the door and right of the door.
The convention nobody states out loud
When you look at a mirror you see yourself reversed, and you have seen yourself that way every morning of your life. A camera pointed at your face does not do that. It shows you what everyone else sees, which — the first time you notice it — looks subtly wrong.
So phone makers flip the front-camera preview horizontally on its way to the screen. The picture behaves like a bathroom mirror because that is what a person holding a phone at arm's length expects. Nothing about the sensor changed. Nothing about the pixels leaving the camera changed. The flip belongs to the display path, not to the footage: it is applied late, to one copy, for the benefit of one viewer.
That works perfectly for the case it was designed for: one person, holding the phone, looking at their own face, comparing it to nothing.
It stops working the moment a phone stops being something you hold and becomes something you put down and leave. Now the same camera has two audiences — whoever is watching the live view, and whoever opens the file afterwards — and those two people are not looking at the same picture.
What Android actually does, in Google's words
The CameraX video-capture guide states the default behaviour directly:
"While the camera preview is mirrored on the front camera by default, videos recorded by VideoCapture are not mirrored by default."
Read that twice, because there are two independent claims in one sentence:
- The preview is mirrored. On the front camera. By default.
- The recording is not mirrored. By default.
The default is that they disagree. Not on some devices, not under some conditions — by design, as the documented starting state. The same page continues:
"With CameraX 1.3, it's now possible to mirror video recordings so that the front camera preview and the recorded video match."
Which is worth reading for what it concedes. The ability to make the two halves agree is described as an addition. Before it, the disagreement was not something an app author could resolve at all through that library.
The date the switch stopped being experimental
CameraX release notes carry a dated heading for every version, and this is the row that matters. Under Version 1.7.0-alpha03, dated August 12, 2026:
"Added
Preview.setMirrorMode,Preview.getMirrorModeandVideoCapture.setMirrorModeto public APIs, and removed theExperimentalMirrorModeannotation."
Two separate things are packed into that line.
First, Preview got a mirror setter of its own. Before it, the guide's story is one-sided: you could change what the recording does, and the preview did what it did. Now both ends of the pair are addressable, which is the only way to guarantee they agree rather than hoping the defaults line up.
Second, ExperimentalMirrorMode is gone. An experimental annotation in a Jetpack library is a warning that the shape may change and a compiler opt-in you have to write out. Removing it is the library saying this is now something you may depend on.
A note on reading pages like this one, because it takes a second and saves a wrong claim: the footer of a Google documentation page carries a last updated date for the page, and that is a fact about the publishing system, not a date attached to anything written on the page. The video-capture guide quoted above is stamped 2025-12-10 while describing behaviour that is entirely current. The release-notes page has dated headings per version, and those are the dates of the actual events. Quote the dated row, never the footer.
Three constants, and why the middle one is almost never right
The same guide lays out the options:
"There are three MirrorMode options: MIRROR_MODE_OFF, MIRROR_MODE_ON, and MIRROR_MODE_ON_FRONT_ONLY."
- Off — never flip. The file matches the sensor. It will not match a mirrored preview.
- On — always flip, including the rear camera. A rear camera has no mirror convention to satisfy, because nobody is looking at their own face through it, so flipping it produces a file in which every sign in the picture reads backwards for no reason at all.
- On-front-only — flip when it is the front camera, leave the rear one alone.
Google recommends the third one to line up with the preview, and describes it plainly:
"mirroring is not enabled for the rear camera, but is enabled for the front camera"
One small trap if you paste from that page: in the sentence carrying the recommendation, the guide misspells the constant as MIROR_MODE_ON_FRONT_ONLY, dropping a letter from MIRROR. The correct spelling appears in the sentence immediately before it, and again in the code sample below it. If your compiler tells you the symbol does not exist, it is right and the prose is wrong.
Why a phone you put down makes this worse than a selfie does
Handheld, the mismatch is invisible. You look at yourself, you record, you never place the two side by side, and if you did you would have no external reference to say which one was correct.
A phone that has been set up somewhere and left there breaks all three of those conditions:
- Somebody describes the picture to somebody else. The bag was on the left of the step. Left in which of the two pictures?
- There is text in the frame. A door number, a delivery label, a note taped to a window, a whiteboard, a page held up to the lens. Text is the one thing that makes a horizontal flip instantly, unmissably obvious — and it will be obvious in exactly one of your two pictures.
- The live view and the file get compared. Not out of curiosity, but because somebody watched something happen and then went looking for it afterwards. That is the entire reason a recording exists.
And there is a prior question that no documentation can answer for you: which camera is even doing the work. A phone propped in a stand with its screen facing you is watching the room with its rear camera, and none of this applies. A phone with its screen facing the room is using the front camera, and all of it does. That depends on which way round you set the phone down. It is not a thing you can look up. It is a thing you check.
The two-minute check, no compiler required
You do not need to build anything to answer this for your own setup. You need a sheet of paper.
-
Write a word on the paper. Pick one that is not a palindrome —
CAMERAworks,MOMdoes not. Block capitals, thick pen. - Put the phone exactly where you intend to leave it, facing the way you intend it to face. Not on your desk pointed at you. The answer depends on which camera ends up doing the work, so the test has to use the real arrangement.
- Hold the paper up in front of the lens and look at the live view. Is the word readable, or reversed?
- Record a few seconds. Stop.
- Open the saved file and find those same frames. Is the word readable now?
There are four possible outcomes and each one tells you something you can act on:
| Live view | Saved file | What you have |
|---|---|---|
| readable | readable | The two agree. Nothing to do. |
| reversed | reversed | The two agree. Also fine — they are consistent with each other. |
| readable | reversed | The documented front-camera default: preview mirrored, file not. |
| reversed | readable | The inverse. Rarer, and worth knowing before you rely on it. |
Rows three and four are the ones to write down somewhere, because they mean the picture you watch and the picture you keep are mirror images of each other, and the only person who will be caught out by that is whoever has to describe one of them out loud.
If you are the one building it
The guide's own snippet sets the policy on the recording side:
val recorder = Recorder.Builder().build()
val videoCapture = VideoCapture.Builder(recorder)
.setMirrorMode(MIRROR_MODE_ON_FRONT_ONLY)
.build()
And as of the August release, Preview carries setMirrorMode and getMirrorMode as public API, so the other half is addressable too. Set both explicitly. Two defaults chosen independently by two different classes is a coin flip you are not obliged to accept, and getMirrorMode means you can assert on it in a test rather than squint at a screen.
If you are using somebody else's camera app rather than writing one, none of those calls are available to you, and the paper test above is the whole of your instrumentation. That is not a small thing — it is a two-minute answer to a question that otherwise surfaces at the worst possible time.
The edges of what these two pages will support
Stating an unknown plainly is worth more than filling it with a guess, so here is where the sources stop:
- Whether any particular app exposes this. A library setting is not a user setting. Whether a given camera app surfaces a mirror control, or which default it picked, is not knowable from Google's documentation and is not something to assume in either direction.
- What a phone maker's own camera app does. CameraX is one library among several ways to talk to a camera. An OEM app may take an entirely different path and land somewhere else.
-
Still photographs. The passage quoted here is about
VideoCapture. It does not describe what happens to a photo, and this piece does not extend it there. - Which handsets have which behaviour. A library version is chosen by the app that bundles it, not by the phone, so there is no device list to consult.
There is a companion piece to this one about a different gap between what setup guides tell you to do and what actually happens: only one of the two permissions every guide tells you to grant is about the camera.
The one-line version
Mirroring happens on the way to a screen, and Android decides it twice — once for the preview, once for the file — with two different defaults, and for several years an app author could only overrule one of them. Since August 12, 2026 both halves have a public setter. And if you are not the one writing the app, a sheet of paper and two minutes will still tell you which of your two pictures is the flipped one.
Sources: CameraX video capturing architecture and the CameraX release notes, both on developer.android.com. Quotations are verbatim; the dated claim comes from the version heading, not the page footer.
Written while building Background Camera RemoteStream, an Android app for running a phone as a screen-off camera on your own network. More at superfunicular.com.
Top comments (0)