CN110781528A - 协同安全操作系统架构、操作系统和电子设备 - Google Patents

Abstract

协同安全操作系统架构、操作系统和电子设备，涉及计算机软件、操作系统、电子设备和信息安全技术领域。在电子设备内部，为地址空间相互独立的两个处理器分布配置双操作系统并行，经封闭协议通道交换数据消息；第一操作系统安全等级更高控制驱动敏感外围设备，并提供可控驱动代理；第二操作系统控制驱动非敏感外围设备，又受控驱动转移共享敏感外围设备；第一操作系统管控驱动共享策略，屏蔽/开放驱动转移委托；对协同分布应用实行协同联动管理，包括协同联动安装/卸载、运行/终止机制。实施例搭配鸿蒙和安卓操作系统，折叠屏手机分立私密空间和开放空间，能显著增强设备系统安全，避免用户信息泄露，利于兼容培育应用生态，提升设备系统价值。

Description

协同安全操作系统架构、操作系统和电子设备

技术领域

本发明涉及计算机软件、操作系统、电子设备和信息安全技术领域。

背景技术

电子设备，典型的如终端和服务器，终端的实例如个人电脑、笔记本电脑、平板电脑、智能电视、移动电话(手机)和穿戴设备等，其信息安全的核心关键，有赖于操作系统安全。流行操作系统由于追求通用性和开放性，难免给应用留下安全隐患，电脑病毒、间谍程序和黑客为害时有发生。而非自主操作系统的复杂性、隐蔽性和更新随意性，也严重构成潜在安全风险。为了解决电子设备的信息安全问题，现有技术方案的一类是通过硬件和系统的冗余来解决，典型的是采用双系统的办法。“信息安全电子设备和应用架构”(专利申请号CN201510413949.9)提出，常规模式和安全模式并行共享输入输出部件，内部受控于安全模式的电子切换机构通过对关键信号线组同步实施电路选择，来控制切换目标输入输出部件排它连通两种模式之一。“通信信息的处理方法及移动终端”(专利申请号CN201611241253.3)提出，第一、第二操作系统分别与第一、第二SIM卡绑定，接收判断第一通信信息与哪张SIM卡对应而交由对应的操作系统显示处理。“一种双卡双系统终端及其来电处理方法和装置”(专利申请号CN201510419172.7)提出，第一、第二操作系统分别接收到第一、第二SIM卡来电时触发事件通知交互，根据预设显示方式将显示屏分为两区域显示两来电界面，不涉及数据共享而可在同时处理两个来电时确保系统间数据安全。“一种双系统一体化智能手机及私密信息的处理方法”(专利申请号CN201610290850.9)提出，开放系统通过网络通信模块与外界进行数据通信，又通过安全模块与私密系统连接，切换模块同时与开放系统、私密系统以及显示单元相互连接，以提高手机系统的安全性。“基于双系统切换的数据安全处理方法及装置”(专利申请号CN201410817232)提出，在第一操作系统下监测终端待执行操作事件，判断是否存在预设安全属性信息，当存在时则将当前第一操作系统切换为第二操作系统，并在第二操作系统下执行操作事件，防止用户隐私数据泄露。“一种移动终端及其在双系统下访问数据的方法和装置”(专利申请号CN201410369962.4)提出，接收到当前操作系统中应用程序共享指令时，将应用程序共享给第二操作系统；检测到当前操作系统从第一操作系统变更为第二操作系统时，切换到第二操作系统；接收到共享应用程序启动指令时，启动对应的应用程序；接收到应用程序访问数据指令时，提取第一和第二操作系统的数据，使得双系统数据的访问更安全。“移动终端及其实现双系统的方法”(专利申请号CN201310382336.4)提出，第一系统用于私密应用运行管理，第二系统用于非私密应用运行管理；第一系统应用虚拟机将私密应用虚拟为第二系统应用，由第二系统的应用加载器调用管理私密应用；硬件虚拟机在移动终端物理硬件层分别为第一和第二系统模拟独立硬件资源访问控制，提高用户数据安全性。“一种支持无缝切换的双系统终端”(专利申请号CN201310342622.8)提出，非智能子系统和智能子系统硬件独立，通过硬件开关键完成切换，共享无线射频模块、屏幕、语音及相关I/O接口设备，非智能子系统始终保持运行，用于安全通话和短信通信，提供安全通信环境保护用户隐私。“一种双系统移动终端的启动方法以及移动终端”(专利申请号CN201710432406.0)提出，对应第一系统的第一单板和对应第二系统的第二单板，分别与母板单独连接，各外围器件分别与母板连接，包含系统模式开关，母板检测开机操作触发系统模式开关对应的系统开机，将外围器件控制通路切换至系统完成初始化，硬件完全隔离分别独立支持不同操作系统，保证硬件稳定和系统安全。“跨环境通信框架”(专利申请号CN201180057951.7)提出，在无虚拟化共享内核上并发独立运行移动操作系统和桌面操作系统的移动设备，对接到第二终端环境时，桌面操作系统提供完整桌面用户体验，其应用通过跨环境通信框架与移动操作系统的应用和服务通信，包括允许两操作系统中的进程以线程安全方式共享存储器到远程对象的接口。“二元协同安全客户端架构”(专利申请号CN201910255296.4)提出，应用客户端分布为二元结构通用安装的私密端和开放端，并发运行于第一和第二终端，构成用户私密和开放空间，两端建立近程信赖通道施行保密镜像与透明镜像，协同应用逻辑状态转换同步与联动互操作，避免信息泄露。

电子设备采用双操作系统并行，在两个操作系统之间存在两个关键问题：一是对外围设备的协同驱动共享，二是对协同分布应用的协同联动管理。现有技术对第一个问题，倾向采用切换控制办法，系统复杂、不灵活成本也高；对第二个问题，亦未顾及优化用户体验。

发明内容

本发明的目的，是解决电子设备内部在双操作系统架构下，对外围设备的协同驱动共享和对协同分布应用的协同联动管理这两个问题，进而改进操作系统和电子设备。

为了解决对外围设备的协同驱动共享这第一个问题，本发明提出一种协同安全操作系统架构，在同一电子设备内部，为地址空间各自独立的第一处理器与内存储器和第二处理器与内存储器，分布配置第一操作系统和第二操作系统并行运行，赋予第一操作系统比第二操作系统更高安全等级或安全预期，两个操作系统相互之间通过基于电路信号封闭连接的协议通道交换数据消息，对外围设备按敏感性区分而实行协同驱动共享，第一操作系统控制驱动敏感外围设备，第二操作系统控制驱动非敏感外围设备，其特征在于，所述协同驱动共享包括对于敏感外围设备的下列控制机制：

可控驱动代理：第一操作系统基于其设备驱动程序，通过所述协议通道，自控地向第二操作系统提供驱动代理，受理第二操作系统的驱动转移委托；

受控驱动转移：第二操作系统的设备驱动程序和/或功能接口程序，通过所述协议通道，受控地转移委托第一操作系统代理驱动而实现间接控制共享；

共享策略控制：第一操作系统管控驱动共享策略，用以操控所述可控驱动代理，屏蔽或开放所述第二操作系统的驱动转移委托。

