CN113703926A

CN113703926A - Android容器创建方法与装置

Info

Publication number: CN113703926A
Application number: CN202111267217.5A
Authority: CN
Inventors: 王思远
Original assignee: Beijing Haiyudongxiang Technology Co ltd
Current assignee: Anhui Haima Cloud Technology Co ltd
Priority date: 2021-10-29
Filing date: 2021-10-29
Publication date: 2021-11-26
Anticipated expiration: 2041-10-29
Also published as: CN113703926B

Abstract

本申请提供了一种Android容器创建方法与装置、电子设备及存储介质，方法包括：获取Docker镜像以及Android容器运行需要的数据包，其中，所述Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成；基于所述Docker镜像以及数据包创建Android容器，其中，同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包，能够减少Docker镜像打包耗时以及对宿主机的存储空间消耗。

Description

Android容器创建方法与装置

技术领域

本发明涉及计算机技术领域，特别涉及一种Android容器创建方法与装置、电子设备及存储介质。

背景技术

Android系统是基于Linux系统发展而来，其内核仍然沿用标准Linux内核。Android系统的容器化方案通常使用Docker（一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，并可以发布到Linux系统中，以沙箱的形式相对独立运行）实现，不同的Android设备对Docker服务的支持能力不同，例如部分系统版本只能以虚拟文件系统vfs存储驱动形式运行容器，此种方式下在宿主机上创建容器时，首先会将Android系统打包成Docker镜像，利用Docker镜像创建容器，之后每创建一个容器都会拷贝一份Docker镜像内容来使用。这个过程中，一方面，Android系统大小通常在2G左右，会导致打包过程耗时较长；另一方面，在宿主机上所消耗的存储空间会随着容器数量的增多而线性增长，而通常这种打包方式产生的Docker镜像体积在1.5GB以上，当容器数量较多时，会极大耗费宿主机的存储空间。

因此，如何提供一种容器创建方案，以减少Docker镜像打包耗时以及对宿主机的存储空间消耗，成为亟待解决的技术问题。

发明内容

针对现有技术存在的技术问题，本申请实施例提供一种Android容器创建方法与装置、电子设备及存储介质。

第一方面，本申请实施例提供了一种Android容器创建方法，包括：

获取Docker镜像以及Android容器运行需要的数据包，其中，所述Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成；

基于所述Docker镜像以及数据包创建Android容器，其中，同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包。

第二方面，本申请实施例还提供了一种Android容器创建装置，包括：

获取单元，用于获取Docker镜像以及Android容器运行需要的数据包，其中，所述Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成；

创建单元，用于基于所述Docker镜像以及数据包创建Android容器，其中，同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包。

第三方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如第一方面所述的Android容器创建方法的步骤。

第四方面，本申请实施例还提供了一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如第一方面所述的Android容器创建方法的步骤。

综上，本申请实施例提供的Android容器创建方法与装置、电子设备及存储介质，指定Android容器运行的Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成，且Android容器运行需要的数据包，能够保证容器能够正常运行Android系统；在此基础上，一方面，仅将Android系统第一个用户态程序运行所需要的文件环境的最小集合打包成Docker镜像，而非将Android系统的全部内容打包成Docker镜像，从而相较于现有技术，能够减少Docker镜像打包耗时；另一方面，每创建一个容器需要拷贝的Docker镜像仅包含Android系统第一个用户态程序运行所需要的文件环境的最小集合，不包含Android系统的其它内容，且同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包，使得拷贝的Docker镜像内容大幅减少，且相同的数据包只需要存储一份即可满足不同容器运行需求，因而能够减少对宿主机的存储空间消耗。

附图说明

图1为本申请实施例提供的一种Android容器创建方法一实施例的流程示意图；

图2为本申请实施例提供的一种Android容器创建装置一实施例的结构示意图；

图3为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

参照图1所示，为本申请实施例提供的一种Android容器创建方法的流程示意图，该方法具体包括：

S10、获取Docker镜像以及Android容器运行需要的数据包，其中，所述Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成；

