OMA DM FUMO 1.O 協議
(OMA-TS-DM-FUMO-V1_0-20060615-C)
一.簡介
?? 本規范描述基于OMA-DM的移動設備的固件升級相關的管理對象信息和管理對象的處理行為。同時被說明的還有同"Exec"命令和Generic Alerts相關的行為。
??
?? 它解決的是移動設備的交互固件升級方案的缺陷。本規范為客戶端和服務器端提供了一套接口來支持固件升級，這個方案由升級包下載、固件安裝和狀態（升級成功或失?。﹨R報三部分組成。
?
?? 本規范為移動操作員、服務提供商、基礎架構廠商、設備制造商和軟件提供商來開發和部署交互式固件升級方案提供依據。
?
?? 目標觀眾：提供固件升級方案和升級包下載方案的工程師。
?
二.固件升級管理對象(FUMO)
?? 固件升級管理對象的基本結構如下：
?
????x---|-----PkgName？?????????? 〈---???????Name of Update Package
??????????|-----PkgVersion？??????? 〈---???????Version of?Update Package
??????????|-----Download??????????? 〈---???????Node used by Exec to initiate download
???????????????????????|---PkgURL?????〈---???????Reference to target for Update Package
??????????|-----Update?????????????? 〈---???????Node used by Exec to initiate Update
???????????????????????|---PkgData??? 〈---???????Reference to target for Update Package
??????????|-----DownloadAndUpdate？〈------??Node used by Exec to initiate
???????????????????????|?????????????????????????????????????????Download and Update?
???????????????????????|---PkgURL?????〈---???????URL Location? to get Update Package
??????????|-----State???????????????? 〈---???????Current State of the device
??????????|-----Ext？????????????????? 〈---?????? Hook for Vendor Specific Extensions?
?
2.1固件升級管理對象參數
?? 下面描述的是固件升級管理對象的節點。
?
2.1.1節點：x
?? 這個內部節點作為一個占位符扮演著固件升級包唯一識別符的角色，其類型必須同第5部分指定的管理對象識別符相對應。廠商可以為x預創建一些永久節點，如果需要也允許通過升級包節點x創建，或者聯合這兩種方式。舉例來說，永久節點可以在固件包加工的時候創建，其他節點作為新特征來增加。一個例子將可能包含標簽節點FWPkg1,FWPkg2...FWPkgn。設備制造商提供的DDF文件指出了x節點被定位到了管理樹的什么位置。
?
?? Occurrence：ZeroOrMore
?? Format：Node
?? Access Types：Get
?? Values：N/A
?
2.1.2節點：x/PkgName
?? 這個可選節點指出了固件升級包的名稱。
?? Occurrence：ZeroOrOne
?? Format：Chr
?? Access Types：Get
?? Values：N/A
?
2.1.3節點：x/PkgVersion
???這個可選節點指定了固件升級包的版本信息，版本信息是設備制造商指定的并且可以容納任意數據。
?? Occurrence：ZeroOrOne
?? Format：Chr
?? Access Types：Get
?? Values：N/A
?
2.1.4節點：x/Download
?? 這個可選內部節點是為了初始化固件下載執行Exec命令的目標。
?? Occurrence：ZeroOrOne
?? Format：Node
?? Access Types：Exec，Get
?? Values：N/A
?
2.1.5節點：x/Download/PkgURL
?? 這個節點指出了固件升級包或下載描述文件的目標URL，這個URL被用來作為可選的下載機制（譬如像HTTP Get[RFC2616]或者Descriptor Based Download[DLOTA]）。
?? Occurrence：One
?? Format：Chr
?? Access Types：Get，Replace
?? Values：N/A
?
2.1.6節點：x/Update
?? 這個可選內部節點是為了初始化固件升級執行Exec命令的目標。
?? Occurrence：ZeroOrOne
?? Format：Node
?? Access Types：Exec，Get
?? Values：N/A
?
2.1.7節點：x/Update/PkgData
?? 這個節點是當DM被用來直接提供二進制固件升級包數據時執行Replace命令的目標。
?? Occurrence：ZeroOrOne
?? Format：Bin
?? Access Types：Replace
?? Values：N/A
?
2.1.8節點：x/DownloadAndUpdate
?? 這個可選內部節點是為了初始化固件下載和升級執行Exec命令的目標，這個升級必須在一旦下載完畢后發生。
?? Occurrence：ZeroOrOne
?? Format：Node
?? Access Types：Exec，Get
?? Values：N/A
?
2.1.9節點：x/DownloadAndUpdate/PkgURL
?? 這個節點指定了固件升級包或者下載描述文件的位置URL，這個將接下來被用來下載和升級。這個URL被用來作為可選的下載機制（譬如像HTTP Get[RFC2616]或者Descriptor Based Download[DLOTA]）。
?? Occurrence：One
?? Format：Chr
?? Access Types：Get，Replace
?? Values：N/A
?
2.1.10節點：x/State
?? 指明同這次固件升級關聯的移動設備的當前狀態。
?? Occurrence：One
?? Format：Int
?? Access Types：Get
?? Values：看下表
?? 下面的狀態表枚舉了有效狀態：
????
State
????????????????????? ??????????????????????
Description
???????????????????????????????????????????
Integer Value
??? Idle/Start????????????????????????????? No pending operation?????????????????????????10??????????????
??? Download Failed????????????????????? Download failed????????????????????????????????20??????????????
??? Download Progressing????????????? Download has started???????????????????????? 30??????????????
??? Download Complete???????????????? Download has been completed?????????????40??????? ??????
???????????????????????????????successfully????????????????????????????
??? Ready to Update???????????????????? Have data and awaiting command???????50???????????????
??????????????????????????????to start update?????????????????????????
??? Update Progressing?????????????????Update has started????????????????????????????60???????? ??????
??? Update Failed/Have Data????????? Update failed but have?????????????????????? 70??????????????
????????????????????? update package??????????????????????????
??? Update Failed/No Data???????????? Update failed and no update??????????????? 80??????????????
??????????????????????????? package available???????????????????
??? Update Successful/Hava Data?? Update complete and data?????????????????? 90??????????????
???????????????????????? still available?????????????????????????????
??? Update Successful/No Data????? Data deleted or removed???????????????????? 100????????????
??????????????????????? after a successful Update???????
2.1.11節點：x/Ext
?? 這個節點是為了提供商特殊的擴展。
?? Occurrence：ZeroOrOne
?? Format：Node
?? Access Types：Get
?? Values：N/A
?
三.管理對象的行為
?? 下面的圖表展示了固件升級時終端的有效狀態的轉換，有些狀態服務器是不知曉的。
?
?
?
?? 典型的，開始狀態是"Idle/Start"，結束狀態是下面的一個：
- Update Failed / Have Data
- Update Failed / No Data
- Update Successful / Have Data
- Update Successful / No Data
- Download Failed
3.1Exec命令
?? Exec命令是必須被支持的。
?? 服務器發出Exec命令來在客戶端執行長時間運行的操作，譬如下載和升級。執行Exec命令的結果作為一個ResultCode被編碼，然后隨著操作的完成用一個Generic Alert返回。一個correlator如果伴隨著Exec命令應用，也將在Generic Alert中返回。如果Exec命令被接受并進入后續處理客戶端必須異步返回一個202狀態。
?? 當在Download節點上執行Exec命令，需要提示用戶選擇的時候，則服務器可以發出一個用戶交互Alert(User Interaction Alert [DMPRO]).
?? 如果采用OMA DM協議的large-object的方式執行升級包的下載，服務器首先用‘Replace’命令來執行下載，然后采用Exec命令來執行升級。
?? 管理對象的State節點被用來表明相應的升級和下載執行后客戶端的狀態變化。
?
3.1.1下載時Exec命令的語義
?? 服務器在x/Download節點上發出Exec命令?？蛻舳烁鶕掌靼l出的x/Download/PkgURL節點標示的URL值初始化一個下載操作。當下載操作完成后，客戶端發出一個Generic Alert來表明下載操作的結果。
?
3.1.1.1下載時Exec命令的示例
?? 前置條件：下面的元素節點被設定為正確的值。
-
?? x/Download/PkgURL被設定
?? Exec命令的例子：
?? <Exec>
????? <CmdID>3</CmdID>
????? <Item>
???????? <Target>
??????????? <LocURI>x/Download</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
????? <CmdID>3</CmdID>
????? <Item>
???????? <Target>
??????????? <LocURI>x/Download</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
?
3.1.2升級時Exec命令的語義
?? 服務器在x/Update節點上發出Exec命令，客戶端利用的是前面Download所接收的升級包。升級操作完成后，客戶端發出一個Generic Alert來表明升級操作的結果。
?
3.1.2.1升級時Exec命令的示例
?? 前置條件：固件升級包必須在設備上已存在。
?? Exec命令的例子：
?? <Exec>
????? <CmdID>3</CmdID>
????? <Item>
?????????<Target>
??????????? <LocURI>x/Update</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
????? <CmdID>3</CmdID>
????? <Item>
?????????<Target>
??????????? <LocURI>x/Update</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
3.1.3下載升級時Exec命令的語義
?? 服務器在x/DownloadAndUpdate節點上發出Exec命令，客戶端根據服務器發出的x/DownloadAndUpdate/PkgURL節點標示的URL值初始化一個下載操作，當下載操作成功完成后，客戶端在不需要服務器的干預下應用接收到的升級包。升級操作完成后，客戶端發出一個Generic Alert來表明升級操作的結果。在這次事件流程中，當下載失敗時，客戶端發出一個Generic Alert來表明下載操作的失敗。
?
3.1.3.1下載升級時Exec命令的示例
?? 前置條件：下面的對象需要用正確的值來設定。
- ?? x/DownAndUpdate/PkgURL
?? Exec命令的例子：
?? <Exec>
????? <CmdID>3</CmdID>
????? <Item>
???????? <Target>
??????????? <LocURI>x/DownloadAndUpdate</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
????? <CmdID>3</CmdID>
????? <Item>
???????? <Target>
??????????? <LocURI>x/DownloadAndUpdate</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
?
3.2通知中Generic Alert的使用
?? 在3.1節中當Exec命令執行結束時，設備需要向DM服務器使用Generic Alert [DMPRO]發送一個通知。這個alert消息包含下面的數據：
- ?? 一個整形的結果代碼--被用來匯報結果狀態
- ?? 固件升級管理對象的URI--用來識別源
- ?? 一個alert類型--用來識別操作
- ?? Correlator--被服務器使用并作為Exec命令的一部分來傳輸
?? 正在匯報錯誤或者失敗的alerts也將在Meta信息的Mark域中除了匯報一般信息外還有嚴重性級別信息。
?? 一旦操作完成后Generic Alert被發送到DM服務器，如果沒有服務器的進一步干預，設備一定不能再次經由Exec命令發起上次操作。
?? 注意：如果服務器需要檢索額外的信息，譬如狀態State，則服務器需要向客戶端查詢那些指定的節點。
?
3.2.1固件升級管理對象的URI
?? 這個URI必須作為Generic Alert [DMPRO]消息的源source被發送，這個允許管理服務器來識別alert的原先來源。
?
3.2.2固件升級的alert類型
?? 來源于管理對象的下面的alert類型必須被使用在Generic Alert [DMPRO]消息中。這個alert類型被用來識別到底在設備上Exec命令執行什么操作。
?? alert類型“org.openmobilealliance.dm.firmwareupdate.download”被用來回復下載操作的完成。
?? alert類型“org.openmobilealliance.dm.firmwareupdate.update”被用來回復升級操作的完成。
?? alert類型“org.openmobilealliance.dm.firmwareupdate.downloadandupdate”被用來回復下載升級操作的完成。
?
3.2.3Correlator
?? 固件升級操作中在?Exec命令里如果服務器傳輸了一個correlator給客戶端，客戶端必須在Generic Alert [DMPRO]消息的correlator域返回相同的值給服務器。
?? 固件升級操作中在?Exec命令里如果服務器沒有傳輸correlator給客戶端，客戶端一定不要在Generic Alert [DMPRO]消息的correlator域返回一個correlator。
?
3.2.4結果代碼
?? 操作的結果代碼必須作為一個整形值在GenericAlert [DMPRO]消息的Data元素中被發送。結果代碼必須是下面定義值中的一個：
?
結果代碼???????????????? 含義?????????????????????????????????????? 應用?????????????????????????????????????????????
200??????????????????? 成功??????????????????????????????? 成功-請求成功
250-299??????????????成功-廠商指定??????????????????? 廠商指定結果代碼為成功?
400??????????????????? 管理客戶端錯誤???????????????????管理客戶端錯誤-基于用戶或設備行為?
401??????????????????? 用戶取消?????????????????????????? 當提示時用戶選擇不接受操作
402??????????????????? 損壞的固件升級包???????????????? 沒有正確的存儲、發現，譬如在希望
????????????????????????????????????????????????????????????????????的和真實的CRCs不匹配
403??????????????????? 固件升級包-設備不匹配??????????錯誤的升級包傳到了設備上?
404??????????????????? 固件升級包驗證失敗????????????? 數字簽名驗證失敗?
405??????????????????? 固件升級包不被接受????????????? 固件升級包不被接受?
406????????????????????下載時驗證失敗???????????????????當下載升級包時，需要驗證但驗證失敗
407??????????????????? 下載時Time-Out???????????????? 客戶端出現了下載時time-out?
408??????????????????? 沒有實現?????????????????????????? 設備不支持的請求操作?
409??????????????????? 未定義錯誤????????????????????????通過其他錯誤代碼標明失敗未定義
410??????????????????? 固件升級失敗???????????????????? 設備上的固件升級失敗???
411????????????????????URL有問題????????????????????????提供下載用的URL存在問題???
412??????????????????? 連不上下載服務器????????????????下載服務器不可得或沒有響應?
450-499??????????????客戶端錯誤-廠商指定??????????? 由廠商指定自己的結果代碼??
500??????????????????? 下載服務器錯誤?????????????????? 遇到了下載服務器錯誤??
501??????????????????? 下載失敗-由于設備內存不足????設備內存不足以保存下載的升級包??
502??????????????????? 升級失敗-由于設備內存不足??? 沒有充足的內存來更新設備
503??????????????????? 下載失敗-由于網絡問題?????????網絡或傳輸層錯誤導致下載失敗?
550-599??????????????下載服務器錯誤-廠商指定?????? 廠商自己制定的下載服務器錯誤代碼???
?
在上面的表格中，2xx序列標明成功結果，4xx和5xx標明失敗的結果和原因。
??
3.3升級包下載和升級的支持
?? 支持FUMO 1.0的客戶端必須至少一種的升級包下載方式，這種下載機制必須是OMA DM下一種的傳輸和下載機制，譬如OMA Download
[DLOTA].另外，為了成功的執行一次固件升級，至少下面一個活動被支持：
[DLOTA].另外，為了成功的執行一次固件升級，至少下面一個活動被支持：
- ?? Exec on x/Update 節點
- ?? Exec on x/DownloadAndUpdate 節點
?
4客戶端發起的固件升級（標準的）
?
4.1概要
?? 固件升級在設備上也有自己的獨立性，所以這個對于客戶端設備和服務器可以作為一個可選的特征。??這部分僅將定義客戶端發起的消息格式和在什么樣的環境下設備不發起。
?? 這個通知時用Generic Alert格式，如果客戶端發起的固件升級請求被實現，那么下面的客戶端請求必須被支持。
?
4.1.1Generic Alert?
?? 消息必須遵循Generic Alert格式。
?
4.1.2Alert Type
?? 設備發起的固件升級消息類型必須使用“org.openmobilealliance.dm.firmwareupdate.devicerequest”，用戶發起的固件升級alert類型必須使用“org.openmobilealliance.dm.firmwareupdate.userrequest”。
?
4.1.3URI
?? 如果指定了alert中的URI，則其必須指向在管理樹中代表一單獨固件升級管理對象的動態節點（譬如<x>）。當節點存在時，服務器就會檢查管理對象表示的固件升級的有效性。如果不存在則會進一步被建議，服務器就會檢查發起這次alert的終端相關的所有固件升級的有效性。服務器可以查詢URI指明的管理對象的內容，只要有相關的升級被發現，服務器就應該發起一個固件升級。
?
4.1.4Data
?? Data元素是必須的。客戶端廠商可以使用這個域來提供明確的實現數據。如果沒有明確的實現數據，這個值需要被設定為空。
?
5 FUMO 應用（通常情況下）
5.1固件升級協議預覽
?? 固件升級協議指定了一系列標準命令（關聯的參數和管理對象），也將在OTA固件升級中使用。OTA固件升級在處理發現、安全、下載、安裝時需要特別的留意。
?? OMA DM在無線設備管理領域是最主要的標準。OMA Download [DLOTA]規范也為通常內容的下載提供了一套靈活的協議，僅僅通過一個分離的下載描述符來控制。下載過程是抽象的，即允許用戶使用OMA DM（E.g., Add/Replace）也允許任何適合的下載機制（用OMA Download [DLOTA]下載協議描述的下載）。
?? 為了獲取OTA固件升級，協議必須支持下面的流程：
- ?? 固件升級步驟1：固件升級開始
- ?? 固件升級步驟2：設備信息交換
- ?? 固件升級步驟3：固件下載
- ?? 固件升級步驟4：固件安裝
- ?? 固件升級步驟5：固件升級的狀態通知
?
5.1.1場景1：經由OMA DM Download（Replace）的固件升級--Large Object
?? 下面的例子展示了如何使用OMA DM協議通過DM Replace命令來將固件的二進制包數據移動到終端設備上。
?
?
?
5.1.2場景2：經由可選下載機制方案的固件升級
?? 下面的例子展示了OMA DM如何調用外部的二進制包數據，通過DM Replace命令來下載固件包：
?
5.1.2.1例子1：‘Exec’ on x/Download node + ‘Exec’ on x/Update node
?? 服務器針對x/Download節點發出Exec命令，如果需要，服務器將在客戶端發送下載通知給服務器后針對x/Update節點發出Exec命令。
?
5.1.2.2例子2：‘EXEC’ on x/DownloadAndUpdate node
?? 服務器針對x/DownloadAndUpdate節點發出Exec命令，在DownloadAndUpdate操作完成后客戶端發送一個最后的通知給服務器。
?
5.2協議定義
?
5.2.1固件升級步驟1：固件升級開始
?? 為了開始任何一個固件升級，設備都需要打開一個到服務器的數據連接。下面的機制能被支持來開始一個固件升級流程：
- ?? 用戶發起
- ?? 網絡發起
?? 用戶發起的升級由于并不需要特殊的標準所以沒有放到這個規范中，推薦的做法是通過設備上的菜單或是服務代碼。用戶發起的升級流程將簡單的打開一個OMA DM會話。
?? 對于網絡發起的升級來說，OMA DM 管理端提供了一個框架通過發送一個Notification Initiation Alert”給客戶端來觸發客戶端開啟數據會話。It is the intent of the Firmware Update Protocol to leverage General Package#0 as specified in the OMA DM Notification Initiation Session document [DMNOTI].OMA DM 指定使用WAP Push并且制定一個可接受的格式來發起這個固件升級。
?
5.2.2固件升級步驟2：設備信息交換
?? 為了讓設備能夠正確地做固件升級，一個最小集合的設備信息標準被客戶端發送到了服務器。為達到固件升級的目的，這個最小集合的設備信息是對每一個OMA DM管理會話都是永久的DevInfo參數[在DMSTDOBJ, Section 5中指定]。
?? 注意：下一部分描述的固件下載流程的安裝必須在一個可選的用戶交互以后進行信息交換。一個OMA DM “alert”命令將被用來傳輸用戶確認信息。
?
5.2.3固件升級步驟3：固件下載
?? 固件下載可以通過OMA DM Replace命令（Large Object）或者外部的數據包文件下載來開啟。這兩種方式各有利弊，所以依賴于軟件提供商和設備制造商來共同決定選擇一個首選的實現。協議建議兩種方式都支持。
?? 請參考附件D查看更進一步的細節信息。
?
5.2.4固件升級步驟4：固件安裝
?? 預期在市場上會有很多產品來在設備上進行固件升級。固件升級規范的目的是為了規范設備和無線網絡解決方案的互操作性，所以這個規范并不處理獨立于網絡之外的固件升級的處理。換句話說，這個規范為固件安裝提供需求來獲取可以接受的用戶經驗。
?
5.2.4.1在OMA DM Download后的固件安裝（Large Object）
?? 下面的這個Exec命令在固件已經使用OMA DM Replace下載到Pkgdata元素的情況下發起這次升級流程：
?? <Exec>
????? <CmdID>3</CmdID>
????? <Item>
???????? <Target>
??????????? <LocURI>.x/Update</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
????? <CmdID>3</CmdID>
????? <Item>
???????? <Target>
??????????? <LocURI>.x/Update</LocURI>
???????? </Target>
????? </Item>
?? </Exec>
?
5.2.4.2可選下載方式的固件安裝（外部數據下載）
?? 對于外部二進制固件升級包下載方式（像OMA v1.0 Download的描述符），推薦的方式是提供正確的安裝參數要由于使用Exec命令發起下載操作。
?? 當升級操作完成升級包不再需要的時候，升級包將從對象存儲中刪除。設備的管理客戶端可以選擇在升級成功或失敗結束后立刻刪除升級包，也可以不管什么時候服務器提示刪除的時候刪除。
?
5.2.5固件升級步驟5：固件升級狀態的通知
?? 在固件升級流程完成的時候，設備通知服務器固件升級的結果狀態。這個是通過一個連續的客戶端或者服務器發起的OMA DM會話來確保管理服務器被通知了這個結果狀態。
?? 客戶端通過Generic Alert [DMPRO]提供一個結果代碼給服務器。
?? OMA DM協議提供的Generic Alert [DMPRO]命令將被OMA-DM客戶端用來通知給DM服務器結果代碼的值。
?
5.2.5.1非致命的結果代碼
?? 對于非致命的升級失敗，終端用戶可以用一種可操作的模式提供失敗指示和終端號碼。
?? 另外就像上面的結果代碼表中列出的一樣，./FwUpdate/x/State元素會提供更多的信息。
?
5.2.5.2致命失敗
?? 致命的失敗將很可能導致設備不可操作，所以就不可能提示終端用戶或是通知服務器這次失敗。因為這個原因，實現并沒有提供一個高層次的錯誤容錯機制在這方面。
?
（完）
（附件信息請直接查看協議）
疑問：我們知道當升級完成后，設備會重新啟動，然后設備上的客戶端會開啟一個新會話向服務器報告升級狀態，我們知道這個alert是1226，其內容是
<Alert>
?? <CmdID>2</CmdID>
?? <Data>1226</Data> <!-- Generic Alert -->
?? <Correlator>abc123</Correlator>
?? <Item>
????? <Source><LocURI>./SyncML/Sample</LocURI></Source>
????? <Meta>
???????? <Type xmlns="syncml:metinf">
??????????? Reversed-Domain-Name: org.domain.samplealert
???????? </Type>
???????? <Format xmlns="syncml:metinf">xml</Format>
???????? <Mark xmlns="syncml:metinf">critical</Mark> <!-- Optional -->
????? </Meta>
????? <Data><!-- Client Alert Data Goes Here -->
????? </Data>
?? </Item>
</Alert>
?? <CmdID>2</CmdID>
?? <Data>1226</Data> <!-- Generic Alert -->
?? <Correlator>abc123</Correlator>
?? <Item>
????? <Source><LocURI>./SyncML/Sample</LocURI></Source>
????? <Meta>
???????? <Type xmlns="syncml:metinf">
??????????? Reversed-Domain-Name: org.domain.samplealert
???????? </Type>
???????? <Format xmlns="syncml:metinf">xml</Format>
???????? <Mark xmlns="syncml:metinf">critical</Mark> <!-- Optional -->
????? </Meta>
????? <Data><!-- Client Alert Data Goes Here -->
????? </Data>
?? </Item>
</Alert>
這里面并沒有地方標示我這個升級結果是針對哪次的升級，也就是如果兩次升級同時完成，我怎么知道這個是通知的那一個升級呢？雖然上面已經說過使用一個連續的alert來通知，這種情況會極少出現，但是怎么也要考慮吧？
現在已經實施的SmartDM項目的做法是確保每次對一個終端（號碼）只存在一個操作來解決，也就是從服務器端就杜絕了一個設備同時做兩種或者兩個操作的可能。
但是我在Bindu的培訓中好像聽說過，以后會在這個alert 1226中增加各自上次操作會話ID來區分到底是對那個操作的回復，這樣就在客戶端解決了這個問題，但是我現在在OMA DM 1.2的協議里面沒有找到這個。
?
| ? | ||
| ? | ||
| ? | ||
| ? |
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
