CN112328297B

CN112328297B - 一种在Linux上兼容运行的Android系统的升级方法与装置

Info

Publication number: CN112328297B
Application number: CN202011383943.9A
Authority: CN
Inventors: 姚宏亮; 李志法; 张耀斌
Original assignee: Beijing Jide System Technology Co ltd
Current assignee: Beijing Jide System Technology Co ltd
Priority date: 2020-11-30
Filing date: 2020-11-30
Publication date: 2021-04-20
Anticipated expiration: 2040-11-30
Also published as: CN112328297A

Abstract

本发明公开了一种在Linux上兼容运行的Android系统的升级方法与装置，属于计算机基础软件领域。所述方法包括创建升级守护进程和升级GUI进程，其中升级守护进程负责创建Socket服务端，完成升级的主要流程控制，穿透Docker对Android OS中的文件进行增删改动作；升级GUI进程通过Socket与升级守护进程连接，将升级状态信息通过升级GUI应用显示，同时把用户对升级GUI应用的操作传递给升级守护进程，完成用户对升级的控制响应工作。发明解决了以容器方式兼容运行在Linux系统中的Android系统因需要与容器一起打包升级而占用大量资源的问题，使Android系统能够单独进行全量或增量升级。

Description

一种在Linux上兼容运行的Android系统的升级方法与装置

技术领域

本发明涉及计算机技术领域，特别是涉及一种在Linux上兼容运行的Android系统的升级方法与装置。

背景技术

当Android系统以容器方式运行在Linux操作系统之上时，由于需要不断完善Android运行环境，例如打补丁，因此需要提供一种在Linux侧穿透容器给Android升级的方法。

虽然Android系统有完善的升级方案，但是由于Android是运行在容器中，无法使用Android自身的升级方案来进行升级。传统升级方案都是把容器和Android系统打包成一体后进行覆盖升级，但这种方式有如下几个问题无法解决：

一：容器加上Android系统的包很大，即便经过裁剪，升级包的占用空间也都是以G来计算的，如果仅仅改动Android很小的部分也需要升级的话，无论是对下载时间和下载带宽占用方面都会形成很大的浪费。

二：传统方案是属于全量升级方案，无法解决增量升级问题。也就是说，是无法做到只新增、替换或删除Android运行环境中某一个文件的，尤其当容器版本和Android系统版本存在一定的依赖关系时，很难做出取舍。

三：传统的升级方案是无法控制升级时间，也就是说只要触发升级无论终端用户是否在使用都需要终止工作进行完整升级，如何利用用户机器的空闲时间升级的策略是无法实现的。

四：传统的升级方案是不考虑升级异常进行升级回退的，也就是说一旦开始升级就是全部覆盖，如果覆盖过程中出现断电、死机等问题，意味着只能重装。

因此，我们需要一种精准、灵活、鲁棒的升级方案，在Linux系统侧实现一种新的升级方案，来替代传统方案。

发明内容

本发明所要解决的主要技术问题在于，

根据本发明一个方面，提供了一种在Linux上兼容运行的Android系统的升级方法，其中所述Android系统以容器方式兼容运行在Linux系统中，包括步骤：

S1：在容器Linux侧启动升级服务，所述升级服务创建升级守护进程，所述升级守护进程为Linux系统的Deamon守护进程服务；

S2：所述升级守护进程连接升级服务器，获取第一升级信息，所述第一升级信息包括所述Android系统的升级包及所述升级包的性质；

S3：所述升级守护进程根据所述第一升级信息执行升级过程，包括：

S31：依次关闭Android运行环境，包括Android应用，Android系统和Docker容器；

S32：备份当前Android运行环境文件为备份版本；

S33：比对所述升级包与所述当前Android运行环境文件，根据比对结果与所述升级包的性质对Android运行环境文件进行升级操作，所述升级操作包括删除文件，新增文件，覆盖文件。

S4：如执行S3异常，所述升级守护进程执行回滚至所述备份版本。

作为本发明的进一步改进，所述升级服务还创建升级GUI进程；所述升级GUI进程通过Socket连接所述升级守护进程，获取第一升级控制信息并显示于Linux用户界面上；所述升级GUI进程获取用户对升级的操作为第二升级控制信息，将所述第二升级控制信息发送至所述升级守护进程；所述升级守护进程根据所述第二升级控制信息执行升级控制。