本实施例中，需要说明的是， Linux容器镜像通常会以某一个标准Linux发行版的镜像作为基础镜像，再叠加一些开发者集成修改的内容，并定义镜像启动后执行的入口程序。而Android系统与Linux系统启动和运行机制相差较大，使得Android容器镜像无法以标准Linux发行版镜像作为基础镜像，而必须完全自主构建镜像，并且需要正确定义Android容器镜像启动后执行的入口程序。

考虑到Docker的运行机制是宿主机系统与容器系统共用Linux内核，以命名空间进行隔离划分，那么Android容器镜像启动后执行的入口程序应该是Android系统第一个用户态程序，因此Android容器运行需要的最基本的内容是Android源码编译产生的Android系统第一个用户态程序运行所需要的文件环境的最小集合。将此内容指定为Android容器运行需要的Docker镜像，并配置合理的环境变量，定义镜像启动后执行的入口程序是Android系统第一个用户态程序，就完成了镜像最基本的构建配置。

显然，Android容器运行的Docker镜像中仅包含Android容器运行需要的最基本的内容，而最占用存储空间的、Android容器运行需要的其它内容（包括Android系统的本地程序、Java系统服务程序以及相应资源）不再打包进Android容器镜像中，使得Docker镜像体积大幅减少，从而能够提高Docker镜像打包效率。

S11、基于所述Docker镜像以及数据包创建Android容器，其中，同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包。

本实施例中，在创建Android容器时，需要将所述Docker镜像指定为Android容器运行的Docker镜像，并将Android容器运行需要的数据包（由Android容器运行需要的其它内容打包生成）通过只读的形式挂载到Android容器中对应的挂载点处。通过此方式，使得Android容器能够正常运行Android系统，并且避免了Docker镜像过大的问题。

本申请实施例提供的Android容器创建方法，指定Android容器运行的Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成，且Android容器运行需要的数据包，能够保证容器能够正常运行Android系统；在此基础上，一方面，仅将Android系统第一个用户态程序运行所需要的文件环境的最小集合打包成Docker镜像，而非将Android系统的全部内容打包成Docker镜像，从而相较于现有技术，能够减少Docker镜像打包耗时；另一方面，每创建一个容器需要拷贝的Docker镜像仅包含Android系统第一个用户态程序运行所需要的文件环境的最小集合，不包含Android系统的其它内容，且同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包，使得拷贝的Docker镜像内容大幅减少，且相同的数据包只需要存储一份即可满足不同容器运行需求，因而能够减少对宿主机的存储空间消耗。

在前述方法实施例的基础上，所述获取Docker镜像以及Android容器运行需要的数据包，可以包括：

从预设的第一存储服务器下载所述Docker镜像或者基于所述Android容器所在的宿主机的Android系统生成所述Docker镜像；以及

从预设的第二存储服务器下载所述数据包或者基于所述Android系统生成所述数据包。

本实施例中，需要说明的是，预设的第一存储服务器中可以存储至少一个版本的Android系统的按前述实施例所示方法生成的Docker镜像，则在宿主机中创建Android容器时，可以直接从所述第一存储服务器中下载需要的Docker镜像。预设的第二存储服务器中可以存储至少一个版本的Android系统对应的Android容器运行需要的数据包，则在宿主机中创建Android容器时，可以直接从所述第二存储服务器中下载Android容器运行需要的数据包。所述第一存储服务器和第二存储服务器可以是同一存储服务器，也可以是不同的存储服务器。通过设置存储服务器，使得在宿主机中创建Android容器时，可以从存储服务器中下载与宿主机版本不同的系统对应的Docker镜像和Android容器运行需要的数据包，继而可以基于下载的Docker镜像和Android容器运行需要的数据包创建出与宿主机系统版本不同的Android容器。

可以理解的是，如果Android容器的系统版本和宿主机的系统版本相同，则在宿主机中创建Android容器时，可以基于宿主机的Android系统生成Android容器运行需要的数据包，从而无需额外设置存储服务器来存储、维护占用存储巨大的数据包资源，极大节约了存储成本，而且不需要从存储服务器下载Android容器运行需要的数据包，能够减少下载耗时。另外，如果Android容器的系统版本和宿主机的系统版本相同，则在宿主机中创建Android容器时，也可以基于宿主机的Android系统生成所述Docker镜像，从而节省外部存储所述Docker镜像所占用的存储空间。