上述协同安全操作系统架构的硬件构成基础，是具备第一处理器与内存储器作为第一处理系统和第二处理器与内存储器作为第二处理系统，两个处理系统的访问地址空间相互独立隔离，分别各配置一个操作系统分布并行运行。两个操作系统可以是同构(相同体系结构、品牌)的，也可以是异构(不同体系结构、品牌)的。尽量采用本国厂商出品的操作系统作为第一操作系统，安全性值得信赖；又可采用他国厂商出品的操作系统作为第二操作系统，安全性值得警惕。选用操作系统的一般考虑是，第一操作系统注重安全自主性，第二操作系统注重通用开放性，从而兼顾安全自主可控和应用生态普适。所述基于电路信号封闭连接的协议通道，其硬件基础可以是局部共享内存(如双端口存储器)、直连数据总线(如高速USB)等，是电路上的数字信号(或光脉冲信号)直连的，不采用开放的射频信号是为了抗干扰和防止电磁泄露；软件层面上再规范数据结构和通信协议，用于在第一操作系统与第二操作系统之间传输交换数据消息。将外围设备区分为敏感设备和非敏感设备的基本考虑，是用户信息泄露的潜在风险，即可能被第二操作系统及其应用泄露的风险。因此，可能被截屏、偷窥、侦听、盗录、定位等的外围设备，应归为敏感外围设备，其它可归为非敏感外围设备。网络、通信(3G/4G/5G等)比较特殊，从信息安全考虑是敏感的，但接入第一操作系统会带来攻击风险，故宜交由第二操作系统控制驱动，而归为非敏感外围设备，而且应避免让第一操作系统共享之。第一操作系统直接控制驱动敏感外围设备，而通过可控驱动共享代理服务于第二操作系统，既能保证第二操作系统通过驱动转移委托正常访问敏感外围设备，又能有效管控敏感外围设备避免被第二操作系统及其应用泄露数据。第二操作系统直接控制驱动非敏感外围设备，也可通过驱动共享代理服务于第一操作系统，能保证第一操作系统通过驱动转移委托正常访问非敏感外围设备。因为非敏感，第二操作系统的驱动共享代理就无须强调是可控的，当然可控也是一种选项，如果需要第二操作系统对第一操作系统通过委托进行的访问而加以管控的话。所谓自控地提供驱动代理，是指自主控制提供驱动代理，而无需委托方身份认证。所述驱动代理与所述驱动转移委托的服务关系，用于保障第一操作系统和第二操作系统对外围设备的协同驱动共享。就需要规范和适配在设备驱动层和/或功能接口层的交换数据参数格式，转换分发外围设备相关数据消息并传入传出。尤其当两个操作系统为异构情况下，适配和转换更有必要。所述驱动共享代理的可控性需要策略化，而且交由第一操作系统管控驱动共享策略，屏蔽则阻止服务，开放则正常服务。

上述协同安全操作系统架构，进一步特别安排显示共享，其特征是，所述可控驱动代理和受控驱动转移适用显示屏，允许通过外部操作随时调整第一操作系统与第二操作系统同屏显示桌面区域的布局和相对大小，而所述可控驱动代理则将所述受控驱动转移的第二操作系统截屏操作，获取图像范围限制于第二操作系统显示桌面区域。第一操作系统与第二操作系统同屏显示，有两个操作系统桌面，布局可以是左右、上下、叠加，通过手动拖曳(触摸屏、键盘鼠标)或特定功能键操作可随时调整桌面区域布局和相对大小。限制第二操作系统的截屏获取的图像范围，是为了避免第一操作系统上的桌面和应用窗口信息内容，可能被第二操作系统及其应用所获取泄露。

上述协同安全操作系统架构，进一步安排外存储器共享，其特征是，所述可控驱动代理和受控驱动转移适用外存储器，所述可控驱动代理将第一操作系统的外存储器中部分区域，虚拟共享为第二操作系统的外存储器，导致第二操作系统对外存储器的访问被映射且限制于该部分区域。有别于内存储器是程序运行的存储器，外存储器是文件系统的存储器，包括用于存储操作系统文件。虚拟共享能减少外存储器芯片或其它存储设备，降低电路复杂性，从而节省产品成本。

上述协同安全操作系统架构，进一步关注通话和音像安全，其特征是，所述可控驱动代理和受控驱动转移适用摄像头、麦克风和扬声器，当第一操作系统进行通话或拍录/播放音像时，所述可控驱动代理自动屏蔽第二操作系统对相关外围设备的驱动转移委托。通话包括语音通话、视频通话，音像包括声音、图像、影像，信息都面临潜在安全隐患，例如，摄像头可能被控制利用于偷拍照、偷录像，麦克风可能被控制利用于窃听，扬声器可能被控制拦截播放音频数据流而偷录，都可能被第二操作系统及其应用所泄露。所以，有必要将这三样设备归为敏感外围设备而置于第一操作系统直接控制之下，自动屏蔽是有效的安全保障。还可以在第一操作系统或其上应用的管理界面，通过设置所述驱动共享策略，来屏蔽第一操作系统的可控驱动共享代理向第二操作系统的驱动转移委托服务，从而能够根据用户需要在敏感的场景、时间和地点，切断第二操作系统及其应用对敏感外围设备的访问控制。

上述协同安全操作系统架构，进一步考虑敏感外围设备的共享使用优先顺序，其特征是，所述可控驱动代理自行避让第一操作系统所引发的控制驱动，保证第一操作系统的应用比第二操作系统的应用在共享使用敏感外围设备时享有优先权。如此优先权安排，使得当第一操作系统的应用在使用敏感外围设备期间，确保切断第二操作系统及其应用的共享访问，避免敏感设备信息被第二操作系统及其应用所泄露。

为了解决对协同分布应用的协同联动管理这第二个问题，本发明提出一种协同安全操作系统架构，在同一电子设备内部，为地址空间各自独立的第一处理器与内存储器和第二处理器与内存储器，分布配置第一操作系统和第二操作系统并行运行，赋予第一操作系统比第二操作系统更高安全等级或安全预期，两个操作系统相互之间通过基于电路信号封闭连接的协议通道交换数据消息，对协同分布应用实行协同联动管理，其特征在于，所述协同联动管理包括下列协同联动机制中的至少一个方面：

协同联动安装：第一操作系统发起安装协同分布应用文件时，从中区分第一应用文件和第二应用文件，将第一应用文件安装于第一操作系统存储区，通过所述协议通道向第二操作系统发出安装消息并传送第二应用文件，触发第二操作系统响应安装消息接收第二应用文件而安装于第二操作系统存储区并将安装结果反馈第一操作系统；和/或，第二操作系统发起安装协同分布应用文件时，从中区分第一应用文件和第二应用文件，将第二应用文件安装于第二操作系统存储区，通过所述协议通道向第一操作系统发出安装消息并传送第一应用文件，触发第一操作系统响应安装消息接收第一应用文件而安装于第一操作系统存储区并将安装结果反馈第二操作系统；第一操作系统记录已安装的第一应用文件与第二应用文件之间的关联对应；

协同联动卸载：第一操作系统发起卸载第一应用文件时，从第一操作系统存储区卸载第一应用文件，通过所述协议通道向第二操作系统发出卸载消息，触发第二操作系统响应卸载消息而从第二操作系统存储区卸载对应的第二应用文件并将卸载结果反馈第一操作系统；和/或，第二操作系统发起卸载第二应用文件时，从第二操作系统存储区卸载第二应用文件，通过所述协议通道向第一操作系统发出卸载消息，触发第一操作系统响应卸载消息而从第一操作系统存储区卸载对应的第一应用文件并将卸载结果反馈第二操作系统；第一操作系统消除已卸载的第一应用文件与第二应用文件之间的关联对应记录；

协同联动运行：第一操作系统发起加载第一应用文件运行为第一应用进程时，通过所述协议通道向第二操作系统发出运行消息，触发第二操作系统响应运行消息而加载关联对应的第二应用文件运行为第二应用进程；和/或，第二操作系统发起加载第二应用文件运行为第二应用进程时，通过所述协议通道向第一操作系统发出运行消息，触发第一操作系统响应运行消息而加载关联对应的第一应用文件运行为第一应用进程；

协同联动终止：第一操作系统发起终止第一应用进程时，通过所述协议通道向第二操作系统发出终止消息，触发第二操作系统响应终止消息而终止关联对应的第二应用进程；和/或，第二操作系统发起终止第二应用进程时，通过所述协议通道向第一操作系统发出终止消息，触发第一操作系统响应终止消息而终止关联对应的第一应用进程。

所谓协同分布应用，是指为同一个任务而需要在第一操作系统上部署的第一应用和在第二操作系统上部署的第二应用，两个相关应用的结合体。例如前述本申请人提出的发明“二元协同安全客户端架构”(专利申请号CN201910255296.4)，就是一种涉及信息安全的协同分布应用架构。协同分布应用文件包括第一应用文件和第二应用文件，就要分别在第一操作系统和第二操作系统上安装、卸载、运行和终止。通常要由用户分别在第一操作系统桌面和第二操作系统桌面上分别操作，用户会感到繁琐甚至混淆困惑。上述协同联动机制，就使得用户在两个操作系统桌面的任意一个上面发起操作，都能够完成协同分布应用在两个操作系统的安装、卸载、运行和终止，如同在单个操作系统桌面环境下操作那样简单，从而改善用户体验。在上述协同联动机制中，所谓关联对应可以理解为一张关系表，存储在第一操作系统一方，还可在第二操作系统保留副本，是第一操作系统与第二操作系统关于协同分布应用的联系纽带。协同联动安装时，若安装成功则登记第一应用文件与第二应用文件之间的关联对应记录。协同联动卸载时，需要由关联对应记录查找与第一应用文件或第二应用文件相对应的应用文件，若卸载成功则删除第一应用文件与第二应用文件之间的关联对应记录。协同联动运行和协同联动终止时，也都需要由关联对应记录查找对应的应用文件，进而查到对应的应用进程而相应地运行和终止。

