Camera sensor not showing in Android Camera2: HAL and driver basics

A high-resolution camera module that runs on its own Linux image can still be completely absent from an Android build: the boot completes, the camera service runs, and every Camera2 application reports zero cameras. The cause is rarely wiring, power or the sensor itself. Android lists a camera only if the build ships a Camera HAL driver for that exact sensor or bridge chip, and most modules are sold with kernel drivers for one Linux platform alone. Below you get the layer-by-layer explanation, a two-boot test that shows where your camera is failing, the pre-purchase checks that settle Android support, and the pixel-budget math that tells you whether the high-resolution sensor is worth the porting effort at all.

Why does a camera that works on Linux stay invisible to Camera2?

Because Android never talks to a camera device node directly: every application camera request goes through the Camera2 framework and then through the Camera HAL, a board-specific driver layer that must be built into your Android image for that exact sensor or bridge chip.

The two boots share the kernel, not the userspace. On the module's own Linux image, the sensor's kernel driver binds, a video node appears under /dev, and a capture tool streams frames — that is all Linux needs. Android adds the camera service and the Camera HAL above the same kernel, and only the HAL publishes cameras: it enumerates the hardware it was written for, creates the camera IDs the framework can list, and answers the capability queries every Camera2 application issues first. With no HAL entry for your sensor or its USB bridge, that enumeration returns an empty list, and no amount of resolution, exposure or cable swapping changes that outcome.

The Android platform documentation draws the line plainly: the camera HAL connects the higher-level camera framework APIs in Camera 2 to the underlying camera driver and hardware. The deciding question is therefore narrow: does a Camera HAL exist for this chip on this build? Not whether the sensor works somewhere else.

What does the camera HAL actually do between Camera2 and the sensor?

The HAL is the only layer that publishes a camera to the framework: it enumerates the sensor, advertises the resolutions and formats it can stream, converts Camera2 requests into sensor and image-processing settings, and hands filled buffers back up.

Applications never see the chip; they see what a shipped HAL declares. That is why two boards with the same sensor can behave differently, and why a Linux driver package proves nothing about an Android image. The stack, from the bottom up:

Current builds talk HAL3, the interface generation that carries camera API version 2, and a V4L2-based HAL written for that pair is what a port maintainer compiles against. A kernel driver is necessary but not sufficient: it is the floor of the stack, and the HAL is the floor of what Camera2 can see. Most of the Camera2 contract — formats, sizes, controls — is declared by that middle layer rather than by the hardware, which is why the HAL's capability list is the first thing to read on a port.

How do you check Android support for a camera module before you buy it?

Ask one question before the price sheet: does the maker, or the maintainer of your Android port, ship a Camera HAL for this sensor or bridge on this board — and get the answer against a build version, not a general yes.

Run the checks in this order, before any money moves:

1. Read the support list for the exact model, not the family. A module advertised for one board's Linux image supports exactly that. If Android is absent from the list, treat it as absent until the right person states otherwise.
2. Ask the build maintainer. Whoever assembles your Android image decides which HALs ship in it. The usable question reads: does build X at API level Y include a Camera HAL for sensor Z on this board?
3. Confirm the kernel side separately. A CSI module needs its kernel driver and board description attached for your board, and the host must accept the sensor's mode list — a separate failure with its own fix, covered in MIPI CSI camera resolution limits: verify the host.
4. Get the answer in writing, with a version attached. 'Should work' and 'we ship no driver' look identical until the module is on your desk; the second is a plan, the first is a hope.

Connector, power and protocol checks belong to the same pre-purchase pass; the camera module interface compatibility: what to verify guide covers the non-OS side.

Can a USB camera work on Android without a sensor-specific HAL?

Sometimes yes: Android builds can include an external-camera HAL that exposes standard USB video class (UVC) devices through the normal Camera2 interfaces, so a compliant webcam-class camera can appear with no module-specific driver at all.

The exception is a build feature, not a right. Whether the external HAL is enabled, how many external cameras it exposes and which modes it allows are set in the build's device configuration — the same maintainer question as before, then a bench test with the real module on the real board. Mode ceilings are common, and a UVC camera can be held to a subset of its modes by the build, much as USB camera stuck at 4K: how sensor resolution modes work explains from the mode-listing side.

Two traps catch high-resolution modules here. Many never speak UVC: they use a vendor protocol over bulk USB with a library on top, and the external HAL has nothing to bind to. Others are UVC-compliant while the build caps them below the resolution you chose them for. If the pixels you bought do not survive both traps, this path closes.

