Chrome and Android Widevine Communication Architecture

The same opaque license loop crosses different process, HAL, TEE, decoder and output boundaries

Chrome desktop and Android Widevine communication paths Both clients relay opaque license messages through a partner proxy, while Chrome uses an out-of-process library CDM and Android uses MediaDrm, an AIDL DRM HAL, OEMCrypto and secure media hardware. SHARED SERVICE / DELIVERY PLANE CHROME DESKTOP LANE process placement is platform/version dependent; desktop library-CDM path shown ANDROID LANE framework API, mediadrmserver, binderized vendor HAL and optional L1 protected path CDM UTILITY PROCESS / CDM SANDBOX TEE / L1 PROTECTED MEDIA PATH MPD + CENC rights verified request + rules individualized license response device status / revocation fetch(opaque EME message) over HTTPS HTTP response -> MediaKeySession.update() app sends opaque KeyRequest over HTTPS response -> provideKeyResponse() EME calls Mojo message / keyschange / expiration callbacks encrypted samples CDM decryptor / key handle decoded frames API Binder AIDL opaque KeyRequest / events return through MediaDrm samples secure call buffer browser-managed provisioning / certificate state provision request / response CDN / Manifest MPD + PSSH + CENC segments public encrypted delivery Entitlement account / asset / device policy and risk decision Partner License Proxy only client-facing license endpoint validate request + append rules HTTPS transport belongs to app/player Widevine License Service verify / individualize / sign Cloud Service or hosted SDK Provisioning / Revocation device credential and client status separate from content license acquisition Web App / EME MediaKeySession generateRequest / update Renderer process MediaInterfaceProxy InterfaceFactory / routing Browser process broker process topology can vary CdmService / MojoCdm session IPC and callbacks CdmAdapter + Widevine CDM proprietary library CDM MSE / Demux PSSH + samples ChunkDemuxer Decryptor / Decoder CDM-backed decrypt path software or platform decoder GPU / OS Media Path decode / compose / display capability depends on platform Display App / Media3 DrmSessionManager HTTP callback app process MediaDrm API openSession get/provideKeyResponse opaque byte arrays mediadrmserver DrmHal + CryptoHal plugin discovery / IPC framework service boundary Widevine DRM HAL IDrmPlugin ICryptoPlugin vendor / SoC implementation Extractor / Player encrypted samples MediaCodec queues MediaCrypto / CryptoHal session-bound crypto context secure buffer descriptors OEMCrypto / TEE key use + decrypt state L1 non-exportable handles Secure Decoder protected surface codec / SoC dependent HWC / Display LEGEND app / media data service control DRM / security boundary request / control license response encrypted media / frames

Same License Loop

  • The app receives and transports an opaque request
  • The partner proxy applies entitlement before fulfillment
  • The opaque response returns to the originating DRM session

Different Isolation

  • Desktop Chrome routes library CDM calls through Mojo
  • Android crosses MediaDrm, Binder and an AIDL DRM HAL
  • Neither public app API promises an exportable content key

Different Media Paths

  • Chrome decode/output protection depends on host platform
  • Android L1 can keep decrypt and decode inside secure hardware
  • License success and secure output remain independent gates

Chrome and Android Widevine communication map - public Chromium, AOSP, EME and MediaDrm architecture - 2026-08-24