上述协同安全操作系统架构，进一步注重应用安装文件的完整一致性，其特征是，所述协同联动安装还预先对应用安装文件验证软件版本状态，确认完整一致则继续安装，否则限制安装。所谓软件版本状态，概念出自本申请人早前提出的发明“软件版本状态管控方法”(专利申请号CN201610649988.3)：生成软件版本状态，是对各应用文件计算数字签名，存储为一个派生后随行的状态文件来表征软件版本状态；验证软件版本状态，是引用随行状态文件验证应用文件的数字签名，来鉴别软件文档完整一致性。所谓限制安装，包括拒绝安装、警示选择安装。

上述协同安全操作系统架构，进一步注重第一应用文件的完整一致性，其特征是，所述协同联动运行还预先对第一应用文件验证软件版本状态，确认完整一致则继续运行，否则限制运行，包括限制存取敏感数据和访问敏感外围设备。所谓限制运行，包括拒绝运行、警示选择运行。所谓限制存取的敏感数据，例如通讯录、备忘录、密码表等。

生成软件版本状态，要由可信赖认证机构使用其私钥执行数字签名；验证软件版本状态，只需用该认证机构的数字证书(公钥证书)由系统自动执行。认证机构可以不只一家，而可能有多家。初始认证机构可以是生产厂家，或定制通信运营商，乃至某个权威机构，其他认证机构如授权的软件测试、测评机构，都能够对应用软件的安全性负责，用各自的私钥执行数字签名生成状态文件。于是，认证机构便形成一条信任链，操作系统通过其中一家或多家认证机构的验证，即能证明应用软件文档的完整一致性。由第一操作系统来建立维护认证机构信任链，包括明确记载相应数字证书，是出于安全审慎起见，以免被第二操作系统及其应用修改替换。

以上解决了对外围设备的协同驱动共享和对协同分布应用的协同联动管理这两个问题，在此基础上改进操作系统，本发明提出一种协同安全操作系统，体系结构逻辑上包括核心层、设备驱动层、功能执行层、应用框架层和应用层，预期用作协同共享和/或协同联动的第一操作系统或第二操作系统角色，其特征在于，所述操作系统具有：

上述关于外围设备的协同驱动共享的特征中任一项所述的协同安全操作系统架构中，作为所述第一操作系统或第二操作系统的协同驱动共享功能；和/或

上述关于协同分布应用的协同联动管理的特征中任一项所述的协同安全操作系统架构中，作为所述第一操作系统或第二操作系统的协同联动管理功能。

操作系统的体系结构有多种形态，本发明提出的层次划分是逻辑上的，层次名称也是描述性的，在具体操作系统中能够找到对应关系。例如，对比安卓(Android)操作系统，核心层/设备驱动层对应安卓宏内核(LINUX KERNEL)层，功能执行层对应安卓运行时库(ANDROID RUNTIME & LIBRARIES)层，应用框架层对应安卓应用框架(APPLICATIONFRAMEWORK)层，应用层对应安卓应用(APPLICATIONS)层。又例如，对比鸿蒙(HarmonyOS)操作系统(当前架构)，核心层/设备驱动层对应鸿蒙内核层，功能执行层对应鸿蒙基础服务层，应用框架层对应鸿蒙程序框架层，应用层对应鸿蒙应用层。本发明提出的协同安全操作系统，是成对互补配置使用的，既用作第一操作系统，又用作第二操作系统；可以是同构操作系统配对，如两个安卓操作系统配对；也可以而且值得推荐的是异构操作系统配对，如鸿蒙操作系统与安卓操作系统配对、Linux操作系统与Windows操作系统配对，等。

在上述协同安全操作系统的基础上，用于改进电子设备，本发明提出一种协同安全电子设备，内部包括地址空间各自独立的第一处理器与内存储器和第二处理器与内存储器，存储有第一操作系统和第二操作系统，其特征在于，所述第一操作系统和第二操作系统采用上述协同安全操作系统。所述协同安全电子设备，可以是服务器、个人电脑、笔记本电脑、平板电脑、智能电视、移动电话和穿戴设备等，尤其是屏幕尺寸较大的，例如折叠屏幕手机、台式电脑等。所述协同安全电子设备，其使用外观特征明显，就是用户界面具有双操作系统桌面，还可切换到其中任何一个操作系统桌面，每个系统桌面上有各自运行的应用界面；操作体验特征也明显，就是对协同分布应用程序，从两个操作系统桌面的其中一个，就能够操作完成在两个操作系统上的联动安装、卸载、运行和终止。

本发明的积极效果，是提供了一种协同安全操作系统架构新机制，能够在同一电子设备内部，用一套较安全的操作系统构成用户私密空间，而用另一套常规的操作系统构成用户开放空间，隔离又协同而实现外围设备安全共享和分布应用顺畅联动，显著增强电子设备系统安全性，有效保护用户的重要信息免于泄露；既有利于兼容既有的应用生态，又有助于培育新生的应用生态，尤其是安全应用生态，从而提升电子设备的系统价值。

附图说明

图1是本发明的示意图。电子设备(1)内部，分布配置第一操作系统(10)和第二操作系统(20)，于各自独立的处理器与内存地址空间并行运行，相互之间通过基于电路封闭连接的协议通道(30)交换数据消息。第一操作系统(10)的体系结构，逻辑上分为四层：应用层(110)，运行应用程序，包括系统应用程序；应用框架层(120)，管理应用程序和对应用层(110)提供功能调用接口；功能执行层(130)，是操作系统的核心功能、组件和类库的实现，提供运行时环境；设备驱动层(140)/核心层(150)，相当于操作系统的宏内核，设备驱动层(140)还部分依托于核心层(150)的支持，包含各种设备驱动程序。对应也类似地，第二操作系统(20)的体系结构，逻辑上也分四层：应用层(210)；应用框架层(220)；功能执行层(230)；设备驱动层(240)/核心层(250)。在第一操作系统(10)的应用层(110)，协同分布应用(1100)被应用框架层(120)安装时，留下第一应用(1101)，第二应用(1102)则被通知传递给第二操作系统(20)而被应用框架层(220)安装为第二应用(2102)，成功安装即登记在关联对应(121)上。类似地，在第二操作系统(20)的应用层(210)，协同分布应用(2100)被应用框架层(220)安装时，留下第二应用(2102)，第一应用(2101)则被通知传递给第一操作系统(10)而被应用框架层(120)安装为第一应用(1101)，成功安装亦登记在关联对应(121)上。协同分布应用(1100)和协同分布应用(2100)表示同一套安装文件，能够在第一操作系统(10)和第二操作系统(20)双方中的任一方发起安装，并联动对方安装完成，都登记在关联对应(121)。同样，两个操作系统中的任一方发起卸载第一应用(1101)/第二应用(2102)，也将参照关联对应(121)，联动对方卸载完成，并消除在关联对应(121)的登记。类似地，两个操作系统中的任一方发起运行/终止第一应用(1101)/第二应用(2102)，也将参照关联对应(121)，联动对方运行/终止完成。第一应用(1101)和第二应用(2102)在加载运行后，也能通过协议通道(30)交换数据消息，如弯折连接线箭头所示。第一操作系统(10)的功能执行层(130)还管控共享策略(132)，以屏蔽/开放驱动代理/驱动委托(131)服务(短箭头指向小圆表示控制关系)。第一操作系统(10)的设备驱动层(140)和第二操作系统(20)的设备驱动层(240)，共同面对物理设备层(40)，具体分别直接控制驱动敏感外围设备(410)和非敏感外围设备(420)，如纵向实线箭头表示；驱动代理/驱动委托(131)针对敏感外围设备(410)，驱动代理/驱动委托(231)针对非敏感外围设备(420)，如纵向虚线箭头表示。敏感外围设备(410)包括：显示屏(411)、摄像头(412)、麦克风(413)、扬声器(414)、键盘(415)、指纹(416)、外存(417)、打印机(418)、GPS(419)、蓝牙(4110)、NFC(4111)，等。非敏感外围设备(420)包括：触摸屏(421)、鼠标(422)、照明灯(423)、指南针(424)、传感器(425)(例如运动传感器)、外存(426)(即外存储器)、红外(427)、WIFI(428)、3G/4G/5G(429)、网络(4210)，等。需要说明的是，其中的敏感外围设备和非敏感外围设备的实际配置，取决于具体电子设备本身的功能需求和实际设计，而会有不同取舍和安排。通过协议通道(30)，在第一操作系统(10)与第二操作系统(20)之间，驱动代理/驱动委托(131)与驱动代理/驱动委托(231)之间(如横向长实线箭头表示)，设备驱动层(140)与设备驱动层(240)之间，都能够交换数据消息；以上高层之间，向下调用也能够交换数据消息。

