10

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

Specifically, the sample app calls a closeCamera() method from onPause() of a fragment, where closeCamera() calls close() on the CameraCaptureSession, then close() on the CameraDevice, then close() on the ImageReader (used for actual picture-taking). After the close() on CameraDevice is when a few occurrences of the aforementioned BufferQueue has been abandoned message appears in LogCat, though I only get the message on some Android 5.1 hardware (Nexus 4 and Nexus 7 2013) and not others (Nexus 5 and Nexus 6).

fadden's comment on this was:

If the consumer side is shut down before entering onPause(), the messages would be expected.

When will TextureView's "consumer side" will be shut down, and why then?

Google's sample code does not proactively do anything to shut down the TextureView that I can see. And, since the TextureView could still be visible when paused, I would have expected that the "consumer side" would not be affected at the time of onPause(), but perhaps later in onStop().

While I realize that this message (despite being an error) is benign, I'm trying to figure out how to get rid of it, if for no other reason than to prevent my being asked time and again why code of mine is logging this error. I am hoping that by understanding more about this "consumer side", I can figure out how better to tidy things up when the user exits a Camera2-using activity or fragment and avoid this error.

Community
  • 1
  • 1
CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • could sub-classing TextureView and call close() onDetachFromWindow be an option ? – Blackbelt May 17 '15 at 10:30
  • 1
    @Blackbelt: Possibly. I wouldn't expect it to be called before `onPause()` of a fragment either. I'll give it a shot and see what the timing is. Thanks for the suggestion! – CommonsWare May 17 '15 at 10:41

2 Answers2

3

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!

Eddy Talvala
  • 17,243
  • 2
  • 42
  • 47
  • "Are you waiting for the camera's onClosed state callback method to be invoked, before exiting onPause?" -- um, no. I'm following the approach established by Camera2Basic, which does not have `onClosed()`. "Wait for CameraDevice.StateCallback#onClosed to be invoked before exiting onPause() after calling CameraDevice#close()." -- OK, I'll experiment with a `CountDownLatch` and post back tomorrow. Thanks! – CommonsWare May 19 '15 at 00:06
  • 1
    I can confirm that using a `CountDownLatch` to block in `onPause()` until `onClosed()` works. This isn't ideal, as we're blocking the main application thread, but if it is what's needed, c'est la vie. Technically, this answer doesn't answer the question ("When Is a TextureView's “Consumer Side” Closed?"), though it definitely addresses my underlying problem. So I'm going to take the rather unconventional approach of granting the bounty but not accepting the answer, as for somebody else, there may be value in other answers that pertain to the `TextureView` question. Regardless, many thanks! – CommonsWare May 19 '15 at 11:11
  • Yes, sorry that the sample is a bit incorrect here. Note that since N5/N6/N9/any non-LEGACY camera2 device block close until it's done anyway, you're not adding any real delay to those devices. – Eddy Talvala May 19 '15 at 20:09
1

As to the actual question - "when is a TextureView's 'Consumer side' closed", I don't know the exact timing, but it is certainly after onPause returns.

Roughly, TextureView contains a GL surface, and once the UI for the activity is no longer visible, those resources are torn down. Once that happens, the SurfaceTexture given out by the TextureView is no longer valid, and any existing users of that SurfaceTexture (or Surfaces made from it) will start receiving those errors. The method TextureView.SurfaceTextureListener.onSurfaceTextureDestroyed should be invoked by TextureView right before this happens.

So as an alternative, you may be able to return false from onSurfaceTextureDestroyed to avoid having it be released during UI teardown, and instead wait for onClosed to fire, and then in onClosed release the TextureView's SurfaceTexture yourself. However, I'm not quite familiar enough with the UI/View side of things to know for sure this'll work, and since some of the underlying native surfaces are released either way, you might still see the abandoned errors with this approach.

If you're curious, the top levels of the relevant code are in TextureView , especially the destroySurface method, though there's a lot you'd need to understand about the whole Android UI system to sort out when exactly the destroySurface method is invoked, and what its effects are.

Eddy Talvala
  • 17,243
  • 2
  • 42
  • 47
  • 1
    My statement quoted in the question was based on the assumption that the camera `close()` blocked. If it could still be sending frames after `onPause()` then the messages make sense -- the TextureView shuts down shortly after `onPause()` returns, releasing the SurfaceTexture, and every frame sent by the still-closing-down camera causes a log message. So the answer to the original question is, "exactly when you'd expect it to". Holding off on releasing the SurfaceTexture should work to avoid the (harmless) messages, but doesn't address the other issues you listed in the first answer. – fadden May 19 '15 at 23:12