在前述方法实施例的基础上，所述基于所述Docker镜像以及数据包创建Android容器，可以包括：

采用overlay文件系统，将所述数据包作为lower层，空目录作为upper层，创建出所述Android容器的专有数据包；

将所述专有数据包挂载至所述Android容器中对应的挂载点处。

本实施例中，需要说明的是，对于同一宿主机中的不同容器，如果这些容器中存在系统对应的Android容器运行需要的数据包相同的容器，则这些容器复用Android容器运行需要的数据包。具体在创建Android容器时，可以采用overlay文件系统，针对每一个Android容器，都会将系统对应的Android容器运行需要的数据包作为下层lower层，空目录作为上层upper层，创建出该Android容器的专有数据包，并将所述专有数据包挂载至该Android容器中对应的挂载点处。这样，通过引入overlay文件系统，使得多个系统版本的Android容器可以共用一份Android容器运行需要的数据包，每个Android容器自身的修改则生成在overlay文件系统的upper层中，由此多个系统版本的Android容器所占用的存储空间与单个Android容器相差无几，从而可以大幅节省宿主机存储空间。

在前述方法实施例的基础上，将所述数据包作为第一数据包；

其中，所述基于所述Docker镜像以及数据包创建Android容器，可以包括：

获取所述数据包的差分升级数据包，并将所述差分升级数据包作为第二数据包；

采用overlay文件系统，将所述第一数据包作为lower层，所述第二数据包作为upper层，创建出所述Android容器的通用数据包；

采用overlay文件系统，将所述通用数据包作为lower层，空目录作为upper层，创建出所述Android容器的专有数据包；

将所述专有数据包挂载至所述Android容器中对应的挂载点处。

本实施例中，需要说明的是，对于同一宿主机中的不同容器，如果这些容器中存在系统对应的Android容器运行需要的数据包不相同的容器，则这些容器可以复用前一系统版本对应的Android容器运行需要的数据包。具体来说，在创建后一系统版本的Android容器时，可以采用overlay文件系统，将前一版本系统对应的Android容器运行需要的数据包作为lower层，后一版本系统相较于前一版本系统的差分升级数据包作为upper层，创建出后一系统版本的Android容器的通用数据包；并采用overlay文件系统，将所述通用数据包作为lower层，空目录作为upper层，创建出后一系统版本的Android容器的专有数据包；之后将所述专有数据包挂载至后一系统版本的Android容器中对应的挂载点处。通过此种方式，在每次创建Android容器时，如果该Android容器不是宿主机中第一个创建的Android容器，则不需要获取该Android容器的系统版本对应的Android容器运行需要的数据包，而只需获取该Android容器的系统版本相较于前一系统版本的差分升级数据包，则宿主机中需要存储的是前一系统版本对应的Android容器运行需要的数据包以及差分升级数据包，不需要存储各个版本系统对应的Android容器运行需要的数据包，从而能大幅节省宿主机的存储空间。另外，差分升级数据包可以存储在第三存储服务器中，便于创建Android容器时从第三存储服务器中下载需要的差分升级数据包及对数据包进行升级，且相较于存储全量数据包来说，能够节省第三存储服务器的存储空间。这样相较于下载全量数据包来说，可以大幅减少下载时间，便于对Android容器系统版本进行灵活、高效的升级。需要说明的是，所述第三存储服务器和第一存储服务器、第二存储服务器可以是同一存储服务器，也可以是不同的存储服务器。差分升级数据包是Android系统对应的Android容器运行需要的数据包的更新升级包，利用差分升级数据包对旧版本的Android系统对应的Android容器运行需要的数据包进行更新可以得到新版本的Android系统对应的Android容器运行需要的数据包。

在前述方法实施例的基础上，所述Android系统第一个用户态程序运行所需要的文件环境的最小集合，可以包括：Android系统源码编译产生的rootfs目录；