作为本发明的进一步改进，所述升级包的性质包括：是否为强制升级，是否为增量升级包，是否为全量升级包。

作为本发明的进一步改进，所述第一升级控制信息包括升级通知信息和升级状态信息。

作为本发明的进一步改进，所述第二升级控制信息包括开始升级，停止升级，预设升级时间。

作为本发明的进一步改进，所述升级包的性质为强制升级时，所述用户对升级无法操作，不能生成所述第二升级控制信息。

根据本发明另一个方面，提供了一种在Linux上兼容运行的Android系统的升级装置，其中所述Android系统以容器方式兼容运行在Linux系统中，包括：

升级服务模块，所述升级服务模块位于所述容器Linux侧，所述升级服务模块创建升级守护进程模块；

升级服务器，所述升级服务器管理第一升级信息，所述第一升级信息包括所述Android系统的升级包及所述升级包的性质；

所述升级守护进程模块连接所述升级服务器，获取所述第一升级信息，根据所述第一升级信息执行升级过程，包括：

S32：备份当前Android运行环境文件为备份版本；

S33：比对所述第一升级信息与所述当前Android运行环境文件，根据比对结果对Android运行环境文件进行升级操作，所述升级操作包括删除文件，新增文件，覆盖文件。

如所述升级过程执行异常，所述升级守护进程执行回滚至所述备份版本。

作为本发明的进一步改进，所述升级服务模块还创建升级GUI进程模块；所述升级GUI进程模块通过Socket连接所述升级守护进程模块，获取第一升级控制信息并显示于Linux用户界面上；所述升级GUI进程模块获取用户对升级的操作为第二升级控制信息，将所述第二升级控制信息发送至所述升级守护进程模块；所述升级守护进程模块根据所述第二升级控制信息执行升级控制。

本发明的有益效果如下：

(1)升级以容器方式兼容运行在Linux系统中的Android系统时，可以只对Android系统进行升级，不需要把容器和Android系统打包成一体后进行覆盖升级。

(2)能够对以容器方式兼容运行在Linux系统中的Android系统进行增量升级，能够只新增、替换或删除Android运行环境中某一个文件。

(3)触发升级后，用户能够从Linux显示界面控制升级时间。

(4)升级异常时，系统可回退至升级前运行版本。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种在Linux上兼容运行的Android系统的升级方法的总体结构图；

图2示出了本发明实施例提供的一种在Linux上兼容运行的Android系统的升级方法的实现流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

可以理解的是，本发明的说明书和权利要求书及附图中的方法与装置中的相关特征可以相互参考。另外，本发明的说明书和权利要求书及附图中的“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

首先，在对本发明实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

容器技术：容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好的在孤立的组之间平衡有冲突的资源使用需求。

Docker：是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。

本发明要解决的核心技术问题为，当Android系统以容器的方式运行在Linux操作系统之上时，对Android系统的升级操作占用大量资源的问题。

针对上述技术问题，本发明提出一种在Linux上兼容运行的Android系统的升级方法与装置，在升级以容器方式兼容运行在Linux系统中的Android系统时，本发明的方法和装置能够只对Android系统进行升级，不需要把容器和Android系统打包成一体后进行覆盖升级；能够对以容器方式兼容运行在Linux系统中的Android系统进行增量升级，能够只新增、替换或删除Android运行环境中某一个文件；触发升级后，用户能够从Linux显示界面控制升级时间；升级异常时，系统可回退至升级前运行版本。

实施例1

图1为在Linux上兼容运行的Android系统的升级方法的总体结构图；

如图1所示，本方法主体实现框架分为三层：Linux桌面、Docker容器以及系统进程。其中：

Linux桌面主要用于显示升级过程，用户可以在Linux桌面通过升级GUI应用获取升级信息，干预升级过程；

Docker中主要运行Android系统，Android系统作为Android应用的运行主体，也是主要的升级对象；

Linux系统部分主要会启动两个进程：升级守护进程和升级GUI进程，其中升级守护进程是升级的主控进程，它负责创建Socket服务端，完成升级的主要流程控制，并同升级服务器通信获取相应升级信息；升级守护进程穿透Docker对Android系统中的文件进行增删改动作；升级GUI进程主要是创建Socket客户端接口，与Socket服务端连接获取升级守护进程的控制信息，并传递给升级GUI应用，同时把用户反馈的操作传递给升级守护进程，完成用户对升级的控制响应工作；