图2是本发明实施例显示屏分配结构的示意图。显示屏(1)的全屏中，显示有分隔条(10)，分出左右两部分：左边显示区域为鸿蒙系统桌面(11)，右边显示区域为安卓系统桌面(12)。中间的水平双向箭头，表示分隔条(10)可以左右平移，以调节鸿蒙系统桌面(11)与安卓系统桌面(12)的相对大小。在实现时可安排，仅当触摸停留在分隔条(10)上，才在触摸位置浮现双向箭头，而点按箭头部可导致两个系统桌面切换成单个系统桌面全屏。

图3是本发明实施例引用的鸿蒙操作系统架构图(当前)，源于厂商正式发布的公开资料，经过编辑绘成。其中，对比本发明示意图1：应用层，对应应用层(110)/(210)；程序框架层，对应应用框架层(120)/(220)，基础服务层对应功能执行层(130)/(230)；内核层，对应设备驱动层(140)/(240)和核心层(150)/(250)。

具体实施方式

下面给出说明，作为本发明的一种适当实施方式。要申明的是，以下实施例不应被理解为本发明的全部可能范围，也不应构成对本发明权利的限制。

折叠屏手机可以展开使用，展现出较大的显示屏。选择现有折叠屏手机作为本发明实施的载体，得出改进后更安全的新折叠屏手机系统。实施设计包括以下方面：

1、手机硬件的适应性修改

(1)外围设备的敏感性划分

参照图1，按信息安全敏感性区分外围设备如表1所示，只列出手机具备的外围设备(也称部件、模组等)。其它如键盘(智能手机使用软键盘)、鼠标、打印机等，一般是台式机、服务器才配备。

表1 外围设备敏感性区分

敏感性区分	设备集
		敏感外围设备	显示屏、摄像头、麦克风、扬声器、指纹、外存、GPS、蓝牙、NFC
非敏感外围设备	触摸屏、照明灯、指南针、传感器、红外、WIFI、3G/4G/6G、网络

(2)硬件电路的修改

在现有电路板基础上扩展设计，先以现有电路和元器件为第一系统，复制第一系统到电路板的扩展部分获得第二系统，第一系统的地址空间(即寻址空间)与第二系统的地址空间相互独立；然后按照上面表1，将新电路板加以精简修改：从第一系统中删除非敏感外围设备及其相关元器件，保留敏感外围设备；从第二系统中删除敏感外围设备及其相关元器件，保留非敏感外围设备。于是从电路上，第一系统连接控制敏感外围设备，第二系统连接控制非敏感外围设备。

(3)协议通道的硬件选择

在修改后的新电路板上，再选择两件性能指标匹配的双端口存储器(字长32位、容量8KB以上)芯片，将其双端口分别编址到第一系统和第二系统各自的地址总线上，存取时需注意片上BUSY标志避免冲突；还可利用该标志产生中断信号，以改善系统存取效率。其中，一件用于第一系统写存而第二系统读取，称为A通道；另一件用于相反方向存取，称为B通道。A、B两个通道，便构成第一系统与第二系统之间的全双工并行硬件高速传输通道，通道容量即为双端口存储器的容量。

以上对手机硬件的修改，所需增加的材料成本主要是第二系统用的处理器、内存储器，以及两系统合用的双端口存储器，新增成本不高。还可改进选择利用不同的处理器芯片进行搭配，比如，第一系统的处理器采用较早的麒麟960芯片，第二系统的处理器采用较新的麒麟990 5G芯片，以求更高性价比。

2、协议通道与消息结构

在硬件高速传输通道的基础上，协议通道传输的是协议消息，实行可变长的数据包传输方式。定义协议消息数据包的结构为，定长的包头后跟变长的包体数据块，包体的数据长度由包头结构中的特定字段决定。包头结构定义如表2，传输交换时，将根据其中的数据长字段存取数据。

表2 协议消息的包头结构定义

本来通信传输一般都要有校验字段(如检查和)，但鉴于内存交换的可靠与可信，就省去了。传输的协议消息，形式化表示为一个四元组后跟数据的描述形式：

<协同号，设备号，功能号，数据长>[数据]

为便于叙述，在后续说明引用时，除第一个元素外，其余各个元素包括数据，将代入文字而非实际代码。

3、操作系统的选型搭配

选择鸿蒙(HarmonyOS)操作系统作为安全等级较高的第一操作系统，以下简称鸿蒙系统，配置在第一系统；选择安卓(Android)操作系统作为第二操作系统，以下简称安卓系统，配置在第二系统。预期用鸿蒙系统构成私密空间，而用安卓系统构成开放空间。

鸿蒙系统已被宣布将开源，而安卓系统早已全部开源，就有公开的源程序和相关技术资料，支持相应修改和扩展来实施本发明。

4、协议通道的实现

鸿蒙系统(参见图3)，在其内核层的Linux内核里，如同安卓系统的宏内核，有各种设备驱动程序。虽然可以按驱动程序的形式，来实现协议通道，但为了提高传输效率，就在Linux内核里增加编制一个协议通道模块，包括两个成员函数：发送函数，向A通道写入协议消息，即发送去安卓系统；接收函数，从B通道读取协议消息，来自安卓系统。该鸿蒙协议通道模块，后面将被鸿蒙驱动代理委托模块调用。

同样，也在安卓系统的Linux内核里，增加编制一个协议通道模块：接收函数，从A通道读取协议消息，来自鸿蒙系统；发送函数，向B通道写入协议消息，即发送去鸿蒙系统。该安卓协议通道模块，后面将被安卓驱动代理委托模块调用。于是，使用这一对协议通道模块，就在鸿蒙系统与安卓系统之间实现了协议通道。进一步改进，需要为协议通道建立互斥机制，防止数据传输过冲，尤其在共享使用情况下。

5、相关数据表

为记录敏感外围设备驱动共享策略、协同分布应用关联对应，定义表3和表4，由鸿蒙系统维护，在系统管理设置中，供用户选择设定。

表3 共享策略

序号	字段名	字段长	说明
				1	设备号	1B	敏感外围设备的代码
2	策略	1B	0＝屏蔽，1＝开放

表4 关联对应

序号	字段名	字段长	说明
				1	第一应用文件	256C	安装目录路径
2	第二应用文件	256C	安装目录路径
				3	第一应用完整性	1B	第一应用文件是否完整：0＝否，1＝是
4	第二应用完整性	1B	第一应用文件是否完整：0＝否，1＝是
				5	第一通道指针	DW	0＝无，非0＝协同通道文件指针(Handle)
6	第二通道指针	DW	0＝无，非0＝协同通道文件指针(Handle)

6、驱动代理/驱动转移委托协议的实现

简称代理委托协议。为便于与设备驱动程序交互，选择在内核层实现代理委托协议。鸿蒙系统和安卓系统都有Linux内核，而两边代理委托协议逻辑也一致，所以设计模块代理委托也类似。

鸿蒙代理委托模块，有四两个成员函数：发送函数，调用鸿蒙协议通道模块的发送函数来实现；接收函数，调用鸿蒙协议通道模块的接收函数来实现；代理函数，对由接收函数收到的协议消息(来自安卓系统，具体来自安卓委托函数)，执行可控驱动代理功能；委托函数，调用发送函数发出协议消息(发去安卓系统，具体去到安卓代理函数)，实现驱动转移功能(非受控)。

