android - When Is a TextureView's "Consumer Side" Closed? -

one of official google samples camera2 api suffers the same bufferqueue has been abandoned problem seen in:

• what can when bufferqueue has been abandoned?
• android logcat shows bufferqueueprocedure

specifically, sample app calls closecamera() method onpause() of fragment, closecamera() calls close() on cameracapturesession, close() on cameradevice, close() on imagereader (used actual picture-taking). after close() on cameradevice when few occurrences of aforementioned bufferqueue has been abandoned message appears in logcat, though message on android 5.1 hardware (nexus 4 , nexus 7 2013) , not others (nexus 5 , nexus 6).

fadden's comment on was:

if consumer side shut down before entering onpause(), messages expected.

when textureview's "consumer side" shut down, , why then?

google's sample code not proactively shut down textureview can see. and, since textureview still visible when paused, have expected "consumer side" not affected @ time of onpause(), perhaps later in onstop().

while realize message (despite being error) benign, i'm trying figure out how rid of it, if no other reason prevent being asked time , again why code of mine logging error. hoping understanding more "consumer side", can figure out how better tidy things when user exits camera2-using activity or fragment , avoid error.

are waiting camera's onclosed state callback method invoked, before exiting onpause?

until callback fires, camera may still have pending work do, , definition of close() finish pending capture requests before shutting down device. can sped calling abortcapture() before calling close().

some devices (like n5 , n6) block close() call when returns, pending work done, implementation detail think our sample inadvertently relies on today.

however, want allow apps call close() , leave onpause() immediately, avoid hanging ui thread on waiting camera hardware shut down. isn't yet reality today.

in other words, close() supposed asynchronous, , isn't on devices. we'd possible fire , forget it, these error messages need addressed on camera device's side (not spam log when repeating request target goes away mid-operation).

the other reason calling close() , exiting onpause() isn't recommended today prevent other apps opening camera in onresume() calls, cause spurious errors when switching between camera apps.

so summarize:

for now: wait cameradevice.statecallback#onclosed invoked before exiting onpause() after calling cameradevice#close().

at future point: safe call close() , exit onpause; framework allow next app connect , not spam log. sorry isn't state today!