DRM，英文全稱為Digital Rights Management，譯為數字版權管理。它是目前業界使用非常廣泛的一種數字内容版權保護技術。随着知識産權保護受重視的程度日益提高，快速攻城略地得Android智能手機是如何利用DRM來有效保護數字版權的呢？本文将通過剖析Android中的DRM架構以及相關工作流程來向讀者揭示DRM的神秘面紗。
M，英文全稱為Digital Rights Management，譯為數字版權管理。它是目前業界使用非常廣泛的一種數字内容版權保護技術。随着知識産權保護受重視的程度日益提高，快速攻城略地得Android智能手機是如何利用DRM來有效保護數字版權的呢？本文将通過剖析Android中的DRM架構以及相關工作流程來向讀者揭示DRM的神秘面紗。
一 DRM架構介紹
嚴格來講，DRM不是一項技術，而是一類技術。很多機構和聯盟都提出過相應的DRM标準。例如Open Mobile Alliance推出的OMA DRM、Marlin Developer Community提出的Marlin DRM，而Google則通過收購Widevine公司推出了Widevine DRM。
從Android智能終端來看，Google的原生Android（Android Open Source Project，簡稱AOSP）系統僅僅內建了OMA DRM V1的一部分功能，它遠未構成一個完整的DRM解決方案。在這種情況下，裝置廠商隻能根據情況選擇合适的DRM解決方案并內建到Android平台中來。例如，手機廠商可以通過Google的授權以擷取Widevine DRM對應的軟體包進而将Widevine DRM內建到自己的産品中。
為了友善裝置廠商的內建，Android設計了一個通用的DRM軟體架構，不同的DRM解決方案可通過Plugin的方式內建到Android系統中。圖1所示為Android中的DRM軟體架構。
圖1 Android中DRM軟體架構
由圖1可知:
- DRM Framework API子產品是Framework層暴露給App的接口。該子產品中最主要的類是DrmManagerClient。
- DRM Framework API子產品通過Binder機制和位于drmserver程序（以Android 4.1為例，drmserver的代碼位于framework/av/drm/drmserver）中的DRM Manager子產品通信。DRM Manager加載并管理系統中所有的DRM插件。
- DRM Plugins是真正實作權限管理、數字内容解密等工作的子產品。根據DRM标準的不同，這些Plugins的實作亦不相同。另外，一個手機可能會內建多個DRM Plugin。這是因為媒體檔案如果采用不同的DRM解決方案進行加密的話，手機在播放它們時，DRM Manager需找到對應的DRM Plugin以進行解密。
圖2所示為DRM架構中幾個重要的類及其關系。
圖2 Android中DRM架構中重要類圖
由圖2可知:
- FileSource代表一個媒體檔案。如果媒體檔案中有DRM資訊，它将建立一個DrmManagerClient對象。該對象用于處理媒體檔案中和DRM相關的操作。DrmManagerClient内部通過DrmManagerClientImpl和位于drmserver程序中的DrmManagerService進行跨Binder通信。
- MediaExtractor類封裝了用于解析媒體檔案中中繼資料的相關函數。對于DRM來說，系統會根據的DRM種類建立不同的MediaExtractor子類。和FileSource類似，MediaExtractor也通過DrmManagerClient和drmserver通信。
- DrmManagerService運作于drmserver程序中，它是整個DRM架構的核心。DrmManagerService借助DrmManager管理系統中的DRM插件。
- DRM插件必須實作IDrmEngine接口。為了友善開發者，Android提供了DrmEngineBase類，該類繼承了IDrmEngine接口并實作了一些通用的接口函數。這樣，DRM Plugin隻需要從DrmEngineBase派生即可。
- 如前文所述，DRM架構中真正完成DRM處理工作的是DRMPlugins，這些Plugins大都需要得到相關機構的授權後才能得到相應的專利代碼包。圖1中列出了三個DRM Plugin。其中FwdLockEngine（OMA-V1的Forward Lock）由AOSP提供。Marlin Plugin和WidevinePlugin則需要相關DRM機構提供專利代碼包。
下面來看看Android中DRM的工作流程。
二 DRM工作流程介紹
2.1 DrmManagerService的初始化
DRM的工作流程和多媒體播放密切相關。首先來了解一下DrmManagerService的建立過程，相關流程如圖3所示：
圖3 DrmManagerService啟動流程
由圖3可知：
- DrmManagerService執行個體對象由drmserver程序在main函數中調用instantiate建立。
- DrmManagerService内部會建立一個DrmManager執行個體對象并調用loadPlugins來加載裝置可能提供的DRM Plugin。DRM Plugin通過動态庫的方式內建到設定中去。Android 4.1中有兩個目錄可存放DRM Plugin。一個是/vendor/lib/drm/，例如Widevine對應的libdrmwvmplugin.so一般放在這個目錄中。另一個目錄是/system/lib/drm/。每一個DRM Plugin對應為一個IDrmManager執行個體。所有被加載的DRM Plugin由DrmManager來統一管理。
- DrmManagerService最後将通過addService把自己注冊到Binder系統中以為廣大用戶端服務。
下面來介紹DRM的工作流程。Android支援的DRM播放方式分為兩種：
- 一種是基于基本碼流的（Elementary Stream Based，簡稱ES Based）播放方式。目前Widevine DRM、Marline DRM都屬于這一種類型。
- 另一種是基于容器的（Container Base）播放方式，目前OMA DRM支援這種方法。
這兩種不同的方式在播放流程上不盡相同。下文将以一個播放具有DRM保護的MP4檔案為例，介紹DRM的工作流程。首先來看ES BasedDRM媒體播放工作流程
2.2 ES BasedDRM播放流程
ES Based DRM意味着每一個資料基元在播放時都需要解密。這種DRM的媒體檔案或流可以使用普通方式正常讀取，但讀取出來的資料是經過加密的。如果不能對資料正确解密，那麼該資料将無法正常播放。
在播放媒體檔案之前，播放器首先要識别該檔案是否被DRM保護。如果受DRM保護的話，還行初始化對應的DRM插件。這部分工作所涉及的流程如圖4所示：
圖4 ES BasedDRM插件初始化
由圖4可知：
- MediaExtractor首先通過sniff函數檢查媒體内容的類型，然後建立相應的Extractor來分析資料。在DRM檢查開啟的情況下，SniffDRM函數就會被用來檢查檔案是否有DRM控制。
- SniffDRM将調用DataSource中的DrmInitialization函數，進而在DataSource中建立一個DrmManagerClient執行個體。如此，MediaExtractor就将DataSource與DrmManagerService聯系起來。
- DrmInitialization函數非常重要，其主要工作包括：
（1）調用openDecryptSession，該函數内部會根據檔案中的DRM資訊來初始化正确的DRM Plugin（Widevine、OMV，還是其他DRM類型）。
（2）建立DecryptSession，并将DRM資訊封裝在DecryptHandler執行個體中傳給FileSource。
- DrmInitialization之後，SniffDRM會通過DecryptHandler來判斷該檔案是否有DRM控制，并分析出該DRM是ES Based，還是Container Based。如果屬于ES Based DRM，MediaExtractor會建立一個DRMExtrator，而在DRMExtrator中，會建立一個MPEG4Extractor。
MediaExtrator建立完後，播放器即可開始播放。ES Based DRM播放相關流程如圖5所示：
圖5 ES Based的DRM媒體檔案播放流程
圖5所示的流程圖可分為三個階段：
- 第一個階段是資源初始化過程。該過程中，媒體播放器将通過getTrack以後擷取一個媒體檔案中代表媒體資料的DRMSource執行個體，DRMSource隻負責DRM的控制和解密，而實際媒體資料的分析仍交給MPEG4Extractor來完成。對于播放器來說，它隻和DRMExtrator和DRMSource互動。另外，在這一階段中，initializeDecryptUnit函數将初始化解密相關的資源。
- 第二階段就是媒體資料讀取，針對每一個資料基元，DRMExtrator都會先通過MPEG4Extractor取得未解密的原始資料，然後通過decrypt函數來請求DRM Plugin進行解密。解密後的資料會被放到另外一處緩存中供Codec使用。如果解密失敗，decrypt将會傳回錯誤，故播放器将無法解析這些資料。
- 媒體播放完畢後将釋放播放資源。和DRM相關的資源将由finalizeDecryptUnit來釋放。
回顧上述流程，對ES Based DRM的特點是，不論使用者是否有權限，播放器都能讀取到媒體資料。
下面來看看Container Based DRM的播放流程。
2.3 Container Based DRM播放流程
和ES Based DRM截然不同的是Container Based DRM。受控于這種DRM管理的媒體檔案在被讀取時就會進行DRM的權限驗證，如果驗證失敗，則無法從中讀取到資料。故Container Based DRM最關鍵的是其pread接口，相關流程如圖6所示：
圖6 ContainerBasedDRM播放流程圖
如圖6可知：
- 首先要進行的工作仍是判别資料格式和DRM類型并建立DrmManagerClient。這一過程和ES Based DRM流程相同，此處不拟贅述。
- 接下來需建立MediaExtractor執行個體。與ES Based DRM不同的是，Container Based DRM在播放時無需建立DRMExtractor，而是直接建立MPEG4Extractor，并在該MediaExtractor中設定DRM的辨別。
- Container Based DRM關鍵在于pread函數。當MediaExtractor從FileSource中提取資料時，readAt最終通過DrmManagerClient的pread函數來通路DrmManager以從中讀取資料。DrmManager将調用具體的DRMPlugin實作的pread。資料的權限檢查和解密的工作都在該DRMPlugin完成。如果DRM解密失敗，pread将不會得到資料。
上文介紹了Android平台中DRM播放的大體流程。下面來看看Google主推的Widevine DRM。
三 Widevine DRM介紹
2010年12月，Google不惜重金将視訊數字版權管理軟體公司Widevine招安。現在看來，Google的這一招為Android陣營增添了一員上将，有Widevine坐陣中軍，Android就有實力在數字内容這片戰場上與已故喬幫主的蘋果一較高下。
在收購Widevine之前，Android沒有系統的數字版權保護機制，而蘋果則在iTunes、iPod時代就建立了完善的版權體系，這讓很多内容提供商更願意在iOS上釋出自己的數字内容，進而使得iOS的生态系統更加豐富和成熟。Widevine的引入彌補了Android在這方面的短闆，它是幫助Android成為當今移動OS霸主的功臣之一。
Android從3.0開始就支援Widevine，這距離Google收購Widevine僅僅過去了三個月，可見Google對于數字版權保護的迫切性。現在Widevine已經成為GMS（Google Mobile Service）中必備的内容，所有想要得到GMS的手機廠商，都需要根據GMS的要求搭載Widevine。
作為Google帳下的愛将，Google為支援Widevine也煞費苦心。目前Android平台中播放Widevine DRM媒體有兩種方法：
- 第一種方法和前文介紹的一樣。Widevine DRM按照ES Based的流程進行播放。但和一般DRM不同的是，Widevine使用的Extractor是WVMExtractor，而不是DRMExtractor。
- 第二種方法是MediaCodec模式，相關結構如圖7所示。
圖7 Widevine Crypto Plugin
由圖7可知：
- MediaCodec、MediaCrypto以Java API的形式直接暴露給應用層。這樣，應用層能夠控制解碼、解密的過程。
- Crypto Plugin是實際完成解密的子產品，其結構和前文提到的DRM Plugin有所不同。
需要特别指出的是，Android目前對MediaCodec模式支援還不是很完善。根據筆者的試驗，一些市面上流行的高端Android 4.1手機還不支援這種播放方式。
另外，Widevine的代碼結構大體可分為三部分：
- 第一部分是Android中的基本架構，包括WVMExtractor等。這部分代碼在AOSP中都可以看到，屬于Open Source的内容。這部分代碼大多沒有實質性内容，相關功能的實作封裝在第二部分的專利代碼包中。
- 第二部分是Widevine的專利代碼包。這部分代碼需要得到Google授權後才能得到。該包提供了很多Widevine專用庫用于完成Widevine DRM權限檢查和解密。同時，它還提供了一些Sample App用于測試。
- 第三部分是手機廠商自身的安全認證。Widevine是一個很強的版權控制體系，它甚至可在硬體層與廠商的安全機制綁定。很多知名的手機廠商都在boot等底層中加入自己的安全機制，隻有通過可信賴的boot loader進行刷機才能得到具有正常權限的手機軟體，并可以使用Widevine。這也是為什麼很多破解的手機無法使用Widevine的原因。
由于專利代碼包和廠商安全機制都涉及到版權問題，故本文就不拟對Widevine做進一步讨論了。如果廠商希望在自己的産品上也搭載Widevine，那麼首先需要與Google聯系。Google會提供Widevine的專業教育訓練。
四 總結
本文主要講述了Android中DRM的運作機制。事實上，DRM是一個不易觸及的領域。由于其安全性高，保密性強，世界上真正掌握DRM核心技術的公司并不多。根據筆者的調查，DRM産業鍊中的相關者大概可分為如下三類：
- 第一類是制定DRM标準的公司或機構，他們掌握DRM的核心技術，對外推廣自己的DRM标準，為需要搭載DRM的公司提供支援。
- 第二類是數字内容提供商，他們是最迫切應用DRM來保護自己數字版權的人，他們會向提供标準的公司夠買DRM技術，在伺服器端加密，并制定數字内容的買賣租賃機制以及相應的密鑰配發原則。
- 第三類是終端裝置制造商，為了讓自己的裝置具有更廣泛的應用性，他們需要搭載主流的DRM以适應市場需求，在搭載過程中，他們也需要标準公司的支援，拿到一些有專利的代碼包，有時還會與内容提供商合作。當然，還有的時候，一家公司會擔當其中的兩個或全部角色，比如亞馬遜，他即是内容提供商，提供電子書籍等内容，又是終端裝置商，出品Kindle Fire這樣的終端裝置，這樣做可以讓他把内容和終端更好地整合在一起。
然而，國内DRM并不非常受歡迎。筆者對于國内的版權保護并無批評之意。隻是由于國内數字内容發展的過程比較特殊，最終形成了當下這種以免費内容占主流的市場氛圍和消費習慣。對于國内市場，任何一種強行主推DRM的收費模式的方法目前看起來還不合适。相信很多網際網路巨頭已經在其長期的摸索中體會了這一點。
當然這并不是說DRM在國内沒有市場。目前很多公司在免費業務之上都加入了基于更高品質的收費業務，進而豐富了盈利的方式。更為重要的是，現在很多中國公司都在向國外擴張，而中國公司走到外面，就必須入鄉随俗，遵從國外的遊戲規則。這時，數字版權保護以及建立在其之上的DRM技術就成了一個必須要重視的問題。在此，筆者真心希望有一天國内能有更多優秀的公司走出國門，在中國模式和世界模式間找到平衡點，将我們自己的數字内容和終端産品推向世界