When Is a TextureView's “Consumer Side” Closed?

Question

One of the official Google samples for the Camera2 API suffers from the same BufferQueue has been abandoned problem as is seen in:

• What can I do when the BufferQue

Answer 1

Are you waiting for the camera's onClosed state callback method to be invoked, before exiting onPause?

Until that callback fires, the camera may still have pending work to do, and the definition of close() is to finish up all pending capture requests before shutting down the device. This can be sped up by calling abortCapture() before calling close().

Some devices (like the N5 and N6) currently block the close() call so that when it returns, all the pending work is done, but this is an implementation detail that I think our sample inadvertently relies on today.

However, we generally want to allow apps to call close() and leave onPause() immediately, to avoid hanging the UI thread on waiting for the camera hardware to shut down. But this isn't yet reality today.

In other words, close() is supposed to be asynchronous, and isn't on all devices. But we'd like it to be possible for you to fire and forget it, so these error messages need to be addressed on the camera device's side (not spam the log when the repeating request target goes away mid-operation).

The other reason just calling close() and exiting onPause() isn't recommended today is that it will prevent other apps from opening the camera in their onResume() calls, which will cause spurious errors when switching between camera apps.

So to summarize:

For now: Wait for CameraDevice.StateCallback#onClosed to be invoked before exiting onPause() after calling CameraDevice#close().

At some future point: Will be safe to just call close() and exit onPause; the framework will properly allow the next app to connect and not spam your log. Sorry this isn't the state today!