升级服务器主要用于升级策略和升级包的管理，并发送给升级守护进程。

图2示出了本发明实施例提供的一种在Linux上兼容运行的Android系统的升级方法的实现流程图，由图中可以看出在该实施例的方法中，具有以下步骤：

Android系统以容器方式兼容运行在Linux系统中；

S32：备份当前Android运行环境文件；

下面通过三个应用场景来具体说明本发明的实现步骤。

应用场景一：强制升级无用户干预

S1：在容器Linux侧启动升级服务，升级服务创建升级守护进程，升级守护进程为Linux系统的Deamon守护进程服务；

在Linux上启动升级服务，该服务会创建升级守护进程，并作为Linux系统的Deamon守护进程服务；

S2：升级守护进程连接升级服务器，获取第一升级信息，第一升级信息包括所述Android系统的升级包及所述升级包的性质；

升级守护进程会连接升级服务器，上报本地版本，获取第一升级信息，包括：是否有新版本，新版本是全量还是增量升级包，是否为强制升级；

升级守护进程自动下载升级包；

S3：升级守护进程根据第一升级信息执行升级过程，包括：

S31：升级守护进程依次关闭Android运行环境，包括Android应用、Android系统和Docker容器；

S32：备份当前Android运行环境文件；

S33：升级守护进程执行升级过程，依次为解压缩升级包→比对升级包当前Android系统的文件→删除不需要的文件→新增文件→覆盖文件，完成升级过程；

S4：如果S3执行正常，重启Docker容器→启动Android系统，升级成功；如果S3执行过程出现异常，升级守护进程执行回滚到备份版本，结束升级过程。

应用场景二：非强制升级用户干预

升级服务还创建升级GUI进程；升级GUI进程通过Socket连接升级守护进程；升级守护进程创建Socket服务端，升级GUI进程启动时自动注册为Socket客户端。

升级守护进程自动下载升级包；

升级包下载完毕后，在用户系统空闲时，升级守护进程通知升级GUI进程弹出升级GUI应用升级界面，升级GUI进程获取用户对升级的操作为第二升级控制信息，当第二升级控制信息为进入升级时，执行S3和S4；当第二升级控制信息为停止升级时，执行S6；当第二升级控制信息为设置升级时间时，升级守护进程等待至升级时间通知升级GUI进程弹出升级界面；

S3：升级守护进程根据第一升级信息执行升级过程，包括：

S32：备份当前Android运行环境文件；

S33：升级守护进程执行升级过程，依次为解压缩升级包→比对升级包当前Android系统的文件→删除不需要的文件→新增文件→覆盖文件，通知升级GUI进程，升级成功，完成升级工作；

S4：如果S3执行正常，重启Docker容器→启动Android系统；如果S3执行过程出现异常或者用户对升级的操作为停止升级时，则进行升级守护进程回滚到备份版本，结束升级过程并通知升级GUI进程，通过升级GUI应用通知用户升级失败；

S5：如果S4无法重启Android运行环境，则尝试重新执行S2、S3和S4，或者通知升级GUI进程，通知用户重启系统；

S6：升级进程停止。

应用场景三：强制升级用户干预

S2：升级守护进程连接升级服务器，获取第一升级信息，第一升级信息包括Android系统升级包及升级包的性质；

升级守护进程自动下载升级包；

升级包下载完毕后，在用户系统空闲时，升级守护进程通知升级GUI进程弹出升级GUI应用升级界面，在升级界面显示升级进度状态，该场景下，用户可以通过升级GUI应用查看升级进度状态，但无法控制升级进程；

S3：升级守护进程根据第一升级信息执行强制升级过程，包括：

S32：备份当前Android运行环境文件；

S4：如果S3执行正常，重启Docker容器→启动Android系统；如果S3执行过程出现异常或者用户中途通过升级GUI应用停止升级，则进行升级守护进程回滚到备份版本，结束升级过程并通知升级GUI进程，通过升级GUI应用通知用户升级失败；

S6：升级进程停止。

实施例2

进一步的，作为对上述实施例所示方法的实现，本发明另一实施例还提供了一种在Linux上兼容运行的Android系统的升级装置。该装置实施例与前述方法实施例对应，为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。在该实施例的装置中，具有以下模块：

