cancel() now only sets a flag, so after release() the in-flight provisioning POST keeps running until it finishes or times out. During that time the worker thread keeps holding the bridge, because PostRequestTask is still a non-static inner class. The old cancel(true) at least interrupted the thread. To actually abort the request, save the HttpURLConnection in a volatile field and call disconnect() on it from cancel(). Also check mCancelled in run() before posting to the UI thread.

Keeping this as is: cancel(true) interrupted the thread, but an interrupt doesn't abort blocking HttpURLConnection I/O, so the old task also ran the POST to completion or timeout. The posted result checks mCancelled before touching the bridge.

We don't need a new thread that later creates a separate thread to resume tasks (resumePendingOperations).

Can we re-purpose our existing handler so that we can provision first (making sure that mHandler has a thread created first, before resumePendingOperations?

To clarify, my understanding is that the provisioning task is dependant on the pending operations task, so we can make them sequential on the same thread without creating a second one.

Provisioning now runs on mHandler's thread, and the pending operations follow it there. Because they share that thread now, resuming the pending sessions stops when one of them restarts provisioning, so the new provisioning request isn't stuck behind them.

There is a check-then-act race between this mCancelled check and release(). release() runs on another thread, the caller's binder thread via RemoteMediaDrmBridgeStub/MediaDrmProxy, not on PendingSessionOpsThread. If it runs after the check passes, onProvisionResponse() keeps going while the bridge is torn down:

• provideProvisionResponse() dereferences a null mDrm. That NPE is not caught, so it is an uncaught exception on the HandlerThread and crashes the process.
• resumePendingOperations() → getHandler() lazily creates a new HandlerThread after release() has already nulled and quit the old one. Nothing ever quits the new thread, so it leaks.

Fix by making delivery and teardown mutually exclusive. Either run release()'s teardown on the handler thread, or guard the mCancelled check plus onProvisionResponse() and the cancel/teardown in release() with the same lock. Also make getHandler() refuse to recreate the thread once released.

Worth doing, but adding it as a third patch on the stack rather than scope-creeping this one more.

There is a check-then-act race here. release() gets called on the binder thread (RemoteMediaDrmBridgeStub.release()), while this code runs on PendingSessionOpsThread. If release() runs after the mCancelled check but before or during onProvisionResponse(), two things can go wrong:

• provideProvisionResponse() dereferences a null mDrm. The resulting NPE is not caught and kills the thread.
• resumePendingOperations() calls getHandler() after release() has nulled mHandler. That lazily starts a new HandlerThread, which nothing ever quits.

The volatile flag doesn't give the "late response is ignored" guarantee. Make the cancel and the delivery atomic: for example, guard both release() and this check-and-deliver block with the same lock, or recheck mDrm/cancellation under that lock inside onProvisionResponse(). Also make getHandler() refuse to recreate the thread after release.

Same reply as the last time you brought this up.