For teams with Android build experience there is a third road: the ecosystem carries V4L2-based Camera HAL implementations, and minimal ones serve a single camera at camera API version 2. Treat them as porting starting points, not drop-in drivers. The work is build integration measured in weeks, and it pays for itself across a fleet of identical machines, not on a one-off bench.

What are your options when the maker ships no Android driver at all?

You have three options when no Android driver exists: run the module on the OS it was written for, switch to a camera family your build already supports, or commission a HAL port — for a single machine, the first or second is almost always the more economical call.

Run the module on the OS it was written for. Keep the sensor, change the computer: an embedded Linux controller drives it with the drivers that already exist. When the camera sits away from the electronics, the same decision points at a standard GigE area scan camera on that controller; when it must be small, the board-level cameras category is the build-in shape:

Both connect over GigE, so cable runs follow Ethernet practice and the streaming goes through the vendor SDK. Board level camera selection for embedded vision machines walks the full selection pass.

Switch to hardware the build already supports. When Android is fixed — an existing application, a locked procurement — pick the camera from the build's side: a UVC device the external HAL serves, or a module the maintainer lists. Then re-run the pixel budget below against that ceiling before committing, because the resolution you give up is the real cost of this option.

Commission the port. Kernel driver, board description, HAL, build integration: a specialist project measured in weeks. Contract it against a demo image on your board, not against effort, and only when the fleet of identical machines is big enough to carry it.

For one machine, the first option usually wins on cost and the second on schedule; the port wins only at fleet scale.

How much of that 64 MP do you actually need?

Work it backwards from the feature: three pixels across a 0.05 mm feature in a 60 mm field of view needs about 3,600 px across — comfortably inside a 4,000 px wide 12 MP sensor, while a 64 MP part carries roughly 2.3× that pixel count per axis.

Worked example: inspect a 60 mm wide field, smallest feature to detect 0.05 mm, machine-vision rule of three pixels across the feature.

A 4,000 px sensor carries 4,000 / 3,600 ≈ 1.11× the requirement, an 11 % margin. Linear resolution grows with the square root of the pixel count: √(64 / 12) = √5.33 ≈ 2.31, so a 64 MP part holds about 2.31 × 4,000 ≈ 9,200 px across if it keeps the same 4:3 shape — an estimate from that ratio, since sensor shapes vary. Tighten the feature to 0.02 mm and the same field needs 60 / (0.02 / 3) ≈ 9,000 px: 12 MP fails, and the 64 MP estimate covers it with about 3 % margin. That thin margin, plus a lens that must resolve the finer pixel pitch — the check in Nyquist limit and camera resolution: match sensor to lens — is the honest cost of the big sensor.

The order of operations stays fixed: settle the driver question first, because the pixel budget exists only on a host that can publish the camera.

When does a missing camera have a cause other than the HAL?

Check the simple causes first, because three imitate a missing HAL: a cable or port that fails power negotiation, missing USB host permissions, and a kernel driver that never attached because the board description was absent — each fixable in minutes once you know which layer failed.

The test that splits the stack takes two boots. Boot the same board on the module's own Linux image first: if the video node appears and a capture tool streams frames, sensor, cable and kernel driver are proven, and the Linux camera device permissions: video and media node checks guide lists what to look for. Then boot Android on the same hardware. A kernel node present while the camera service reports an empty list means the gap is the HAL, and no settings screen closes it. A node missing under Android as well means the kernel side needs work first, starting with camera loads the wrong sensor driver: read dmesg, fix the overlay. For USB devices, host permissions remain the most common false alarm: depth camera not detected on Android: check USB host permissions.

Which checks do you run before you order the module?

Four checks settle the purchase: a HAL named for your sensor on your build, kernel support proven for your board, a pixel budget computed against the supported ceiling, and a fallback host that runs the module today.

Work down the list in this order — each line depends on the one above it:

• HAL confirmed for your sensor or bridge, on your build, version named. This layer publishes cameras; without it nothing else matters.
• Kernel side proven for your board. Driver attached, board description in place, mode list accepted by the host.
• Pixel budget computed against that ceiling. Field, smallest feature, three pixels across, lens matched to the pixel pitch.
• A host that runs the module today. If the Android answer is no, the Linux controller enters the purchase order now, not after delivery.

Compressed to one sentence: no Camera HAL for your sensor on your build means no camera in Camera2, at any resolution, on any image that does not add one. Settle it with one written answer, spend on pixels second, and treat camera and controller as one decision. If the support answer stays ambiguous, send the sensor, bridge, board and build details through the contact page, or shortlist by interface and resolution in the camera finder. The systems topic page gathers the related guides on hosts, drivers and bandwidth.