安卓代理委托模块，也有四两个成员函数：发送函数，调用安卓协议通道模块的发送函数来实现；接收函数，调用安卓协议通道模块的接收函数来实现；代理函数，对由接收函数收到的协议消息(来自鸿蒙系统，具体来自鸿蒙委托函数)，执行驱动代理功能；委托函数，调用发送函数发出协议消息(发去鸿蒙系统，具体去到鸿蒙代理函数)，实现受控驱动转移功能。

(1)鸿蒙代理函数的实现

每当鸿蒙接收函数收到一条这样的协议消息

<协同号，设备号，功能号，数据长>[数据]

必是来自安卓委托函数，先按表2检查协同号，如下区别处理：

若协同号是协同驱动(0)，则首先检查对该设备的访问操作，是否与鸿蒙自用或表3中策略相冲突，若是，则忽略之(相当于屏蔽)，并调用发送函数发回消息<0，设备号，功能屏蔽号，0>[]；若否(不冲突)，则由设备号决定设备类型和设备驱动程序，再根据功能号、数据长提取参数并作必要的转换适配，然后将功能号和参数传入相应的设备驱动程序执行。这意味着，鸿蒙系统使用敏感外围设备有优先权，而不会被安卓系统的转移驱动所抢断。而且，若设备号是显示屏或外存储器，则无须检查冲突，因为对鸿蒙系统和安卓系统都是分区共用关系。

若协同号是协同联动(1)，则提取数据，转交并激发进程管理事件，被进程管理程序获取，进而作为联动消息处理。

若协同号是协同应用(2)，则提取数据，解构数据得知目的应用进程标识，送入对应的应用缓冲区，进而被该应用所获取。

(2)鸿蒙委托函数的实现

直接封装发送函数，即调用发送函数发出协议消息。

(3)安卓代理函数的实现

与鸿蒙代理函数的功能处理类似，只是对于协同驱动，不检查对应设备自用和策略冲突，直接功能号和参数传入相应的设备驱动程序执行。这意味着，鸿蒙系统使用非敏感外围设备也有优先权，其转移驱动能够抢断安系统卓的使用。

(4)安卓委托函数的实现

也是直接封装发送函数，即调用发送函数发出协议消息。

(5)鸿蒙系统与安卓系统间的代理委托关系

在鸿蒙系统与安卓系统间，通过协议通道实现了：鸿蒙代理委托模块的代理函数与安卓代理委托模块的委托函数之间，形成代理委托关系，使得鸿蒙系统驱动使用的敏感外围设备，也能被安卓系统驱动转移使用，而且可控地，鸿蒙系统驱动使用有优先权；安卓代理委托模块的代理函数与鸿蒙代理委托模块的委托函数之间，形成代理委托关系，使得安卓系统驱动使用的非敏感外围设备，也能被鸿蒙系统驱动转移使用，而且未加控制，鸿蒙系统驱动使用也有优先权。

7、协同驱动共享的实现

协同驱动共享，还需修改现有的设备驱动程序才能支持。总的思路是，区分来自本系统的驱动操作和来自对方的驱动转移消息，分别处理执行。下面以几个敏感外围设备的驱动修改为例来说明，至于其它外围设备，只需参照修改即可。

(1)显示屏驱动

首先将显示屏分屏，显示两个操作系统桌面，参见图2。鸿蒙系统桌面在左，中间显示分隔条，安卓系统桌面在右。默认的设置策略是，当折叠屏幕展开时，分隔条就正好显示在折叠线上，以达到好像翻书的体验效果。允许调整改变两个桌面的布局(如上下分布隔开、切换到单个系统桌面)和大小(关键是分隔条移动位置)，就还需修改鸿蒙系统的程序框架层中的窗口管理器(Windows Manager)，将系统桌面的布局和大小的数值变量化存储，由外部用户操作引发的改变，将相应地保存系统桌面的当前位置和大小。每当发生改变，还派生两个操作：一是触发本方系统显示重绘鸿蒙系统桌面；二是调用鸿蒙代理委托模块，发出一条协议消息<0，显示，桌面设置，数据大小>[安卓系统桌面当前大小数值]；而在对方系统，安卓代理委托模块将收到该协议消息，解析执行后既保存安卓系统桌面当前大小数值，又触发重绘安卓系统桌面，进入安卓系统显示驱动程序，调用安卓代理委托模块，发出一条协议消息<0，显示，桌面重绘，数据大小>[桌面显示数据]；该重绘消息又被鸿蒙代理委托模块收到，解析后传入鸿蒙系统的显示驱动程序而执行重绘。

鸿蒙系统显示屏驱动程序，在保持现有驱动功能基础上，作两方面改进：一是蒙系统的显示操作，由原来按全屏固定尺寸大小，变为按系统桌面的当前位置和大小执行，包括显示鸿蒙系统桌面，还负责显示屏幕分隔条；二是解析由鸿蒙代理委托模块传入的协议消息，执行安卓系统驱动转移的相应显示操作，并限于安卓系统桌面区域。显示数据由上层生成，相关模块也需修改，而参照系统桌面当前大小，绘制桌面和应用窗口。关于截屏操作，对来自鸿蒙系统的截屏操作，按选项可获取全屏或鸿蒙系统桌面图像；对协议消息<0，显示，截屏，0>[]传入的安卓系统的截屏操作，限制获取安卓系统桌面图像，发出一条协议消息<0，显示，截屏，数据大小>[安卓系统桌面屏幕图像数据]，安卓系统的显示驱动程序即能收到，然后向上层返回。

安卓系统显示屏驱动程序，跳过现有驱动功能，将所有显示驱动操作，按功能项转换为协议消息<0，显示，功能项号，数据大小>[显示数据]，例如，功能项号为截屏的代码，调用安卓代理委托模块，发送到鸿蒙代理委托模块，又从鸿蒙代理委托模块接收到协议消息<0，显示，截屏，数据大小>[安卓系统桌面屏幕图像数据]，就如同原来的显示驱动对截屏操作获取桌面屏幕图像数据。

(2)外存驱动

鸿蒙系统管理驱动的外存，划分出一个分区，简称安卓分区，虚拟为安卓系统的外存，用于存储安卓系统的文件系统。需要分别修改鸿蒙系统外存驱动程序，和安卓系统外存驱动程序。鸿蒙代理委托模块收到的协议消息，便是安卓代理委托模块发出的协议消息，例如，读操作<0，外存，读，描述大小>[存储位置与数据量的描述]，写操作<0，外存，写，数据大小>[存储位置与写存的数据]，将会被解析传入鸿蒙系统外存驱动程序；而由安卓代理委托模块收到的协议消息，便是鸿蒙代理委托模块发回的协议消息，例如，读操作<0，外存，读，数据大小>[读取的数据]，写操作<0，外存，写，数据大小>[结果状态数据]，将会被解析传入安卓系统外存驱动程序。

鸿蒙系统外存驱动程序，在保持现有驱动功能基础上改进。对鸿蒙代理委托模块传入的来自安卓系统的操作消息(指令)，按照操作功能项分类处理，如同原有功能处理那样，但有两点区别：一是所有访问操作的范围，都隐射到安卓分区并且限制在安卓分区；二是所有访问操作的结果，都转换为相应操作的协议消息，调用鸿蒙代理委托模块发送，从而反馈回安卓系统。对于读/写操作，当数据量过大(协议消息长度超过协议通道容量)时，将分解为若干连续的协议消息传输过程(下同)。

安卓系统外存驱动程序，在现有驱动功能基础上改进。对所有驱动功能项操作，都转换为相应的操作协议消息，例如，读操作<0，外存，读，描述大小>[存储位置与数据量的描述]，写操作<0，外存，写，数据大小>[存储位置与写存的数据]，接着调用安卓代理委托模块发出，而将被鸿蒙代理委托模块收到去执行处理；对鸿蒙代理委托模块发回的协议消息，例如，读操作<0，外存，读，数据大小>[读取的数据]，写操作<0，外存，写，数据大小>[结果状态数据]，解析传入到本外存驱动程序，结果数据就如同原来的外存驱动对外存获取操作数据的结果。

(3)摄像头驱动

鸿蒙系统摄像头驱动程序，在保持现有驱动功能基础上改进。对源自鸿蒙系统上层的驱动功能不变，增加对鸿蒙代理委托模块传入的来自安卓系统的操作消息的处理，按照摄像头操作功能项分类处理，例如，拍照操作<0，摄像头，拍照，0>口，执行原有功能获取图像数据，然后转换为协议消息<0，摄像头，拍照，数据大小>[图像/状态数据]，再调用鸿蒙代理委托模块发回安卓系统。

