DM要点解析

RedBend关于DM的培训总结报告
本次会议历时2天， 总计4个小时左右， 比较全面地介绍了FOTA, FUMO等协议以及RedBend公司关于DM（移动售后增强服务）的实现。
第一天下午先对Questionnire问题单的重要性进行了讲解。RedBend公司需要我们提供具体机器的相关参数以便提供精确的实现库。因为库的具 体实现是需要根据机型来确定的， RedBend北京分公司只有在获取到这个Questionnaire反馈单之后提供给总部才能获得库。 我们在初期对这个Questionnaire的反馈不够及时， 造成了进度上的一些延后， 这是以后在合作的时候需要改进的地方。
然后重点说明了FOTA协议以及它和DM的关联。简单来说， FOTA是用来进行手机固件升级的一个组件。它将差分包从服务器上下载下来， 然后生成新的Image, 替换掉手机中老的体统， 达到升级的目的。其中如何将差分包做到尽可能的小， 是一个难题。RedBend公司有他们的专利技术。RedBend提供了UPI, 它是安装升级的底层库， 但是针对具体平台还需要我们去实现一个UA(Update Agent)，UA实现与设备的直接操作，我们需要把UPI集成到UA里面去。
在进行固件升级的时候， 有几个方面是需要注意的：
1. 使更新能够访问到UPI， 保证重启之后在系统层就能更新。
2. 不能更新调用更新模块的区域。 因为如果已经刚好擦除了调用更新模块的区域， 然后断电了， 再重启之后那段代码已经被擦除，就无法再继续更新。
3. 更新时进入Recovery模式， 无法连接到网络， 完成后需要重启， 正常进入手机系统后才能汇报更新结果。
UA在检测到固件更新的时候， 调用vCurrentMobileInstaller来具体操作。流程如下：
1. 在FLASH中找到差分包文件
2. 把差分包数据拷贝到RAM区域， 以便读写。
3. 读取RAM区域的差分包， 并且生成新的镜像块。
4. 把镜像块从RAM区拷贝到FLASH区域
5. 把FLASH中的镜像块覆盖设备固件中。
第三步和第四步重复执行， 直到整个固件差分包解析完。 其中我们需要注意的是为什么不直接把在RAM区生成的镜像块直接写到设备固件中去， 而要先缓冲在FLASH区域呢？ 这也是容错考虑。 万一更新过程中收到其他的影响（手机没电了）， 导致更新中断， 那么下次进来的时候就可以读取FLASH中之前更新的进度， 接着更新了。
我们要实现的时候， 需要去完成UA中的RB_ImageUpdate() , getUPIVersion(), getBlockSize()等方法。 这是主要的工作， 需要对底层操作有经验的人来完成。 这部分可以参考北研所之前的FOTA代码。 会对我们的进度有些帮助。
FOTA和DM的关系其实是依赖包含关系。 FOTA是负责附件更新的一个比较独立的组件； 而DM更偏向于应用层， 它有跟服务器交互的具体协议， 其中更新固件的部分调用FOTA来实现。
第二天上午介绍了DM中的FUMO, SCOMO, LAWMO协议和固件更新处理的过程。
FUMO是固件下载更新中需要遵循的协议， 和服务器交互的数据是个树形的结构， 包含了包名， Download/Update、DownloadAndUpdate命令, 对应的PKGUrl.
SCOMO是具体应用安装升级协议。 它包括Inventory和Download两部分。Inventory部分列出手机上安装的应用程序列表， 在每次DM需要进行升级软件的时候去收集手机上的应用程序列表。以便上报到服务器进行比对。Download用于标示那个应用需要去下载安装。
     LAWMO是手机锁屏的协议。包括锁定(PartiallyLock)， 解锁(UnLock) 和 恢复出厂设置(FactoryReset)。 比如我们在手机丢失的情况下， 可以致电中国移动申请锁定手机， 删除手机上的信息。 服务器发送这些命令到手机， 就可以完成这些操作。
DM中固件更新过程分为四个阶段
1. 发现阶段
2. 下载阶段
3. 升级阶段
4. 更新通知
每个过程都是与服务器使用命令进行通讯， GET, ALERT, REPLACE. 一方会对另一方的命令进行执行结果的回复。需要注意的是在下载中PKGUrl并不是需要下载的文件， 而是一个Download Descriptor文件， 其中描述了文件大小， 下载需要多久等信息， 给用户一个提示。用户确认后会根据DD文件里的实际文件地址去下载。