跨固件平台升级系统的研究_纪大峣.pdf

第 39 卷 第 7 期 福 建 电 脑 Vol.39 No.7 2023 年 7 月 Journal of Fujian Computer Jul.2023 纪大峣，1983年生，男，主要研究方向为嵌入式系统、操作系统、智能计算。E-mail:。跨固件平台升级系统的研究 纪大峣(瑞芯微电子股份有限公司研发部 福州 350003)摘 要 Android 固件平台的平台固件承载着 SoC 芯片原厂对固件平台的最新研究成果。如何在 Android 跨大版本升级时在保留用户数据的同时升级对应新版本 Android 固件平台的系统固件和平台固件是 Android 跨大版本升级的核心问题。此外如何避免端到端的定制开发，是解决设备厂商 Android 跨大版本升级困境的关键。为此，本文提出一种统一的跨固件平台升级系统，通过对 Android 固件平台的 Android 系统固件和平台固件进行统一的多平台兼容设计在一个固件平台上实现统一的跨固件平台升级系统，有效解决现有方法无法在保留用户数据的基础上同步升级对应新版本 Android 固件平台的平台固件问题和大量端到端定制开发导致的维护问题。实验结果验证了该方法能够在升级后保留用户数据并实现固件平台的完全升级，同时无缝支持将多个旧版本 Android 固件平台升级到新版本 Android 固件平台，已经在大规模设备上广泛应用。关键词 操作系统；固件平台；固件升级；Android 大版本升级 中图法分类号 TP393 DOI:10.16707/ki.fjpc.2023.07.007 A Unified Cross-Firmware Platform Upgrade System JI Dayao(Department of Research and Development,Rockchip Electronics Co.,Ltd,Fuzhou,China,350003)Abstract The platform firmware in the Android firmware platform carries the latest research results of the SoC vendor on the firmware platform,so how to upgrade the system firmware and platform firmware of the corresponding new version of the Android firmware platform on the basis of keeping user data when upgrading across major versions of Android is the core problem of Android cross-major version upgrade;In addition,how to avoid end-to-end custom development is the key to solving the dilemma of cross-major version upgrade of Android by device manufacturers.To this end,this paper proposes a Unified Cross-Firmware Platform Upgrade System,UCFPUS,which realizes a unified cross-firmware platform upgrade system on one firmware platform by carrying out a unified multi-platform compatible design of Android system firmware and platform firmware of the Android firmware platform,which effectively solves the maintenance problems caused by the existing methods that cannot synchronously upgrade the corresponding new version of the Android firmware platform on the basis of keeping user data.Experimental results verify that the proposed method can keep user data and achieve a complete upgrade of the firmware platform after the upgrade,and seamlessly supports the upgrade of multiple old versions of Android firmware platform to the new version of the Android firmware platform,which has been widely used in large-scale devices.Keywords Operating System;Firmware Platform;Firmware Upgrade;Android Major Version Upgrade 1 引言 Android 系统基本上每年都发布一个大版本1。当发布一个新的 Android 大版本时，SoC（System on Chip）芯片原厂都会基于新版本 Android 系统开发对应 SoC 芯片的新一代固件平台。新的固件平台除了基于新发布的 Android 大版本外，通常在平台的2023 年 福 建 电 脑 31 其他基础技术方面也会进行相应更新，将最新的研究成果和对平台的思考和重新设计在新平台上体现出来。这会不可避免地导致对应 SoC 芯片的新Android 固件平台与早期平台存在显著差异，如固件设计发生变化、分区表类型和分区设计不一致、用户数据分区的加密方式发生变化等。Android系 统 在 智 能 物 联 网（Artificial Intelligence of Things，AIoT）边缘设备中得到越来越广泛的应用2-5。同时，AIoT 边缘设备的生命周期越来越长。这就意味着很多已经出货的遗留设备存在强烈地从旧版本 Android 系统通过固件空中接口（Firmware-Over-The-Air，FOTA）升级到新版本的需求，从而能够无缝体验新版本 Android 系统的新特性。同时厂商通过承诺所售设备在其生命周期内能够通过 FOTA 无缝升级到后续新版本 Android系统，来提高产品对客户的吸引力6。现有的将旧版本 Android 系统升级到新版本的方法，为了能够保留设备中当前所有可读写用户数据分区里的数据，同时也为了能够与现有的Android FOTA 流程无缝兼容，通常只升级新版本Android固件平台中Android开放源码项目（Android Open Source Project，AOSP）代码所对应的系统固件6-7，即只关注 Android 版本本身的升级，而忽略新版本固件平台中的非系统固件（即平台固件）的升级。由于一个 SoC 芯片的新版本 Android 固件平台除了包括新版本 Android 系统固件外，更重要的是新的非系统固件的更新换代。SoC 芯片原厂通常会将对芯片固件平台的最新研究成果融入新版本Android 固件平台的非系统固件上。这就意味着此类方法在将旧版本 Android 升级到新版本后，无法享受到新版本 Android 固件平台中非系统固件更新所带来的新技术和新设计。同时该类 Android 大版本升级方法通常都是针对每一个特定的设备型号分别进行端到端的定制开发。具体来说，每一个设备型号，都需要针对某两个特定的 Android 大版本进行定制开发，以便将某一特定设备型号的某一特定旧 Android 系统版本升级到某一特定新 Android 系统版本6。这种定制通常不具有通用性，导致开发工作量大且固件代码管理复杂，需要针对特定型号和特定旧 Andriod 系统版本分别进行单独管理和维护。同时，当对应 SoC芯片的新固件平台发布时，其早期 Android 版本的固件平台通常都已经被用于开发大量的产品。而且这些早期版本不是一个版本，通常是好几个版本。当SoC芯片的生命周期越来越长时，其早期Android版本的固件平台会越来越多，导致端到端定制的工作量和维护量成倍增长，产生大量的定制固件平台变种。为了解决当前将旧版本 Android 系统升级到新版本时没有同步升级对应新版本 Android 固件平台的非系统固件，从而无法体验新固件平台引入的新技术成果问题，也为了解决 Android 跨大版本互升时端到端定制开发产生的大量不兼容变种固件平台代码导致的开发工作量大、固件代码管理复杂问题，本文设计和实现了一种统一的跨固件平台升级系统 UCFPUS（A Unified Cross Firmware Platform Update System）。采用 UCFPUS 后，在将旧版本Android 系统升级到新版本时，既能够保留当前设备中所有用户可读写分区中的用户数据，又能够将新版本 Android 固件平台中的系统固件和非系统固件同步升级，使得升级后的设备能够完全享受新固件平台中的各种新技术。UCFPUS 作为一个统一的跨固件平台升级系统，可以无缝集成到 SoC 芯片新版本 Android 固件平台，统一支持将多个旧版本Android 固件平台升级到新版本，有效解决设备厂商的 Android 大版本互升困境，提高产品吸引力和用户满意度。2 相关研究 现有的将旧版本 Android 系统升级到新版本的方法主要分为两大类：一类是固件平台的完全升级，另外一类是 Android 系统固件的升级。固件平台的完全升级指的是将包括分区表在内的所有固件全套更新。升级后的效果，相当于通过上位机烧录新版本 Android 固件平台的全套固件。由于新版本固件平台相对旧版本的分区表变化不可预测，因此此类方法需要处理分区表任意变更时的 FOTA 场景8-11。仅支持部分分区表变更的方法通常难以完全满足需求。与此同时，由于分区表的任意变更意味着设备中的可读写用户数据分区中的数据在 FOTA 升级后将无法直接保留，在该类方法中，新版本 Android 固件平台只需要一个通用的包括所有固件的固件升级包即可。多个旧版本Android 都可以使用同一个固件升级包来将设备FOTA 升级到新版本 Android 固件平台8-11。例如某一厂商基于某一 SoC 芯片的 Android 9 固件平台、Android 10 固件平台和 Android 11 固件平台分别开32 纪大峣：跨固件平台升级系统的研究 第 7 期 发了相同硬件的设备，当该 SoC 芯片的 Android 12固件平台发布后，如果要将分别搭载 Android 9、Android 10 和 Android 11 固件的遗留设备全部升级到 Android 12 固件平台，只需要制作一个包含Android 12 固件分区表在内的固件升级包，然后将该固件升级包分别推送到对应的搭载 Android 9、Android 10 和 Android 11 固件的遗留设备来实现将对应旧版本 Android 固件平台 FOTA 的升级。但是此类方法通常需要依赖外置存储介质（如 U 盘），并且升级后无法直接保留可读写用户数据分区里的数据8-9。而很多设备部署时并没有标配外置存储。有些方法虽然不需要依赖外置存储，但是对应方法的复杂度高且通常无法直接保留用户分区数据，需要用户干预进行备份和恢复10-11。在很多场景，用户希望在升级到新版本 Android 系统固件平台时，能够自动保留已有的用户分区数据不变。此外，该类方法通常需要对搭载旧版本 Android 固件的升级流程进行修改8-11，无法与现有的 Android常规 FOTA 流程无缝兼容。Android 系统固件的升级指的是当将一个搭载旧版本 Android 的固件 FOTA 升级到新版本时，只将新版本 Android 本身升级到设备上，即只将新版本 Android 固件平台中的 Android 系统固件升级到设备上6-7,12-13，而不是将整个新版本 Android 固件平台的全部固件升级到设备上。一个 SoC 芯片的Android 固件平台包括系统固件和非系统固件。SoC芯片 Android 固件平台的系统固件指的是 AOSP 或者定制化 AOSP 所编译出来的构成 Android 操作系统本身的固件，如 system 固件、vendor 固件、odm固件或者 super 固件。这些 Android 系统固件在设备的启动顺序上位于启动引导程序固件之后，且由boot 固件引导。Android 系统固件通常包括 boot 固件和 recovery 固件。SoC 芯片 Android 固件平台的非系统固件指的是除系统固件之外的其他固件，也称为平台固件，是 SoC 芯片原厂为对应 SoC 芯片开发设计的平台固件，通常与 SoC 芯片本身强相关。一个 SoC 芯片 Android 固件平台的非系统固件通常包括各个级别的启动引导程序固件、ARM 安全固件（ARM Trusted Firmware，ATF）、可信操作系统（Trusted Operting System，TOS）固件、虚拟机固件、基带固件等。这类固件在启动顺序上通常位于系统固件之前。采用此类方法将旧版本Android 升级到新版本时，只将新版本 Android 固件平台中的系统固件升级到设备上6-7,12-13，即 Google所说的对遗留设备的改造升级14。此类方法通常能够在 FOTA 升级后保留用户可读写分区中的数据，并且能够与现有的 Android FOTA 升级流程兼容。但是由于此类方法通常不同步 FOTA升级对应新版本 Android 固件平台的非系统固件，因此采用此类固件升级方法将旧版本 Android 升级到新版本后，无法享受到新版本 Android 固件平台中非系统固件更新所带来的新技术和新设计。而 SoC 芯片原厂通常会将对芯片固件平台的最新研究成果融入新版本 Android 固件平台的非系统固件上。此外，基于 Android 系统固件的升级方法，通常需要针对每一款特定设备的任意两个 Android 大版本之间进行端到端的定制开发。也就是说，需要每一款设备，分别针对某一特定旧版本 Android 系统到某一新版本 Android 系统的 FOTA 升级进行定制开发6。每一个端到端的定制开发意味着需要针对每一款或每一不同类型的设备对新版本 Android系统打一系列定制补丁形成一个定制的新版本Android 平台。设备厂商通常都依赖 SoC 芯片原厂提供方案将旧版本 Android 升级到新版本 A 12-13。由于每一款 SoC 芯片都被不同厂商用于开发各种不同类型的设备，因此这种定制开发对 SoC 芯片原厂带来的挑战不堪重负。随着 SoC 芯片的生命周期越来越长，再加上每年一个 Android 大版本的发布，将意味着 SoC 芯片原厂每年都需要针对主要 SoC芯片固件平台发布新版本 Android 固件平台。随着越来越多新版本 Android 固件平台的发布，即便是支持有限的几个旧版本到新版本的升级，这种定制开发也会给 SoC 芯片原厂带来大量的开发和维护工作量。例如 RK3288 这款 SoC 芯片在 2014 年发布15，从 RK3288 Android 5.0 固件平台、RK3288 5.1固件平台到 2022 年的 RK3288 Android 12 固件平台，中间存在着九个对应的不同 Android 固件平台；RK3399这款SoC芯片在2016年发布16，从RK3399 Android 6.0 固件平台到 RK3399 Android 12 固件平台，中间就存在着七个对应的不同 Android 固件平台。这两款 SoC 芯片从发布至今都被广泛应用于各类 AIoT 边缘设备，其每一个 Android 版本固件平台都被广泛使用。这就意味着即使只支持最近几个旧版本 Android 固件平台升级到新版本，这种定制开发也会给 SoC 芯片原厂带来繁杂的开发工作量和维护困境。3 UCFPUS 概述 2023 年 福 建 电 脑 33 统一的 Android 大版本跨固件平台升级系统UCFPUS既解决了固件平台的完全升级方法所导致的设备中的可读写用户数据分区中的数据在 FOTA升级后无法保留的问题和无法与现有的 Android 常规 FOTA 流程兼容的问题，又解决了 Android 系统固件的升级方法没有同步升级对应新版本 Android固件平台的非系统固件问题，使得用户可以体验到新固件平台引入的新固件设计技术，还解决了端到端定制开发引起的开发和维护困境。UCFPUS 跨固件平台升级系统的架构如图 1 所示。它由四个部分共同构成：固件分区表布局与分区类型、块设备节点映射、文件系统表与分区映射和用户数据区文件系统类型与加密方式。“固件分区表布局与分区类型”通过同时支持分区表描述文件静态配置机制和分区表描述文件动态生成机制来实现在一个统一的固件平台上同时兼容多种不同的固件分区表。“块设备节点映射”通过统一的块设备节点映射来实现将相同的物理分区映射到相同的块设备节点路径，从而为实现在一个统一的固件平台上同时兼容多种 Android 固件平台的升级提供针对块设备的统一访问方式。“文件系统表与分区映射”通过 Android 系统文件系统表（File System Table，fstab）动态生成机制和 recovery fstab静态配置机制来实现在一个统一的固件平台上同时兼容多种不同的文件系统表。“用户数据区文件系统类型与加密方式”在兼容各个不同 Android 版本固件平台的文件系统表的基础上，在一个统一的固件平台上支持对用户数据区配置不同的文件系统类型和不同的加密方式。UCFPUS固件分区表布局与分区类型 块设备节点映射文件系统表与分区映射用户数据区文件系统类型与加密方式图 1 UCFPUS 架构框图 4 UCFPUS 的设计与实现 4.1 固件分区表布局与分区类型 Android 操作系统的 SoC 芯片固件平台通常采用全局唯一标识分区表（GUID Partition Table，GPT）作为固件分区表的类型17。设备在上电启动引导过程中根据固件分区表所指明的分区起始地址和长度来加载各种不同类型的固件，进而完成设备的启动引导。一个 SoC 芯片 Android 固件平台的固件分区表通常包括两种类型的分区，一类是固件分区，一类是可读写用户数据分区。其中固件分区存储一个SoC 芯片固件平台中的各种不同类型的固件，包括Android 系统固件和非系统固件；可读写用户数据分区用于存储系统运行过程中临时可读写数据和终端用户的可读写数据，在一个设备出厂时可读写用户数据分区通常是空的。固件分区中的非系统固件，取决于不同 SoC 芯片固件平台的设计；而Android 系统固件则随着 Android 大版本的不同而有所不同，具体如表 1 和表 2 所示。表 1 描述了Android 非 A/B 系统不同 Android 大版本的主要系统固件分区，表 2 描述了 Android A/B 系统不同Android 大 版 本 的 主 要 系 统 固 件 分 区，其 中“=Android 10”表示大于等于 Android 10。表 1 非 A/B 时不同 Android 版本主要系统固件分区=Android 10 boot recovery system boot recovery system vendor boot recovery system vendor boot recovery super 表 2 A/B 时不同 Android 版本主要系统固件分区=Android 10 boot_a boot_b system_a system_b boot_a boot_b system_a system_b vendor_a vendor_b boot_a boot_b system_a system_b vendor_a vendor_b boot_a boot_b super 不同 Android 版本固件平台的固件分区表往往不一致。该组成部分通过同时支持分区表描述文件静态配置机制和分区表描述文件动态生成机制来实现在一个统一的固件平台上同时兼容多种不同的固件分区表。分区表描述文件是一个定义分区表布局的文本文件，描述了每一个物理分区的名字、起始地址和长度。分区表描述文件静态配置机制指的是通过定义分区表路径静态配置项来直接指定具体的分区表描述文件。当需要创建或者修改分区表描述文件时，直接创建或者修改符合预设格式要求的文本文34 纪大峣：跨固件平台升级系统的研究 第 7 期 件。分区表描述文件动态生成机制指的是通过一组配置项来分别配置分区列表布局以及各个分区大小，编译时通过解析该组配置项来动态生成分区表描述文件。当需要创建和修改分区表描述文件时，只要修改对应的分区表布局配置项和各个分区大小配置项，然后重新编译即可。该组成部分通过动态兼容分区表描述文件的动态生成机制和静态配置机制来满足不同用户的需求，实现原理如图 2 所示。图 2 中的“将文本形式的分区表描述文件转换为二进制格式的分区表镜像”这一步通常在上位机烧录固件的过程中通过烧录工具来转换，并在转换后写入设备存储介质中分区表所在的地址空间。分区表路径静态配置项是否为空使用该配置项指定的分区表描述文件，并解析该分区表描述文件来获取并配置所有Android系统分区的大小根据预先配置的分区表布局配置项和各个分区大小配置项来自动生成分区表描述文件配置分区表布局配置项和各个分区大小配置项将文本形式的分区表描述文件转换为二进制格式的分区表镜像否是 图 2 固件分区表生成原理 4.2 块设备节点映射 该组成部分通过统一的块设备节点映射来实现将相同的物理分区映射到相同的块设备节点路径，即将不同 Android 固件平台中名字相同的物理分区都映射到相同的块设备节点路径，从而为实现在一个统一的固件平台上同时兼容多种 Android 固件平台的升级提供针对块设备的统一访问方式。通过为块设备节点提供统一的访问方式，从而在Android 跨大版本升级时能够将相同的固件无缝写入设备存储介质的对应固件分区。具体来说，在Android 系统的 init 服务中，针对上报的每一个块设备事件，根据对应的分区名创建统一的符号链接到/dev/block/by-name/。例如物理分区 boot 被统一映射到符号链接/dev/block/by-name/boot。4.3 文件系统表与分区映射 文件系统表包括 Android 系统 fstab 和 recovery fstab 两种类型。文件系统表主要由 Android 版本和固件分区表来共同决定。这意味着不同 Android 版本固件平台的文件系统表通常差异很大。特别是 Android 系统fstab 的配置还取决于是否开启动态分区、是否开启A/B 系统、是否开启 Android 启动时验证（Android Verified Boot，AVB）等18-20。该组成部分通过Android系统fstab动态生成机制和recovery fstab静态配置机制来实现在一个统一的固件平台上同时兼容多种不同的文件系统表。其中，recovery fstab静态配置机制指的是通过定义 recovery fstab 静态配置项来直接指定具体的 recovery fstab。Android 系统 fstab 动态生成机制指的是通过fstab 模板文件配置项、块设备前缀配置项和文件系统管理器标记配置项来动态生成 Android 系统fstab，实现原理如图 3 所示。是否开启动态分区逻辑分区映射到物理分区，设置块设备前缀配置项为/dev/block/by-name/针对动态分区组中的所有逻辑分区，设置块设备前缀配置项为空否是根据A/B系统开关标记和Android启动时验证开关标记来设置对应的文件系统管理器标记配置项定义fstab模板文件设置fstab模板文件配置项为对应配置好的fstab模板文件根据块设备前缀配置项和文件系统管理器标记配置项来将fstab模板文件配置项所指定的fstab模板文件转换为Android系统fstab 图 3 Android 系统 fstab 生成原理 2023 年 福 建 电 脑 35 4.4 用户数据区文件系统类型与加密方式 不同 Android 版本固件平台的用户数据区所对应的文件系统类型与加密方式可能不一致。特别是用户数据区加密方式，不同 Android 版本之间可能存在很大差异。例如在 Android 10 之前，各种不同的 Android 固件平台通常采用全盘加密的方式21，而从Android 10开始不允许在新设备上使用全盘加密并且 AOSP 持续减少对全盘加密的支持21，而是统一采用文件级加密22。该组成部分在兼容各个不同 Android 版本固件平台的文件系统表的基础上，在一个统一的固件平台上支持对用户数据区配置不同的文件系统类型和不同的加密方式。具体来说，在新版本 Android固件平台的非系统固件中同时兼容多种旧版本Android 固件平台的加密方式，即在新版本 Android固件平台的可信操作系统固件和对应的可信应用（Trusted Application，TA）中同时实现多种加密方式并实现动态兼容。4.5 设计与实现原理 UCFPUS 通过对 Android 固件平台的 Android系统固件和非系统固件进行统一的多平台兼容设计来实现在一个固件平台上实现统一的跨固件平台升级系统。对于非系统固件来说，通过对新版本 Android固件平台中包括各个级别的启动引导程序固件、ARM 安全固件和可信操作系统固件等所有非系统固件进行融合设计，全链条实现对旧平台固件旧特性的支持以及旧平台与新平台冲突特性的调和机制来实现新版本 Android 固件平台的非系统固件无缝支持多种不同的固件分区表，使得新版本Android 固件平台的非系统固件可以在不同的分区布局下工作。对于旧固件平台拥有但新固件平台没有的非系统固件分区，新版本固件平台通过直接不使用对应的非系统固件分区来实现；而对于旧固件平台没有但新固件平台新增的非系统固件分区，则通过允许将新增的非系统固件分区对应的非系统固件融合到旧固件平台存在的非系统固件分区，在引导时从对应的非系统固件分区读出融合固件来加载，实现新固件平台增加新分区时新平台的非系统固件不需要访问新分区也能正常工作，实现对多种不同固件分区表的支持。对于 Android 系统固件来说，UCFPUS 通过Android 的 lunch 机制来支持不同 Android 版本固件平台的无缝升级23。每个旧版本 Android 在新版本固件平台上建立一个对应的 lunch，如在 Android 12固件平台上为了支持将旧版本 Android 11 升级到Android 12，则建立一个 Android_11 的 lunch 来实现。UCFPUS 根据不同 Android 版本固件平台所对应的不同分区布局将 Android 系统固件编译成不同类型和数目的系统固件镜像。针对不支持动态分区的旧 Android 固件平台，当要将该旧版本固件平台升级到新版本固件平台时，通过在该旧版本Android所对应的lunch配置文件中关闭动态分区镜像的生成机制来实现。当新 Android 固件平台新增分区用于存储对应的 Android 系统固件，但是对应的旧版本 Android 平台固件分区表中不存在对应的系统固件分区时，通过在新 Android 固件平台上将新增分区所对应的系统固件融合到对应旧版本Android 固件平台存在的系统固件分区来实现对多种不同固件分区表的无缝支持。例如新 Android 固件平台支持 vendor 系统固件，但是某一旧版本Android 固件平台的固件分区表只支持 system 分区，没有 vendor 分区，此时可以在新 Android 固件平台上同时将 system 系统固件和 vendor 系统固件编译在统一的 sysem 固件中，实现将 vendor 固件融合到 system 固件。基于上述非系统固件和 Android 系统固件的设计与实现原理，在一个新版本 Android 固件平台上实现对某一旧版本 Android 固件平台支持的过程就是添加一个对应 lunch 并进行配置的过程，具体步骤如下：（1）构建一个与对应旧版本 Android 固件平台相同的固件分区表。根据需要选择分区表描述文件静态配置机制或者分区表描述文件动态生成机制。如果选择静态配置机制，则将分区表路径静态配置项指向具体的分区表描述文件所在的路径；如果选择动态生成机制，则根据旧版本 Android 固件平台的固件分区表布局对分区表布局配置项和各个分区大小配置项进行配置。（2）构建一个与对应旧版本 Android 固件平台兼容的 recovery fstab。可读写用户数据分区所对应的文件系统类型需与对应旧版本 Android 固件平台对应分区的文件系统类型一致。（3）构建一个与对应旧版本 Android 固件平台兼容的 Android 系统 fstab。首先设计与对应旧版本Android 固件平台兼容的 fstab 模板文件，然后通过Android 系统 fstab 动态生成机制来生成对应的兼容36 纪大峣：跨固件平台升级系统的研究 第 7 期 Android 系统 fstab。对于可读写用户数据分区所对应的文件系统类型和加密方式，需与对应旧版本Android 固件平台对应分区的配置项保持一致。5 实验结果与分析 5.1 实验环境说明 本文在 RK3399 这款 AIoT 芯片的 Android 12固件平台上实现了 UCFPUS 跨固件平台升级系统。RK3399是 一 款 由 双 核Cortex-A72和 四 核Cortex-A53 构成的六核 SoC 芯片24。本实验的硬件平台采用 RK3399 开发板，如图 4 所示。图 4 RK3399 开发板 本实验的固件环境见表 3。表 3 中的“基础固件平台”指的是实现 UCFPUS 跨固件平台升级系统的 Android 固件平台，“跨版本实验固件平台”指的是“5.2 实验过程”中所需要使用到的旧 Android版本固件平台。表 3 固件实验环境 基础固件平台 跨版本实验固件平台 RK3399_ANDROID12.0_SDK RK3399_ANDROID9.0_SDK RK3399_ANDROID10.0_SDK RK3399_ANDROID11.0_SDK 5.2 实验过程 在 RK3399 Android 12 固件平台上设计与实现UCFPUS 跨固件平台升级系统，成功地将搭载RK3399 Android 9、RK3399 Android 10 和 RK3399 Android 11 这三个大版本 Android 固件平台的RK3399 开发板通过 FOTA 对应地升级到 RK3399 Android 12 固件平台。具体如下：（1）在 RK3399_ANDROID12.0_SDK 实现了通过 FOTA 将 RK3399 固件平台从 Android 9 固件平台升级到 Android 12 固件平台、从 Android 10 固件平台升级到 Android 12 固件平台以及从 Android 11 固件平台升级到 Android 12 固件平台。实验结果如表 4 和表 5 所示。表 4 RK3399 跨固件平台互升实验结果_用户数据 互升版本 lunch 项 data 区数据是否保留 Android 9 到 Android 12 rk3399_mid 是 Android 10 到 Android 12 rk3399_Android10 是 Android 11 到 Android 12 rk3399_Android11 是 表 5 RK3399 跨固件平台互升实验结果_固件 互升版本 Android 系统固件是否升级 非系统固件是否升级 Android 9 到 Android 12 是 是 Android 10 到 Android 12 是 是 Android 11 到 Android 12 是 是 （2）以 RK3399 开发板从 Android 9 升级到Android 12 为例来说明完整的实验过程。首先在 RK3399 Android 9 固件平台（即RK3399_ANDROID9.0_SDK）上编译 RK3399 9.0固件，并将对应全套固件烧录到 RK3399 开发板中。此时 RK3399 开发板中搭载的是 Android 9.0 固件，如图 5 所示。然后在用户分区 data 下新建一个文件jdy_test_9，文件内容为jdy_test_9_to_12_ OTA，具体如图 6 所示。图 5 RK3399 开发板 Android 9 固件信息 2023 年 福 建 电 脑 37 图 6 RK3399 开发板 Android 9 固件版本与 data 信息 接着在 RK3399 Android 12 固件平台（即RK3399_ANDROID12.0_SDK）的非系统固件中添加特殊的打印信息，同时在 RK3399 Android 12 固件平台上选择 Android 9 固件平台升级到 Android 12固 件 平 台 的 对 应lunch项（lunch rk3399_mid-userdebug）。然后编译对应的Android 12固件平台完整升级包，将对应的完整升级包推送到 RK3399 开发板上，触发正常的 FOTA 升级流程。升级完成后，通过启动过程中的串口信息查看非系统固件的打印信息，确认RK3399开发板中运行的是RK3399 Android 12固件平台中的非系统固件。同时进入系统查看，发现RK3399开发板中的固件已经顺利地从Android 9固件平台升级到 Android 12 固件平台。具体信息见图 7 和图 8。图 7 RK3399 开发板 Android 12 固件信息 图 8 RK3399 开发板 Android 12 固件 data 信息 从图 7 可以看出，RK3399 开发板已经顺利地从Android 9 固件平台升级到 Android 12 固件平台。图7 中的 Android version 为 12。从图 8 可以发现，data区下的文件 jdy_test_9 在 Android 12 平台上得到了保留，并且文件内容与 Android 9 固件平台下的对应文件一致。5.3 实验结果分析 通过表 4 和表 5 可以发现，统一跨固件平台升级系统UCFPUS能够在FOTA升级后保留可读写用户数据分区里的数据，并实现包括 Android 系统固件和非系统固件在内的固件平台的完全升级，有效解决了在确保待升级设备中的用户可读写分区中的数据在升级后保持不变这一关键产品需求的前提下同时升级新版本 Android 固件平台的系统固件和非系统固件，实现了固件平台的完全升级，使得FOTA升级后的设备既拥有新版本的Android系统，又能够享受 SoC 原厂新一代固件平台所带来的新固件技术和体验。通过“5.2 实验过程”可以证明，UCFPUS 作为一个统一的跨固件平台升级系统能够无缝支持将多个旧版本 Android 固件平台升级到新版本An