安卓系统摄像头驱动程序，在现有驱动功能基础上改进。对所有驱动功能项操作，都转换为相应的操作协议消息，例如，拍照操作<0，摄像头，拍照，0>口，接着调用安卓代理委托模块发出，而将被鸿蒙代理委托模块收到去执行处理；对鸿蒙代理委托模块发回的协议消息，例如，<0，摄像头，拍照，数据大小>[图像/状态数据]，解析传入到本摄像头驱动程序，结果数据就如同原来的摄像头驱动对摄像头获取操作数据的结果。

(4)麦克风驱动

鸿蒙系统麦克风驱动程序，在保持现有驱动功能基础上改进。对源自鸿蒙系统上层的驱动功能不变，增加对鸿蒙代理委托模块传入的来自安卓系统的操作消息的处理，按照麦克风操作功能项分类处理，例如，录音操作<0，麦克风，录音，4>[时长数据(毫秒数)]，执行原有功能获取音频数据，然后转换为协议消息<0，麦克风，录音，数据大小>[音频/状态数据]，再调用鸿蒙代理委托模块发回安卓系统。

安卓系统麦克风驱动程序，在现有驱动功能基础上改进。对所有驱动功能项操作，都转换为相应的操作协议消息，例如，录音操作<0，麦克风，录音，4>[时长数据(毫秒数)]，接着调用安卓代理委托模块发出，而将被鸿蒙代理委托模块收到去执行处理；对鸿蒙代理委托模块发回的协议消息，例如，<0，麦克风，录音，数据大小>[音频/状态数据]，解析传入到本麦克风驱动程序，结果数据就如同原来的麦克风驱动对麦克风获取操作数据的结果。

(5)扬声器驱动

鸿蒙系统扬声器驱动程序，在保持现有驱动功能基础上改进。对源自鸿蒙系统上层的驱动功能不变，增加对鸿蒙代理委托模块传入的来自安卓系统的操作消息的处理，按照扬声器操作功能项分类处理，例如，播音操作<0，扬声器，播音，数据大小>[音频数据]，执行原有功能播放音频数据，然后转换为协议消息<0，扬声器，播音，4>[结果状态字]，再调用鸿蒙代理委托模块发回安卓系统。

安卓系统扬声器驱动程序，在现有驱动功能基础上改进。对所有驱动功能项操作，都转换为相应的操作协议消息，例如，播音操作<0，扬声器，播音，数据大小>[音频数据]，接着调用安卓代理委托模块发出，而将被鸿蒙代理委托模块收到去执行处理；对鸿蒙代理委托模块发回的协议消息，例如，<0，扬声器，播音，4>[结果状态字]，解析传入到本扬声器驱动程序，结果数据就如同原来的扬声器驱动对麦克风播放操作的结果。

(6)其它驱动

上述设备驱动程序，涵盖了敏感外围设备的输入类和输出类，可供其它敏感外围设备的驱动程序参照修改。类似地，对非敏感外围设备的驱动程序，也能参照修改。

对设备驱动的实用性改进的一种方案，是为了提高效率改善性能，而将驱动共享提升到功能接口层面。例如，对于视频播放，可将安卓系统的播放功能，转移委托鸿蒙系统的播放功能代理播放，于是，视频数据的存取和解析就与播放操作过程部分并行，就能有更好的播放体验效果。这就需要修改托鸿蒙系统的播放功能模块、安卓系统的播放功能模块，以及扩展协议通道的消息适用范围。相应修改思路，与上述驱动修改思路类似。

8、协同联动管理的实现

为兼容现有应用安装文件，首先定义一个协同分布应用安装文件，后缀命名为.p2k，是文本文件。其中两行分别是：[1stApp]＝<第一应用文件安装包>；[2ndApp]＝<第二应用文件安装包>。协同分布应用安装文件，与第一应用安装文件、第二应用安装文件并列存储，以便协同联动安装时搜索。然后，对现有操作系统作相应修改。关联对应表(见表4)只在鸿蒙系统中管理维护。在传输协议消息过程中，若文件数据长度超出协议通道容量，则需分割成多个分组消息连续发送。为实现协同联动管理，需要做以下系统修改，主要是增加处理步骤。

(1)修改鸿蒙系统程序框架层中的安装包管理器(Package Manager)

发起安装的处理步骤：识别打开分布应用安装文件，从中搜索第一应用文件、第二应用文件；安装第一应用文件；调用鸿蒙代理委托模块发出协议消息<1，联动，安装，数据大小>[第二应用文件数据]，而安卓代理委托模块将收到并处理；鸿蒙代理委托模块接收到，安卓代理委托模块发回的协议消息<1，管理，安装，数据大小>[结果状态+第二应用文件安装目录路径数据]；若安装成功(结果状态标识)，则在关联对应表登记一条记录，将两个安装目录路径，分别写入第一应用文件字段、第二应用文件字段，复位其它字段。

响应安装的处理步骤：鸿蒙代理委托模块，接收到安卓代理委托模块发来的协议消息<1，联动，安装，数据大小>[第二应用文件安装目录路径+第一应用文件数据]；安装第一应用文件；调用鸿蒙代理委托模块发出协议消息<1，联动，安装，数据大小>[结果状态数据]，而安卓代理委托模块将收到并处理；若安装成功，则在关联对应表登记一条记录，将两个安装目录路径，分别写入第一应用文件、第二应用文件两个字段，复位其它字段。

发起卸载的处理步骤：卸载应用文件；从关联对应表中第一应用文件字段，搜索该应用文件路径，若发现记录，则判为第一应用文件，随即提取第二应用文件安装目录路径，并继续后面步骤；调用鸿蒙代理委托模块发出协议消息<1，联动，卸载，数据大小>[第二应用文件安装目录路径数据]，而安卓代理委托模块将收到并处理；接收安卓代理委托模块发回的协议消息<1，联动，卸载，数据大小>[结果状态数据]；若卸载成功，则从关联对应表删除该条记录。

响应卸载的处理步骤：鸿蒙代理委托模块，接收到安卓代理委托模块发来的协议消息<1，进程，卸载，数据大小>[第二应用文件安装目录路径数据]；从关联对应表中第二应用文件字段，搜索该第二应用文件安装目录路径，若发现记录，则提取第一应用文件的安装目录路径，并继续后面步骤；卸载第一应用文件；调用鸿蒙代理委托模块发出协议消息<1，联动，卸载，数据大小>[结果状态数据]；若卸载成功，则从关联对应表删除该条记录。

(2)修改安卓系统应用框架层中的安装包管理器(Package Manager)

发起安装的处理步骤：识别打开分布应用安装文件，从中搜索第二应用文件、第二应用文件；安装第二应用文件；调用安卓代理委托模块发出协议消息<1，联动，安装，数据大小>[第二应用文件安装目录路径+第一应用文件数据]，而鸿蒙代理委托模块将收到并处理；安卓代理委托模块接收到，鸿蒙代理委托模块发回的协议消息<1，联动，安装，数据大小>[结果状态数据]；检查是否安装成功，可作提示信息。

响应安装的处理步骤：安卓代理委托模块，接收到鸿蒙代理委托模块发来的协议消息<1，联动，安装，数据大小>[第二应用文件数据]；安装第二应用文件；调用安卓代理委托模块发出协议消息<1，联动，安装，数据大小>[结果状态+第二应用文件安装目录路径数据]，而鸿蒙代理委托模块将收到并处理。

发起卸载的处理步骤：卸载应用文件(设为第二应用文件)；调用安卓代理委托模块发出协议消息<1，联动，卸载，数据大小>[第二应用文件安装目录路径数据]，而鸿蒙代理委托模块将收到并处理；安卓代理委托模块接收到，鸿蒙代理委托模块发回的协议消息<1，联动，卸载，数据大小>[结果状态数据]；检查是否安装成功，可作提示信息。

响应卸载的处理步骤：安卓代理委托模块，接收到鸿蒙代理委托模块发来的协议消息<1，联动，卸载，数据大小>[第二应用文件安装目录路径数据]；卸载第二应用文件；调用安卓代理委托模块发出协议消息<1，联动，卸载，数据大小>[结果状态数据]，而鸿蒙代理委托模块将收到并处理。

