The failure covers four stages of one flow
A licence acquisition failure is reported by the player after a session manager tried to obtain keys for a protected track. The message marks the end of a chain rather than a single fault. A DrmSessionManager decides that a track needs a session and creates one. The session obtains a key request from the platform DRM API. A MediaDrmCallback posts those bytes to the licence server and returns the response. The session installs the returned keys and reports success, or it raises a DrmSessionException that the player turns into the error you read.
Because one message covers all of that, the first move is to establish which stage stopped. The log line, the network capture and the manifest each hold part of the answer, and none of them is enough on its own.
Separate the stage before changing code
Each stage fails with evidence that distinguishes it from the others, and the common fix follows from the stage.
- The key request was never produced. A device without a usable device certificate cannot build a request the licence server will accept, and the platform reports a provisioning error instead of a network error. Provisioning happens once at device level, and a reset or altered device may not have completed it.
- The request was produced and never left the device. A connection error, a timeout or a refused handshake means the licence host was unreachable on that network. The capture shows an attempt with no response, which rules out both the server decision and the key material.
- The server answered and refused. A non-success status points at the licence server. The body often carries a reason the server defines, and the common causes are a playback credential that expired between the entitlement call and the licence call, or identifiers in the request that do not match what the account may watch.
- The server answered and the session rejected the licence. The response arrived, so transport and authorisation both worked. A rejection here points at a response the session cannot parse, a key that does not match the identifiers in the manifest, or a response format the player did not expect.
- Keys arrived and the track still cannot use them. A session shared across tracks or opened before entitlement finished can hold keys that no longer match the selected track. The failure appears after a successful licence call, which is why its timing separates it from the cases above.
Read the error category, then the detail
The platform DRM API reports failures through typed exceptions and error codes. The category carries the useful information: a provisioning code sends you to the certificate state of the device, a media or licence code sends you to the server response, and a session code sends you to the order in which sessions were created. Chasing an exact integer before the category wastes time, because two codes in the same category usually share one fix. The player error also carries the exception that caused it, and that exception names the layer which refused rather than the player that reported the failure.
Walk backwards from the refusal
Start at the licence call and move back towards the account.
- Check whether the licence request appears in the capture at all. Its absence moves the problem upstream to the entitlement call.
- Read the request. Confirm the method, the content type, whether the body is binary, and which app-level headers were attached.
- Read the response status and any body the server returned. A refusal with a body is more informative than a bare status.
- Find the entitlement call that produced the licence URL and the playback credential, then check what it returned and when.
- Compare the content identifiers in the manifest with the identifiers the key request names.
Fixes that match each cause
- Provision the device, or use a device that already holds a usable certificate.
- Point the media item at the licence URI that the backend returned for that title rather than a value stored in the app.
- Refresh the playback credential before the session opens, and open the session only after entitlement succeeds.
- Attach the headers the licence server expects. Many servers accept only the content type the player was configured with.
- Create one session manager for the item that is playing, and release sessions when playback stops.
A failure that survives those checks usually means the app and the device disagree about the licence format rather than about authorisation. Reproducing the format becomes a code problem, and the capture supplies the bytes to compare.
When the goal is a client rather than a fix
An app that plays protected content often has to be driven by a backend without its player. The reproducible half of that work is the application layer: entitlement, playback material, and the headers and credentials attached to the licence call. The platform component still performs the cryptographic half on the device. Android DRM reverse engineering covers that reconstruction, and the licence exchange itself is described in Widevine licence requests in Android apps.
Related work
Reviewed 28 September 2026 · SReverse research desk