所述Android容器运行需要的数据包，可以包括：Android系统源码编译产生的system目录和vendor目录。

本实施例中，需要说明的是，Android容器镜像启动后执行的入口程序应该是Android系统第一个用户态程序，即/init程序。/init程序运行所需要的文件环境的最小集合是系统根目录rootfs，且/init程序本身也包含在rootfs中，因此容器镜像所需要最基本的内容是Android源码编译产生的rootfs目录，可以将rootfs目录指定为Android容器运行的Docker镜像。

Android系统启动的大致流程包括如下步骤：

（1）内核启动第一个用户态程序/init；

（2）/init程序解析大量*.rc文件，根据其中的配置，启动相应的本地服务和进程，例如服务管理器ServiceManager、Zygote进程等；

（3）Zygote进程启动后，会初始化资源，创建Java虚拟机，并创建出SystemServer进程；

（4）SystemServer进程会创建大量的Java层系统服务，包括活动管理器ActivityManagerService、窗口管理器WindowManagerService、电源管理器PowerManagerService、包管理器PackageManagerService等必须的系统服务。

可以看出，Android容器需要这些Android系统的本地程序和Java系统服务程序以及相应资源才能顺利运行。这些Android容器所必需的内容通常在Android源码编译产生的system目录和vendor目录中包含，因此设置所述Android容器运行需要的数据包包括：Android系统源码编译产生的system目录和vendor目录。这样，通过镜像与数据分离的方案，使得Android容器镜像仅包含前述实施例中基本构建配置产生的Docker镜像，而将system目录、vendor目录等Android容器运行需要的内容生成对应的数据包。在Android容器创建时，除了指定运行的Docker镜像以外，还需要将数据包通过只读的形式挂载到容器对应的rootfs中的挂载点下，即将数据包中的system目录挂载到容器的/system处，数据包中的vendor目录挂载到容器的/vendor处。

下面通过具体的例子说明本发明的Android容器创建过程。

假设宿主机的Android系统版本是版本A，在宿主机中需要创建3个Android容器，分别为C1、C2和C3，且容器C1、C2和C3的系统版本分别为B1、B2和B3，版本B1、B2和B3，均与版本A不同，且B1和B3版本Android系统对应的Docker镜像相同，且与B2版本Android系统对应的Docker镜像不同。第一存储服务器中存储有B1版本Android系统对应的Docker镜像（以下记为“B1镜像”）、B1版本Android系统对应的Android容器运行需要的数据包（以下记为“B1数据包”）、B2版本Android系统对应的Docker镜像（以下记为“B2镜像”），以及B2版本相较于B1版本的差分升级数据包（以下记为“B21差分包”）、B3版本相较于B2版本的差分升级数据包（以下记为“B32差分包”）。

则创建容器C1的过程包括如下步骤：

（a11）从第一存储服务器中下载 B1镜像和B1数据包，加载 B1镜像，并解压缩B1数据包到指定目录，作为容器C1的通用数据包；

（a12）在容器C1创建前，使用overlay文件系统，以步骤（a11）中的通用数据包作为lower层，空目录作为upper层，创建出容器C1的专有数据包；

（a13）在容器C1创建时，将容器C1的专有数据包挂载至容器C1中对应挂载点处。

创建容器C2的过程包括如下步骤：

（a21）从第一存储服务器中下载 B2镜像和B21差分包，加载 B2镜像，并解压缩B21差分包到指定目录；

（a22）在容器C2创建前，使用overlay文件系统，以步骤（a11）中的B1数据包作为lower层，步骤（a21）中的B21差分包作为upper层，创建出容器C2的通用数据包；

（a23）在容器C2创建前，使用overlay文件系统，以步骤（a22）中的通用数据包作为lower层，空目录作为upper层，创建出容器C2的专有数据包；

（a24）在容器C2创建时，将容器C2的专有数据包挂载至容器C2中对应挂载点处。

创建容器C3的过程包括如下步骤：

（a31）从第一存储服务器中下载B32差分包，解压缩到指定目录，并拷贝一份步骤（a11）下载的 B1镜像，加载 B1镜像；