(3)修改鸿蒙系统程序框架层中的活动管理器(Activity Manager)

发起运行的处理步骤：运行应用文件；从关联对应表中第一应用文件字段，搜索该应用文件路径，若发现记录，则判为第一应用文件，随即提取第二应用文件安装目录路径，并调用鸿蒙代理委托模块发出协议消息<1，联动，运行，数据大小>[第二应用文件安装目录路径数据]，而安卓代理委托模块将收到并处理。

响应运行的处理步骤：鸿蒙代理委托模块，接收到安卓代理委托模块发来的协议消息<1，联动，运行，数据大小>[第二应用文件安装目录路径数据]；从关联对应表中第二应用文件字段，搜索该第二应用文件安装目录路径，若发现记录，则提取第一应用文件的安装目录路径，并运行第一应用文件。

发起终止的处理步骤：由系统确定应用进程所对应的应用文件，终止该应用进程；从关联对应表中第一应用文件字段，搜索该应用文件路径，若发现记录，则判为第一应用进程，随即提取第二应用文件安装目录路径，并调用鸿蒙代理委托模块发出协议消息<1，联动，终止，数据大小>[第二应用文件安装目录路径数据]，而安卓代理委托模块将收到并处理。

响应终止的处理步骤：鸿蒙代理委托模块，接收到安卓代理委托模块发来的协议消息<1，联动，终止，数据大小>[第二应用文件安装目录路径数据]；从关联对应表中第二应用文件字段，搜索该第二应用文件安装目录路径，若发现记录，则提取第一应用文件的安装目录路径，再由系统确定对应的第一应用进程，并终止该应用进程。

(4)修改安卓系统应用框架层中的活动管理器(Activity Manager)

发起运行的处理步骤：运行应用文件(设为第二应用文件)；调用安卓代理委托模块发出协议消息<1，联动，运行，数据大小>[第二应用文件安装目录路径数据]，而鸿蒙代理委托模块将收到并处理。

响应运行的处理步骤：安卓代理委托模块，接收到鸿蒙代理委托模块发来的协议消息<1，联动，运行，数据大小>[第二应用文件安装目录路径数据]；运行第二应用文件。

发起终止的处理步骤：由系统确定应用进程所对应的应用文件，终止该应用进程；调用安卓代理委托模块发出协议消息<1，联动，终止，数据大小>[第二应用文件安装目录路径数据]，而鸿蒙代理委托模块将收到并处理。

响应终止的处理步骤：安卓代理委托模块，接收到鸿蒙代理委托模块发来的协议消息<1，联动，终止，数据大小>[第二应用文件安装目录路径数据]；由系统确定对应的第二应用进程，并终止该应用进程。

9、协同分布应用数据传输的实现

扩展鸿蒙系统和安卓系统的设备文件系统，模拟一个协同通道文件(命名CoChannel)，在程序框架层/应用框架层，为协同分布应用提供双向数据传输功能的文件操作，包括打开、读、写、和关闭操作。文件操作的实现，基于协议通道，依托上述代理委托模块，需增加下列关于协同通道文件的操作处理步骤。

(1)打开协同通道文件

鸿蒙系统打开协同通道文件步骤：传入文件指针(Handle)，由系统确定应用进程所对应的应用文件，从关联对应表中第一应用文件字段，搜索该应用文件路径，若发现记录则将文件指针写入记录的第一通道指针字段。

安卓系统打开协同通道文件步骤：传入文件指针(Handle)，设为第二通道指针；由系统确定应用进程所对应的应用文件(设为第二应用文件)，调用安卓代理委托模块发出协议消息<2，打开，指针，数据大小>[第二通道指针+第二应用文件安装目录路径数据]；鸿蒙代理委托模块将收到并处理，从关联对应表中第二应用文件字段，搜索该应用文件路径，若发现记录则写入第二通道指针字段，否则判为非协同分布应用，回传协议消息<2，打开，指针，4>[第二通道指针/打开结果]；安卓代理委托模块，收到鸿蒙代理委托模块回传的协议消息，若第二通道指针＝0，则打开结果失败(非协同分布应用)。

(2)写协同通道文件

鸿蒙系统写协同通道文件步骤：传入文件指针(Handle)、文件数据和大小，从关联对应表中第一通道指针字段，搜索该文件指针，若发现记录则继续；提取记录中的第二通道指针字段；调用鸿蒙代理委托模块发出协议消息<2，写，数据，数据大小>[第二通道指针+文件数据]，而安卓代理委托模块将收到并处理。

安卓系统写协同通道文件步骤：传入文件指针(Handle)(设为第二通道指针)、文件数据和大小；调用安卓代理委托模块发出协议消息<2，写，数据，数据大小>[第二通道指针+文件数据]，而鸿蒙代理委托模块将收到并处理。

(3)读协同通道文件

鸿蒙系统读协同通道文件步骤：传入文件指针(Handle)、文件数据缓冲区和大小，从关联对应表中第一通道指针字段，搜索该文件指针，若发现记录则继续；提取记录中的第二通道指针字段；调用鸿蒙代理委托模块，收到安卓代理委托模块发来的协议消息<2，写，数据，数据大小>[第二通道指针+文件数据]，若第二通道指针相符，则将文件数据复制到文件数据缓冲区并确定数据大小。

安卓系统读协同通道文件步骤：传入文件指针(Handle)(设为第二通道指针)、文件数据缓冲区和大小；调用安卓代理委托模块，收到鸿蒙代理委托模块发来的协议消息<2，写，数据，数据大小>[第二通道指针+文件数据]，若第二通道指针相符，则将文件数据复制到文件数据缓冲区并确定数据大小。

(4)关闭协同通道文件

鸿蒙系统关闭协同通道文件步骤：传入文件指针(Handle)，从关联对应表中第一通道指针字段，搜索该文件指针，若发现记录，则清除记录中的第一通道指针字段。

安卓系统关闭协同通道文件步骤：传入文件指针(Handle)(设为第二通道指针)；调用安卓代理委托模块发出协议消息<2，关闭，指针，4>[第二通道指针]，而鸿蒙代理委托模块将收到并这样处理，从关联对应表中第二通道指针字段，搜索该文件指针，若发现记录，则清除记录中的第二通道指针字段。

以上操作处理步骤还能继续改进，增加错误检测和反馈，以及保证协议通道的共享互斥。

10、应用认证保障

鸿蒙系统被视为安全等级高，用来构建用户的私密空间，其上安装运行的应用程序就有必要检测认证。重点保证鸿蒙系统上的应用，包括协同分布应用的第一应用文件，经过可信赖的认证机构认证。保障的实施包括下列几方面：

(1)确定数字证书

在鸿蒙系统中建立一个数字证书表，预置一个初始的数字证书属于系统管理者，例如设备厂商、通信运营商，或某个权威机构。由该系统管理者为其他认证机构颁发数字证书。鸿蒙系统的设置管理，提供数字证书表的操作界面，用于维护数字证书表，包括对系统管理者所颁发数字证书的增加、删除、查询和修改，系统自动验证数字证书的有效性。还可以采取系统后台推送机制，通过通信方式传递自动更新。

(2)生成软件版本状态

对于预发布的应用软件产品，首先对安装状态下的文件目录树，生成软件版本状态文件，与启动文件同名(后缀不同)，随行加入到启动程序文件所在同级目录；然后打包文件生成安装包，再为该安装包文件生成软件版本状态文件，与安装包文件同名(后缀不同)并随行正式发布。由有效的认证机构用其私钥执行签名，采用的软件状态生成工具软件，按照本申请人早前提出的发明“软件版本状态管控方法”(专利申请号CN201610649988.3)的实施方案开发，包括生成和验证软件状态的功能。

(3)验证软件版本状态

在前述的修改鸿蒙系统程序框架层中的安装包管理器(Package Manager)中，对所述发起安装和响应安装的处理步骤，增加预处理步骤：对第一应用文件(安装包)，引用软件版本状态文件，从数字证书表中顺序取用一个个数字证书来验证软件版本状态，只要有一个通过验证，就继续安装；否则，警示用户风险，交由用户选择拒绝安装或继续安装。对非协同分布应用文件(安装包)，也同样验证处理。

