Continuous focus on zone for image capture

[Quentin Hébert]

Hello,

Is there a way to have a continuous focus on a zone during an image capture sessions ?

In our app, we are able to determine the wanted focus zone through image analysis, and then to request a one time focus on this zone through [startFocusAndMetering()](https://developer.android.com/reference/androidx/camera/core/CameraControl#startFocusAndMetering(androidx.camera.core.FocusMeteringAction)).

We would like to have a continuous focus on this zone, and even ideally to be able to update this zone.

We tried to call `startFocusAndMetering()` each time the focus action finishes but we end up having either a laggy preview, or a constant "focus breathing" effect.

We are therefore wondering if it would be more efficient to use the camera continuous focus mode on a custom zone, since on the native camera app of a device, it is possible to tap on an object and then the object is tracked and stays in focus even when we move the camera, without the issue we encounter with `startFocusAndMetering()`.

Thanks in advance

[Wenhung Teng]

Thanks for reaching out.

In CameraX (and the underlying Camera2 API), this method is generally treated as an active trigger—it forces the camera to initiate a new AF scan to find the best focus right now, which causes the "breathing" effect as the lens hunts for focus repeatedly.

To achieve a "continuous focus on a zone" similar to native camera apps, you usually need a combination of your custom object tracking and strategic use of CameraX APIs.

Here are some recommendations:

1. For a Static Zone (preventing timeout) If the zone doesn't move much, ensure you call startFocusAndMetering only once, but disable the timeout. By default, CameraX resets focus to the center after 5 seconds.

```
val action = FocusMeteringAction.Builder(meteringPoint).disableAutoCancel().build() 

cameraControl.startFocusAndMetering(action)
```

Once this is set, the camera should use its own internal Continuous Auto-Focus (CAF) to keep that specific region sharp without further calls from your app.

2. For a Moving Zone (Object Tracking) CameraX does not currently have built-in high-level object tracking that automatically updates AF regions without triggering new scans. Native camera apps often utilize specialized vendor hardware or complex ML pipelines to achieve smooth tracking.

Since you already have image analysis determining the zone, you can implement tracking, but you must avoid calling startFocusAndMetering on every single frame.

• Implement a threshold: Only call startFocusAndMetering (with the new coordinates) if your tracked object has moved significantly (e.g., more than X% of the screen width). Small movements should be ignored to let the camera's internal CAF handle minor adjustments.

• Debounce calls: Ensure you don't trigger a new focus action while one is already in progress or explicitly recently finished.

Hopefully, this helps you find the right balance for your application.

[Quentin Hébert]

Thanks a lot for the recommendations.

Implementing a threshold on the object position changes is actually exactly what we ended up doing.

About disabling the timeout, it doesn't seem to use the continuous auto-focus like your described.
Instead, it makes one focus, and then the `ListenableFuture` returned by `startFocusAndMetering()` completes, and it totally stops focusing after that, until we re-trigger it manually.

Would there be any possibility to have the behavior that you described for the static zone ? It could allow us to use the continuous focus on the custom zone, and then to update it when it moves.

Thanks !

[Tahsin Masrur]

> Instead, it makes one focus, and then the `ListenableFuture` returned by `startFocusAndMetering()` completes, and it totally stops focusing after that, until we re-trigger it manually.
>
> Would there be any possibility to have the behavior that you described for the static zone ? It could allow us to use the continuous focus on the custom zone, and then to update it when it moves.

There's a high chance that's a bug, potentially device-specific. The behavior should be what Wenhung described in his earlier message. Could you please share more info about this?

Please share the code you are using (preferably a minimal reproducible code sample), the device model, and a log dump. It might be better to file a bug here to share info more easily and keep the issue actively tracked.