一：升级服务模块，升级服务模块位于所述容器Linux侧，启动时创建升级守护进程模块和升级GUI进程模块；升级服务模块对应于实施1中的升级服务；

二：升级服务器，升级服务器管理第一升级信息，第一升级信息包括所述Android系统的升级包及升级包的性质；升级包的性质包括：是否为强制升级，是否为增量升级包，是否为全量升级包。

三：升级守护进程模块，升级守护进程模块连接升级服务器，获取第一升级信息；

四：升级GUI进程模块，升级GUI进程模块通过Socket连接所述升级守护进程模块，获取第一升级控制信息并显示于Linux用户界面上；升级GUI进程模块获取用户对升级的操作为第二升级控制信息，将第二升级控制信息发送至升级守护进程模块；

S3：当第二升级控制信息为停止升级时，执行S6；当第二升级控制信息为开始升级时，升级守护进程模块根据第一升级信息执行升级过程，包括：

S32：备份当前Android运行环境文件；

S5：如果S4无法重启Android运行环境，则尝试重新执行下载升级包、S3和S4，或者通过升级GUI应用通知用户重启系统；

S6：升级进程停止。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实装置施例的相关描述。

可以理解的是，上述方法和中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims

1.一种在Linux上兼容运行的Android系统的升级方法，其中所述Android系统以容器方式兼容运行在Linux系统中，其特征在于，包括：

S31：依次关闭Android运行环境，包括Android应用，Android系统和容器；

S32：备份当前Android运行环境文件为备份版本；

S33：比对所述升级包与所述当前Android运行环境文件，根据比对结果与所述升级包的性质对Android运行环境文件进行升级操作，所述升级操作包括删除文件，新增文件，覆盖文件；

S4：如S3执行正常，重启容器后启动Android系统，完成升级；如执行S3异常，所述升级守护进程执行回滚至所述备份版本，结束升级；

所述升级服务还创建升级GUI进程；所述升级GUI进程通过Socket连接所述升级守护进程，获取第一升级控制信息并显示于Linux用户界面上；所述升级GUI进程获取用户对升级的操作为第二升级控制信息，将所述第二升级控制信息发送至所述升级守护进程；所述升级守护进程根据所述第二升级控制信息执行升级控制。

2.一种如权利要求1所述的在Linux上兼容运行的Android系统的升级方法，其特征在于，所述升级包的性质包括：是否为强制升级，是否为增量升级包，是否为全量升级包。

3.一种如权利要求2所述的在Linux上兼容运行的Android系统的升级方法，其特征在于，所述第一升级控制信息包括升级通知信息和升级状态信息。

4.一种如权利要求1到3中任一项所述的在Linux上兼容运行的Android系统的升级方法，其特征在于，所述第二升级控制信息包括开始升级，停止升级、预设升级时间。

5.一种如权利要求1到3中任一项所述的在Linux上兼容运行的Android系统的升级方法，其特征在于，所述升级包的性质为强制升级时，所述用户对升级无法操作，不能生成所述第二升级控制信息。

6.一种在Linux上兼容运行的Android系统的升级装置，其中所述Android系统以容器方式兼容运行在Linux系统中，其特征在于，包括：

S32：备份当前Android运行环境文件为备份版本；

S33：比对所述第一升级信息与所述当前Android运行环境文件，根据比对结果对Android运行环境文件进行升级操作，所述升级操作包括删除文件，新增文件，覆盖文件；

如所述升级过程执行正常，重启容器后启动Android系统，完成升级；如所述升级过程执行异常，所述升级守护进程执行回滚至所述备份版本，结束升级；

所述升级服务模块还创建升级GUI进程模块；所述升级GUI进程模块通过Socket连接所述升级守护进程模块，获取第一升级控制信息并显示于Linux用户界面上；所述升级GUI进程模块获取用户对升级的操作为第二升级控制信息，将所述第二升级控制信息发送至所述升级守护进程模块；所述升级守护进程模块根据所述第二升级控制信息执行升级控制。

7.一种如权利要求6所述的在Linux上兼容运行的Android系统的升级装置，其特征在于，所述升级包的性质包括：是否为强制升级，是否为增量升级包，是否为全量升级包。

8.一种如权利要求7所述的在Linux上兼容运行的Android系统的升级装置，其特征在于，所述升级包的性质为强制升级时，所述用户对升级无法操作，不能生成所述第二升级控制信息。