Short answer: Android hands an app a list of cameras, and on a phone with several pieces of glass on the back, what lands on that list is shaped by the manufacturer's implementation rather than by the count on the box. Google's Camera2 guide says most devices on Android 9 and higher expose the individual physical cameras, with a stated exception for less-common sensor types, alongside an easier one that stands in front of them, so its stated expectation is that the extra entries are reachable. It also documents what reaching them involves: a set of rules for the cases the framework promises, and per-device testing for anything past them. The companion page on enumerating cameras classifies entries first by which direction they point, and coverage is not among the properties it offers an app to read off an entry. The multi-camera guide is the one that treats focal length as comparable across a phone's physical cameras, which on my reading is the nearest thing to a coverage question either document answers.
Three circles on the back, and a list that need not have three entries
Pick up a phone with three circles on the back and the natural count is three. The framework's count can be different, and the multi-camera guide is explicit about why.
Its worked example is exactly that phone. For reference, it says, "consider a device with three back-facing cameras", and each of those three is a physical camera. Then the grouping arrives: "A logical camera is then a grouping of two or more of those physical cameras." The output of that logical camera can come from one of the physical ones underneath it, or from more than one of them fused together, and either way the stream is handled by the Hardware Abstraction Layer.
So a phone with three rear cameras can present an app with a logical camera plus its physical members, and the shape of that presentation belongs to the manufacturer. The enumeration guide is content to use the vocabulary loosely in the other direction, describing lenses where the API returns cameras, and noting that "Each lens can have unique capabilities, such as burst capture, manual control, or motion tracking."
What the enumeration page classifies, and what it does not
Having received the list, an app looks at each entry to work out what it is. The enumeration guide names the lens-facing and capabilities values from its sample. The lens-facing value is the headline one, and it takes one of three values: front, back, and external. The second is a capabilities value, which the page describes as reporting, among other things, "whether the camera is able to produce standard frames as an output" as opposed to depth data.
Direction and whether it produces ordinary frames. There is no field on that page reporting how much of a room an entry takes in, no wide or ultra-wide category, and no coverage figure. Its examples of why an app would care include an app for depositing checks that might use only the first rear-facing camera, a social media app that defaults to a front-facing one but gives users the option to switch between all available lenses and can remember what they chose, a selfie app, and an augmented-reality app. Those are questions about direction, though the social one is also about offering the user a choice among the lenses the device has.
The other page tells a different story, and it is worth saying so early because it cuts against the tidy version of this. The multi-camera guide lists "switching between cameras depending on crop region or desired focal length" among its typical use cases, and later has an app pick between physical cameras by focal length outright. So the guide has an app select on focal length, which is as close to a coverage figure as anything in these two documents gets, and treating that as the coverage answer is my reading rather than the guide's. The catch is where it lives: on the physical members of a multi-camera grouping, in the guide about using them, rather than on the page an app consults to work out what it has been handed.
Two further sentences from the enumeration guide describe the awkward part. First: "Many devices have multiple cameras that face the same direction." Second, on writing the switch-camera button that many camera apps offer: "Although there is no universal logic for selecting the next camera", after which it supplies a sample it says works for a large set of devices with many different configurations, plus a pointer for edge cases. So the page does give a sample it stands behind; what it declines to claim is a universal rule.
There is also a facing value that rarely comes up in a phone-shaped discussion. The third constant covers cameras outside the device, and that same enumeration page notes in passing: "Some even have external USB cameras."
Why the situation looks like this
The multi-camera guide includes a short history, and it explains the shape of the present arrangement better than a list of methods would.
Many manufacturers, it says, develop first-party camera applications that usually come pre-installed. To reach everything the hardware can do, "they may use private or hidden APIs or receive special treatment from the driver implementation that other applications do not have access to". Some devices produced the fused multi-lens stream for certain privileged applications and nobody else. The blunt summary of the era: "Often, only one of the physical cameras is exposed to the framework."
Then the platform closed the private route and opened a public one. Android 9 brought the multi-camera API, private APIs stopped being allowed in apps, and the guide records the resulting expectation in careful language: "Android best practices strongly recommend that phone manufacturers expose a logical camera for all physical cameras facing the same direction."
The outcome is described as broad: "In most cases, devices running Android 9 and higher expose all physical cameras (except possibly for less-common sensor types like infrared) along with an easier-to-use logical camera." Whether that counts as the recommendation being well kept is my inference and not the guide's; it reports what devices do without grading anyone's compliance.
It also states the residual, in a sentence worth keeping: "What the logical camera provides is entirely dependent on the OEM implementation of the Camera HAL." A device is free to have its logical camera pick among its physical ones by the requested crop and focal length, and the guide gives a named handset that does precisely that.
One more line, this time from the enumeration guide, makes the same point from the opposite side. For apps still on the deprecated camera API, the number of cameras reported depends on the manufacturer, and where a logical multi-camera exists, "this method will only expose one camera for every logical camera and underlying physical cameras group". The count an app sees is partly a function of which API it asked with.
What the extra entries are for, and what they cost
The multi-camera guide names the payoff. Merging physical cameras into a single stream lets users "switch between the different physical cameras to experience a different field-of-view", and for the strongest version of that effect, "you can choose the pair of cameras that provide the minimum and maximum focal length available". A different field of view from the same phone is exactly the thing somebody hoping to cover a whole room is after.
The mechanics are constrained. You open the logical camera as a single device and work inside a single capture session; the session configuration carries output configurations, and an output configuration may name a physical camera ID, and the framework then routes a request by the output target attached to it. Where two physical cameras belong to the same logical grouping, the framework will let you replace one logical stream of the right type with two streams from that pair.
Then the caveat, and it is narrower than it first sounds. Those replacements are described as the bare minimum needed to get frames from more than one physical camera at once. Going past that minimum is common on real devices but unpromised, and the guide says what the unpromised part costs: "Since it's not a hard guarantee from the framework, doing that requires performing per-device testing and tuning using trial and error." A related caution opens the page, where many multi-camera use cases are called tightly coupled to a specific hardware configuration, so that "not all use cases are compatible with every device".
There is a second cost, and it is optical rather than procedural. On the logical camera the guide describes distortion as minimal, so frames can be used roughly as they arrive. Go past it to the physical ones and that changes: "For physical cameras, there are potentially very different lens configurations, especially on wide lenses." The guide also names the instruments. Distortion is queryable per lens through CameraCharacteristics.LENS_DISTORTION, some devices implement automatic correction through CaptureRequest.DISTORTION_CORRECTION_MODE, and the guide says distortion correction defaults to being on for most devices. What it claims here is variability rather than a fixed penalty, and it is variability the handset in front of you can be asked about rather than guessed at.
What this means when a phone is being chosen for the job
Small and dull, which is the useful kind.
Count the circles on the back as hardware, not as options. The relationship between them and what any app can offer is a manufacturer decision that the platform documents as a strong recommendation, alongside a separate report that in most cases devices running Android 9 and higher expose all physical cameras, with a stated exception for less-common sensor types. Neither of those is the same kind of fact as the number of lenses.
Read the platform's default as a fallback rather than a verdict. The enumeration guide's own wording is conditional: "If you don't need a specific camera, select the first camera that faces the desired direction". Its broader posture is the opposite of settling for whatever turns up first, and it says so directly: "Don't assume that your app always runs on a handheld device with one or two cameras." Enumerate, then choose for the purpose.
Treat a coverage claim about a second entry as a per-model claim. The multi-camera guide supports the general mechanism, and the same guide carries the caution that the parts beyond that promised minimum are tested device by device. A demonstration on one handset has not thereby been made on another.
Remember the external option exists. The platform carries a lens-facing value for cameras outside the phone, the enumeration guide notes that some devices have external USB ones, and it suggests that when such a camera is connected the user probably prefers it as the default.
And read the enumeration guide against itself, because it does not want any of this turned into a shopping rule. Its advice for a switcher interface is to "choose the first available camera for each possible lens-facing configuration", which means surfacing one entry per direction rather than every rear entry a phone has. It also carries the sentence most directly aimed at the frame of this whole section: "Don't restrict your app's availability on certain devices based on camera hardware." A phone that offers less of a list is a phone an app is meant to work on anyway.
What these two pages do not settle
I did not test a single device for this, and nothing here should be read as a survey. How often a current phone withholds one of its rear cameras from third-party apps is exactly the question the multi-camera guide's phrase about most cases is standing in for, and I found no published measurement of it.
Neither page says what order the camera list itself arrives in, so I cannot tell you which entry a first-camera-facing-a-direction default lands on for any particular phone. The enumeration guide does recommend an order, but for a different list and a different purpose: building a switcher, where "The recommended order of iteration is: all external, first back, first front." That is guidance on presenting cameras to a user, not a statement about the order they are handed to an app. Beyond describing the sample as retrieving a list of all cameras, no prose sentence on either page says what comes back, and the sample code adds a comment that the list may be empty.
I also could not establish how the picture differs between the two supported APIs for this question. The multi-camera material is written for Camera2, while both pages open by recommending the higher-level library for anything that does not need low-level features, and what that library does with a logical camera's members is not covered by either page quoted here.
And nothing in the argument above describes any particular application. These are two platform documents about what the platform offers; what a given app does with the offer is a separate question, answerable only by looking at that app.
Choose an old phone for the circles on its back and you may be choosing glass that no third-party app on that handset can address. Nothing in either document promises otherwise, and the property both of them put first for telling entries apart is simply which way each one points.
We build Background Camera RemoteStream, an Android app that keeps recording with the screen off and serves the picture over your own network. More writing on this sort of thing at superfunicular.com.
Sources, both first-party:
- Android Developers, Multi-camera API
- Android Developers, Camera lenses and capabilities
Top comments (0)