在前述修改鸿蒙系统程序框架层中的活动管理器(Activity Manager)中，对所述发起运行和响应运行的处理步骤，增加预处理步骤：对第一应用文件，引用软件版本状态文件，从数字证书表中顺序取用一个个数字证书来验证软件版本状态，只要有一个通过验证，就继续运行；否则，提示用户风险，交由用户选择拒绝运行或继续运行；验证结果，写入关联对应表(表4)中的第一应用完整性字段。对非协同分布应用文件，也同样验证处理，只是不将验证结果写入关联对应表。

验证软件版本状态的功能，与上述生成工具软件的类似，需要编制为鸿蒙系统的功能函数以供调用。涉及存取敏感数据的其它相关部分，如通讯录管理器(TelephonyManager)等，需要适应修改，检查应用不完整一致性时限制存取。还要对上述协同驱动共享的实现，增加检查关联对应表中的第一应用完整性字段，当不完整一致性时限制访问敏感外围设备。

11、一键保护机制

修改鸿蒙系统的系统设置程序，选定一个敏感外围设备集，默认全选敏感外围设备，还可任意单选或排除设备成员，确定后保存到内部的敏感外围设备受控表中。在鸿蒙系统桌面上，布设一个切换/状态键，对应处理实现是：保护状态时，按敏感外围设备受控表，逐个对设备成员，在共享策略表(表3)中，将相应设备号的记录，置策略字段为屏蔽(0)；开放状态时，进行同样操作，但置策略字段为开放(1)。于是，就能达到一键保护敏感外围设备，而禁止安卓系统及其应用访问；也能一键开放，而允许正常访问。一键保护的触发方式，也不限于按键，还能够实现手势、声控等其它方式的触发。

通过以上修改实施，再重新编译，就能得出改进后新的鸿蒙操作系统和安卓操作系统，这两个操作系统都是协同安全操作系统。折叠屏手机经过前述硬件适应性改造，再装上这样一对协同安全操作系统，就形成为了协同安全折叠屏手机，是协同安全电子设备的一种。参照类似方法实施的协同安全电子设备，还可以是服务器、个人电脑、笔记本电脑、平板电脑、智能电视、移动电话和穿戴设备等。

Claims (10)

1.一种协同安全操作系统架构，在同一电子设备内部，为地址空间各自独立的第一处理器与内存储器和第二处理器与内存储器，分布配置第一操作系统和第二操作系统并行运行，赋予第一操作系统比第二操作系统更高安全等级或安全预期，两个操作系统相互之间通过基于电路信号封闭连接的协议通道交换数据消息，对外围设备按敏感性区分而实行协同驱动共享，第一操作系统控制驱动敏感外围设备，第二操作系统控制驱动非敏感外围设备，其特征在于，所述协同驱动共享包括对于敏感外围设备的下列控制机制：

可控驱动代理：第一操作系统基于其设备驱动程序，通过所述协议通道，自控地向第二操作系统提供驱动代理，受理第二操作系统的驱动转移委托；

受控驱动转移：第二操作系统的设备驱动程序和/或功能接口程序，通过所述协议通道，受控地转移委托第一操作系统代理驱动而实现间接控制共享；

共享策略控制：第一操作系统管控驱动共享策略，用以操控所述可控驱动代理，屏蔽或开放所述第二操作系统的驱动转移委托。

2.根据权利要求1所述的协同安全操作系统架构，其特征是，所述可控驱动代理和受控驱动转移适用显示屏，允许通过外部操作随时调整第一操作系统与第二操作系统同屏显示桌面区域的布局和相对大小，而所述可控驱动代理则将所述受控驱动转移的第二操作系统截屏操作，获取图像范围限制于第二操作系统显示桌面区域。

3.根据权利要求1所述的协同安全操作系统架构，其特征是，所述可控驱动代理和受控驱动转移适用外存储器，所述可控驱动代理将第一操作系统的外存储器中部分区域，虚拟共享为第二操作系统的外存储器，导致第二操作系统对外存储器的访问被映射且限制于该部分区域。

4.根据权利要求1所述的协同安全操作系统架构，其特征是，所述可控驱动代理和受控驱动转移适用摄像头、麦克风和扬声器，当第一操作系统进行通话或拍录/播放音像时，所述可控驱动代理自动屏蔽第二操作系统对相关外围设备的驱动转移委托。

5.根据权利要求1所述的协同安全操作系统架构，其特征是，所述可控驱动代理自行避让第一操作系统所引发的控制驱动，保证第一操作系统的应用比第二操作系统的应用在共享使用敏感外围设备时享有优先权。

6.一种协同安全操作系统架构，在同一电子设备内部，为地址空间各自独立的第一处理器与内存储器和第二处理器与内存储器，分布配置第一操作系统和第二操作系统并行运行，赋予第一操作系统比第二操作系统更高安全等级或安全预期，两个操作系统相互之间通过基于电路信号封闭连接的协议通道交换数据消息，对协同分布应用实行协同联动管理，其特征在于，所述协同联动管理包括下列协同联动机制中的至少一个方面：

协同联动安装：第一操作系统发起安装协同分布应用文件时，从中区分第一应用文件和第二应用文件，将第一应用文件安装于第一操作系统存储区，通过所述协议通道向第二操作系统发出安装消息并传送第二应用文件，触发第二操作系统响应安装消息接收第二应用文件而安装于第二操作系统存储区并将安装结果反馈第一操作系统；和/或，第二操作系统发起安装协同分布应用文件时，从中区分第一应用文件和第二应用文件，将第二应用文件安装于第二操作系统存储区，通过所述协议通道向第一操作系统发出安装消息并传送第一应用文件，触发第一操作系统响应安装消息接收第一应用文件而安装于第一操作系统存储区并将安装结果反馈第二操作系统；第一操作系统记录已安装的第一应用文件与第二应用文件之间的关联对应；

协同联动卸载：第一操作系统发起卸载第一应用文件时，从第一操作系统存储区卸载第一应用文件，通过所述协议通道向第二操作系统发出卸载消息，触发第二操作系统响应卸载消息而从第二操作系统存储区卸载对应的第二应用文件并将卸载结果反馈第一操作系统；和/或，第二操作系统发起卸载第二应用文件时，从第二操作系统存储区卸载第二应用文件，通过所述协议通道向第一操作系统发出卸载消息，触发第一操作系统响应卸载消息而从第一操作系统存储区卸载对应的第一应用文件并将卸载结果反馈第二操作系统；第一操作系统消除已卸载的第一应用文件与第二应用文件之间的关联对应记录；

协同联动运行：第一操作系统发起加载第一应用文件运行为第一应用进程时，通过所述协议通道向第二操作系统发出运行消息，触发第二操作系统响应运行消息而加载关联对应的第二应用文件运行为第二应用进程；和/或，第二操作系统发起加载第二应用文件运行为第二应用进程时，通过所述协议通道向第一操作系统发出运行消息，触发第一操作系统响应运行消息而加载关联对应的第一应用文件运行为第一应用进程；

协同联动终止：第一操作系统发起终止第一应用进程时，通过所述协议通道向第二操作系统发出终止消息，触发第二操作系统响应终止消息而终止关联对应的第二应用进程；和/或，第二操作系统发起终止第二应用进程时，通过所述协议通道向第一操作系统发出终止消息，触发第一操作系统响应终止消息而终止关联对应的第一应用进程。

7.根据权利要求6所述的协同安全操作系统架构，其特征是，所述协同联动安装还预先对应用安装文件验证软件版本状态，确认完整一致则继续安装，否则限制安装。

8.根据权利要求6所述的协同安全操作系统架构，其特征是，所述协同联动运行还预先对第一应用文件验证软件版本状态，确认完整一致则继续运行，否则限制运行，包括限制存取敏感数据和访问敏感外围设备。

9.一种协同安全操作系统，体系结构逻辑上包括核心层、设备驱动层、功能执行层、应用框架层和应用层，预期用作协同共享和/或协同联动的第一操作系统或第二操作系统角色，其特征在于，所述操作系统具有：

权利要求1至5中任一项所述的协同安全操作系统架构中，作为所述第一操作系统或第二操作系统的协同驱动共享功能；和/或

权利要求6至8中任一项所述的协同安全操作系统架构中，作为所述第一操作系统或第二操作系统的协同联动管理功能。

10.一种协同安全电子设备，内部包括地址空间各自独立的第一处理器与内存储器和第二处理器与内存储器，存储有第一操作系统和第二操作系统，其特征在于，所述第一操作系统和第二操作系统采用权利要求9所述的协同安全操作系统。

Images