（a32）在容器C3创建前，使用overlay文件系统，以步骤（a11）中的B1数据包作为lower层，步骤（a21）中的B21差分包作为upper层，创建出第一通用数据包；

（a33）在容器C3创建前，使用overlay文件系统，以步骤（a32）中的第一通用数据包作为lower层，步骤（a31）中的B32差分包作为upper层，创建出第二通用数据包，作为容器C3的通用数据包；

（a34）在容器C3创建前，使用overlay文件系统，以步骤（a33）中创建的通用数据包作为lower层，空目录作为upper层，创建出容器C3的专有数据包；

（a35）在容器C3创建时，将容器C3的专有数据包挂载至容器C3中对应挂载点处。

参照图2所示，为本申请实施例提供的一种Android容器创建装置的结构示意图，该装置具体包括：

获取单元20，用于获取Docker镜像以及Android容器运行需要的数据包，其中，所述Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成；

创建单元21，用于基于所述Docker镜像以及数据包创建Android容器，其中，同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包。

本申请实施例提供的Android容器创建装置，指定Android容器运行的Docker镜像基于Android系统第一个用户态程序运行所需要的文件环境的最小集合打包生成，且Android容器运行需要的数据包，能够保证容器能够正常运行Android系统；在此基础上，一方面，仅将Android系统第一个用户态程序运行所需要的文件环境的最小集合打包成Docker镜像，而非将Android系统的全部内容打包成Docker镜像，从而相较于现有技术，能够减少Docker镜像打包耗时；另一方面，每创建一个容器需要拷贝的Docker镜像仅包含Android系统第一个用户态程序运行所需要的文件环境的最小集合，不包含Android系统的其它内容，且同一宿主机的不同Android容器在创建时复用Android容器运行需要的数据包，使得拷贝的Docker镜像内容大幅减少，且相同的数据包只需要存储一份即可满足不同容器运行需求，因而能够减少对宿主机的存储空间消耗。

在前述装置实施例的基础上，所述获取单元，可以用于：

在前述装置实施例的基础上，所述创建单元，可以用于：

将所述专有数据包挂载至所述Android容器中对应的挂载点处。

如图3所示，本申请实施例提供的一种电子设备，包括：处理器30、存储器31和总线32，所述存储器31存储有所述处理器30可执行的机器可读指令，当电子设备运行时，所述处理器30与所述存储器31之间通过总线32通信，所述处理器30执行所述机器可读指令，以执行如上述Android容器创建方法的步骤。

具体地，上述存储器31和处理器30能够为通用的存储器和处理器，这里不做具体限定，当处理器30运行存储器31存储的计算机程序时，能够执行上述Android容器创建方法。

对应于上述Android容器创建方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述Android容器创建方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims

1.一种Android容器创建方法，其特征在于，包括：

2.如权利要求1所述的方法，其特征在于，所述获取Docker镜像以及Android容器运行需要的数据包，包括：

3.如权利要求2所述的方法，其特征在于，所述基于所述Docker镜像以及数据包创建Android容器，包括：

将所述专有数据包挂载至所述Android容器中对应的挂载点处。

4.如权利要求2所述的方法，其特征在于，将所述数据包作为第一数据包；

其中，所述基于所述Docker镜像以及数据包创建Android容器，包括：

将所述专有数据包挂载至所述Android容器中对应的挂载点处。

5.如权利要求1至4任一项所述的方法，其特征在于，所述Android系统第一个用户态程序运行所需要的文件环境的最小集合，包括：Android系统源码编译产生的rootfs目录；

所述Android容器运行需要的数据包，包括：Android系统源码编译产生的system目录和vendor目录。

6.一种Android容器创建装置，其特征在于，包括：

7.如权利要求6所述的装置，其特征在于，所述获取单元，用于：

8.如权利要求7所述的装置，其特征在于，所述创建单元，用于：

将所述专有数据包挂载至所述Android容器中对应的挂载点处。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如权利要求1至5任一项所述的Android容器创建方法的步骤。

10.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至5任一项所述的Android容器创建方法的步骤。