Containerized multi-instance management method and related equipment

Abstract

The invention discloses a containerized multi-instance management method and related equipment, and relates to the technical field of computer virtualization, and the method comprises the following steps: obtaining hardware architecture information of a host system and configuration parameters of a containerized engine; based on the hardware architecture information and the configuration parameters, deploying a containerized engine to support operation of a plurality of Android instances on a single chip, each Android instance being configured with an independent data storage directory and an attribute file, the attribute file being used for covering Android system attributes; based on a preset network mode type, a network resource allocation strategy of each Android instance is determined, and the network mode type comprises a shared network mode or an independent network mode; and in response to the instance management instruction, carrying out life cycle operation on the Android instance so as to realize resource isolation and independent operation of multiple instances.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer virtualization, and in particular to a containerized multi-instance management method and related equipment. BACKGROUND

[0002] With the rapid development of mobile Internet technology, the application scenarios of Android system in smart devices are increasingly diversified, such as smart home, vehicle terminal and industrial control, etc. Under this background, a single hardware platform needs to run multiple independent Android instances simultaneously to meet different functional requirements or improve resource utilization. However, the traditional virtualization technology has the problem of insufficient compatibility when adapting to specific hardware architecture, and it is difficult to fully exert the hardware performance. In addition, the existing solutions generally lack flexibility in multi-instance management, the resource isolation between instances is poor, and the network configuration mode is single, which is difficult to meet the diversified needs of instance communication or isolation in complex scenarios. Therefore, there is an urgent need for a containerized multi-instance management method to solve the above-mentioned technical problems. SUMMARY

[0003] A series of simplified concepts are introduced in the summary section, which will be further described in detail in the specific embodiments section. The summary section of the present application does not mean to attempt to limit the key features and necessary technical features of the claimed technical solutions, nor to attempt to determine the protection scope of the claimed technical solutions.

[0004] In a first aspect, the present application provides a containerized multi-instance management method, comprising:

[0005] obtaining hardware architecture information of a host system and configuration parameters of a containerization engine;

[0006] based on the hardware architecture information and the configuration parameters, deploying the containerization engine to support running multiple Android instances on a single chip, wherein each Android instance is configured with an independent data storage directory and an attribute file, and the attribute file is used to override the Android system attributes;

[0007] based on a preset network mode type, determining a network resource allocation strategy for each Android instance, wherein the network mode type includes a shared network mode or an independent network mode;

[0008] in response to an instance management instruction, performing a lifecycle operation on the Android instance to realize resource isolation and independent running of the multiple instances.

[0009] In some embodiments, obtaining the hardware architecture information of the host system and the configuration parameters of the containerization engine comprises:

[0010] Obtaining a hardware architecture identifier and chip feature parameters based on a firmware interface of a host system;

[0011] Determining a containerized engine type and version constraint condition matched with the hardware architecture identifier based on a preset configuration rule library;

[0012] Generating configuration parameters of the containerized engine based on the chip feature parameters and the version constraint condition, wherein the configuration parameters include an image loading path, a resource quota limit, and a kernel module dependency.

[0013] In some embodiments, based on the hardware architecture information and the configuration parameters, the containerized engine is deployed to support running multiple Android instances on a single chip, including:

[0014] Loading an Android image matched with the hardware architecture identifier based on the image loading path;

[0015] Allocating independent CPU core numbers, memory capacities, and storage spaces for each Android instance based on the resource quota limit to generate an instance resource isolation strategy;

[0016] Initializing kernel virtualization modules and network driver modules of the containerized engine based on the kernel module dependency to establish a running basis of a container instance;

[0017] Creating multiple Android instances in the containerized engine based on the instance resource isolation strategy, wherein each Android instance is bound with an independent data storage directory and an attribute file;

[0018] Overriding Android system attributes based on the attribute file to adapt to the running requirements of the single-chip multiple-instance.

[0019] In some embodiments, based on a preset network mode type, a network resource allocation strategy of each Android instance is determined, including:

[0020] When the preset network mode type is a shared network mode, the network resource allocation strategy of the Android instance is determined as a shared IP address allocation strategy, wherein the shared IP address allocation strategy includes sharing an IP address of the host system with the Android instance, and generating an external access interface based on a preset port mapping rule;

[0021] When the preset network mode type is an independent network mode, the network resource allocation strategy of the Android instance is determined as an independent network parameter configuration strategy, wherein the independent network parameter configuration strategy includes allocating independent MAC addresses and IP addresses for the Android instance, and defining gateway, DNS, and routing rules based on a container network interface plug-in.

[0022] In some embodiments, in response to the instance management instruction, a lifecycle operation is performed on the Android instance, including:

[0023] Based on the type identifier of the instance management instruction, a target Android instance and a target operation type are determined;

[0024] Based on the data storage directory and the attribute file associated with the target Android instance, the instance running state parameters are parsed;

[0025] When the target operation type is a start operation, based on the instance resource isolation strategy and the network parameter configuration strategy, instance start parameters are generated, and an instance start command is executed through a containerization engine interface;

[0026] When the target operation type is a stop operation, based on the process identifier in the instance running state parameters, an instance stop command is generated and the running process of the target Android instance is terminated;

[0027] When the target operation type is a delete operation, based on the path identifier of the data storage directory, the storage resources of the target Android instance are released and the associated containerized instance configuration is removed.

[0028] In some embodiments, further comprising:

[0029] In response to a version upgrade request of the container engine, based on the hardware architecture information of the host system and the upgraded container engine installation package, a target container engine version is determined;

[0030] Based on the target container engine version, all currently running Android instances are deleted and the associated data storage directory and attribute file are retained;

[0031] Based on the path identifier of the data storage directory and the configuration parameters of the attribute file, an Android instance is recreated through the upgraded container engine interface to load the retained data storage directory and attribute file, and the instance running state is restored.

[0032] In some embodiments, further comprising:

[0033] Based on the resource quota limit, the CPU core occupancy rate and the memory capacity usage rate of each Android instance are collected in real time;

[0034] Based on a preset resource threshold rule library, a first resource over-limit state corresponding to the CPU core occupancy rate and a second resource over-limit state corresponding to the memory capacity usage rate are determined;

[0035] When the first resource over-limit state or the second resource over-limit state meets a preset adjustment condition, a new CPU core quota or a memory capacity quota is generated based on a dynamic resource allocation algorithm.

[0036] update the resource quota limit based on the new CPU core quota or memory capacity quota to optimize resource allocation of the single-chip hardware platform.

[0037] In a second aspect, the application provides a containerized multi-instance management apparatus, comprising:

[0038] a configuration parameter acquisition unit configured to acquire hardware architecture information of a host system and configuration parameters of a containerized engine;

[0039] a plurality of instance deployment units configured to deploy the containerized engine based on the hardware architecture information and the configuration parameters to support running a plurality of Android instances on a single chip, wherein each Android instance is configured with an independent data storage directory and an attribute file, and the attribute file is used to override Android system attributes;

[0040] an allocation strategy determination unit configured to determine a network resource allocation strategy for each Android instance based on a preset network mode type, wherein the network mode type includes a shared network mode or an independent network mode;

[0041] a lifecycle operation unit configured to perform lifecycle operations on the Android instances in response to instance management instructions to achieve resource isolation and independent running of the multi-instances.

[0042] In a third aspect, an electronic device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to implement the steps of the containerized multi-instance management method of any one of the first aspect when executing the computer program stored in the memory.

[0043] In a fourth aspect, the application provides a computer-readable storage medium storing a computer program, wherein the computer program is executable by a processor to implement the containerized multi-instance management method of any one of the first aspect.

[0044] In summary, the application acquires hardware architecture information of a host system and configuration parameters of a containerized engine, deploys an adapted containerized engine to support efficient running of a plurality of Android instances on a single chip. Each instance is configured with an independent data storage directory and an attribute file to achieve resource isolation and personalized attribute override, effectively improving hardware resource utilization and system stability. Network resources are allocated flexibly based on a preset network mode type to meet communication needs in different scenarios. Lifecycle operations are performed in response to instance management instructions to simplify the management process of multi-instances, ensure independent running and dynamic adjustment of the instances, and improve the efficiency and flexibility of multi-instance management. BRIEF DESCRIPTION OF DRAWINGS

[0045] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments with reference made to the accompanying drawings. The drawings are for purposes of illustration only and are not intended to be limiting in

[0046] Figure 1 A containerized multi-instance management method flowchart provided by an embodiment of the present application;

[0047] Figure 2 A containerized multi-instance management device structure schematic diagram provided by an embodiment of the present application;

[0048] Figure 3 A containerized multi-instance management electronic device structure schematic diagram provided by an embodiment of the present application. DETAILED DESCRIPTION

[0049] The terms "first", "second", "third", "fourth" and the like in the description and in the claims of the present application, if any, are used for distinguishing between similar objects talking about the embodiments and not necessarily for describing a specific sequential or chronological order. It is to be understood that the use of these terms herein is to be construed as interchangeable in order to describe the embodiments disclosed herein. Furthermore, the terms "comprise", "comprising", "include", "including", and the like, if any, are used synonymously to denote or describe the presence of stated features, integers, steps, actions, actions, elements, or components, and / or the like, but do not preclude the presence or addition of one or more other features, integers, steps, actions, actions, elements, components, and / or the like. In the following description of embodiments, various aspects, advantageous features and embodiments of the application are explained with reference to the drawings, wherein:

[0050] Reference will now be made to Figure 1 A containerized multi-instance management method flowchart provided by an embodiment of the present application, specifically can include:

[0051] S110, obtaining hardware architecture information of a host system and configuration parameters of a containerization engine;

[0052] Exemplarily, the step S110 provides a basis for the deployment of the containerization engine by obtaining the hardware architecture information of the host system. The hardware architecture information covers key features such as chip type, instruction set architecture, and memory distribution, ensuring that the containerization engine can be optimally configured for a specific hardware environment, thereby fully exploiting the performance potential of the single-chip platform. The purpose of this step is to solve the problem of insufficient hardware adaptation of traditional virtualization technology and provide stable and efficient underlying support for multi-instance running.

[0053] Further, the configuration parameters of the containerization engine are generated based on the dynamic matching of the hardware architecture information and preset rules. By filtering the types and versions of the containerization engine compatible with the hardware identifier through the preset configuration rule library, and combining the chip feature parameters to generate key parameters such as image loading path and resource quota limit, this process ensures that the containerization engine is deployed to accurately adapt to the target hardware, laying a foundation for subsequent resource isolation and independent running of multiple instances.

[0054] S120, based on the hardware architecture information and the configuration parameters, deploying the containerization engine to support running multiple Android instances on a single chip, wherein each Android instance is configured with an independent data storage directory and an attribute file, and the attribute file is used to override the Android system attributes;

[0055] Exemplarily, the step S120 deploys a customized containerization engine by dynamically adapting the hardware architecture features of the host system, providing core support for efficient running of multiple Android instances on a single-chip platform. Based on the hardware architecture information and the configuration parameters, the containerization engine initializes the virtualization environment and loads the adapted Android image, ensuring that the instance running is deeply coordinated with the hardware resources. By allocating an independent data storage directory to each instance, physical isolation of storage resources between instances is achieved, avoiding data conflicts; at the same time, the attribute file overrides the original attributes of the Android system in a standardized format, so that each instance can independently configure system parameters to meet the individual needs of different business scenarios.

[0056] Further, the containerization engine builds the underlying environment for multi-instance running through the initialization of the kernel virtualization module and the network driver module. Based on the resource quota limit, the CPU core number, memory capacity, and other hardware resources are dynamically allocated to each instance, forming an instance resource isolation strategy to ensure intelligent control of resource competition between multiple instances. The mounting and permission control of the attribute file further ensure the security of the configuration data, preventing unauthorized tampering. This deployment mechanism not only solves the problem of insufficient hardware adaptation in traditional solutions, but also provides a unified technical framework for stable running and flexible management of multiple instances.

[0057] S130, determine a network resource allocation strategy of each Android instance based on a preset network mode type, wherein the network mode type comprises a shared network mode or an independent network mode;

[0058] For example, step S130 dynamically adapts the communication requirements of the instance through the preset network mode type, and realizes flexible network resource configuration. In the shared network mode, the instance shares the IP address with the host system, and provides an access interface to the outside through the port mapping rule, which is suitable for scenarios that need to closely cooperate with the host system or share network resources. In the independent network mode, the instance is allocated an independent MAC address and IP address, and the gateway, DNS and routing rules are defined through the container network interface plug-in to realize network layer isolation and meet the needs of independent network configuration or strict isolation in complex scenarios. The dynamic selection of the two modes provides differentiated network support capabilities for multiple instances.

[0059] Further, the generation of the network resource allocation strategy is based on the efficient matching of the preset rules and actual needs. By analyzing the network mode type, the system automatically triggers the corresponding configuration process: the shared mode prioritizes the communication efficiency between instances to simplify network management; the independent mode constructs a dedicated network environment for the instance through virtualization technology to avoid IP conflicts and resource preemption. This strategy not only solves the problem of rigid network configuration in traditional solutions, but also optimizes the network resource utilization of single-chip platforms through a dynamic allocation mechanism, ensuring the stable operation and efficient interaction of multiple instances in complex scenarios.

[0060] S140, in response to an instance management instruction, performing a lifecycle operation on the Android instance to realize resource isolation and independent running of multiple instances.

[0061] For example, step S140 dynamically triggers the creation, start, stop or delete operation of the target Android instance by analyzing the type identifier of the instance management instruction. Based on the instance resource isolation strategy and network parameter configuration strategy, the system allocates independent hardware resources and network environment for each instance, ensuring that the CPU core number, memory capacity and storage space between instances are physically isolated to avoid resource competition. At the same time, by binding independent data storage directories and attribute files, the independence of instance running state and configuration parameters is guaranteed, realizing fine-grained control of multiple instances from the bottom.

[0062] Further, the lifecycle operation is deeply coordinated with the resource isolation mechanism to ensure the stability of the instance running environment. When executing the start or stop instruction, the system dynamically adjusts the resource allocation according to the instance running state parameters, and controls the lifecycle of the instance process through the containerization engine interface; the delete operation releases the storage resources and removes the configuration information based on the path identifier, and completely eliminates the residual impact. This mechanism not only realizes the on-demand dynamic scheduling of multiple instances, but also ensures the safe and independent running of each instance on the single-chip platform through strict resource isolation and permission control.

[0063] In summary, the embodiments of the present application efficiently deploy a virtualization environment supporting multiple Android instance running on a single-chip platform by obtaining the hardware architecture information of the host system and generating adaptive containerization engine configuration parameters, improving hardware resource utilization and system stability. Each instance is configured with an independent data storage directory and attribute file, realizing physical-level resource isolation and personalized system attribute coverage, effectively avoiding data conflicts and parameter interference, and meeting the customized needs of different business scenarios. Based on the preset network mode, shared or independent network resources are dynamically allocated to support flexible communication or strict isolation between instances, solving the problem of rigid network configuration in traditional solutions. By responding to instance management instructions to perform lifecycle operations, the creation, start, stop and delete processes of multiple instances are simplified, ensuring the independent controllability and dynamic adjustment capability of the running state of each instance. The embodiments of the present application realize efficient cooperation and fine management of multiple instances on a single-chip platform, taking into account performance optimization, security isolation and operation convenience, providing reliable technical support for complex scenarios such as intelligent terminals and industrial control.

[0064] In some examples, obtaining the hardware architecture information of the host system and the configuration parameters of the containerization engine includes:

[0065] Based on the firmware interface of the host system, the hardware architecture identifier and the chip feature parameters are obtained;

[0066] Based on the preset configuration rule library, the containerization engine type and version constraint condition matched with the hardware architecture identifier are determined;

[0067] Based on the chip feature parameters and the version constraint condition, the configuration parameters of the containerization engine are generated, wherein the configuration parameters include the image loading path, the resource quota limit and the kernel module dependency.

[0068] For example, the hardware architecture identifier and chip feature parameters are extracted by calling a preset hardware information query interface in the host system firmware interface. The hardware architecture identifier is used to uniquely identify the chip architecture type of the host system, such as ARMv8, x86_64, etc.; the chip feature parameters include but are not limited to CPU core number, memory capacity, storage bandwidth, instruction set extension support capability, etc. By directly accessing the firmware layer data, the hardware information obtained has high precision and real-time, which provides accurate basis for the subsequent adaptation and deployment of the containerization engine.

[0069] The containerization engine type and version constraint conditions matching the hardware architecture identifier are determined based on a preset configuration rule library. The preset configuration rule library stores the mapping relationship between the hardware architecture identifier and the containerization engine type and version. By matching the hardware architecture identifier with the entries in the rule library, the compatible containerization engine type (such as Docker, Kata Containers, etc.) and its supported version range (such as Docker 20.10.x and above) are filtered out. At the same time, combined with the instruction set extension support capability in the chip feature parameters, the containerization engine version that meets the hardware specific function is further filtered out, such as the engine version that supports ARM TrustZone security extension. This step ensures that the selected containerization engine is deeply adapted to the hardware characteristics of the host system in terms of function and performance through rule matching and dynamic filtering.

[0070] According to the CPU core number, memory capacity and storage bandwidth in the chip feature parameters, the resource quota limit of the containerization engine is dynamically calculated, including the upper limit of the CPU core number, the upper limit of the memory capacity and the upper limit of the storage space allocated for each Android instance. At the same time, based on the containerization engine type and version specified in the version constraint condition, the corresponding image loading path is generated, such as loading the Android system image matching the hardware architecture identifier from the preset image repository. In addition, combined with the kernel module support capability in the chip feature parameters, the kernel module dependencies required by the containerization engine are determined, such as KVM virtualization module, OverlayFS storage driver module, etc. The finally generated configuration parameters cover image loading path, resource quota limit and kernel module dependency, which provide complete configuration guidance for the deployment and multi-instance running of the containerization engine.

[0071] In summary, the embodiment of the present application accurately obtains the hardware architecture identifier and chip feature parameters by calling the host system firmware interface, ensuring the deployment of the containerization engine and the deep adaptation of the hardware environment. Based on the preset configuration rule library, dynamically match the compatible containerization engine type and version constraint conditions, combined with the chip instruction set extension capability, filter out the engine version that supports specific hardware functions, effectively solve the performance bottleneck caused by insufficient hardware adaptation in traditional solutions. Through dynamic calculation of resource quota limits based on chip feature parameters, allocate independent CPU core number, memory capacity and storage space upper limit for each Android instance, realize intelligent control of resource competition among multiple instances. At the same time, generate an image loading path and kernel module dependencies that match the hardware architecture, ensure that the containerization engine loads the adapted Android image and activates the necessary virtualization modules during initialization, and build a stable and efficient underlying environment for multi-instance running. The final generated configuration parameters cover image path, resource quota and kernel dependencies, forming a complete deployment guidance framework, providing efficient and reliable technical support for single-chip platform multi-instance management.

[0072] In some examples, based on the hardware architecture information and the configuration parameters, a containerization engine is deployed to support running multiple Android instances on a single chip, including:

[0073] Based on the image loading path, load the Android image matching the hardware architecture identifier;

[0074] Based on the resource quota limit, allocate independent CPU core number, memory capacity and storage space for each Android instance, and generate instance resource isolation strategy;

[0075] Based on the kernel module dependencies, initialize the kernel virtualization module and network driver module of the containerization engine to establish the running foundation of the container instance;

[0076] Based on the instance resource isolation strategy, create multiple Android instances in the containerization engine, wherein each Android instance is bound to an independent data storage directory and attribute file;

[0077] Based on the attribute file, override the Android system attributes to adapt to the running requirements of single-chip multi-instance.

[0078] For example, based on the image loading path in the configuration parameter, an Android image matching the hardware architecture identifier is loaded from the preset image repository. The image loading path is dynamically generated according to the hardware architecture identifier of the host system, for example, for a host system with an ARMv8 architecture, the image loading path points to an Android image file adapted to the ARMv8 instruction set. By verifying the digital signature and integrity hash value of the image file, it is ensured that the loaded image is fully compatible with the target hardware architecture. During the loading process, the containerization engine decompresses the image to the specified storage area of the host system and initializes the root file system of the image, providing a standardized Android running environment for subsequent instance creation and running.

[0079] Based on the resource quota limit (such as CPU core upper limit, memory capacity upper limit, and storage space upper limit) in the configuration parameter, an independent CPU core number, memory capacity, and storage space are allocated to each Android instance. The resource quota limit is dynamically calculated according to the chip feature parameters of the host system, for example, the exclusive core number of each instance is allocated according to the total CPU core number, or the memory upper limit of each instance is set according to the total memory capacity. The containerization engine generates an instance resource isolation strategy based on the allocation result, which clearly limits the physical resource range accessible by each instance, including CPU scheduling priority, memory access permission, and storage space quota. The above strategy realizes resource isolation through the cgroups mechanism of the Linux kernel, ensuring fine control of resource competition between multiple instances and avoiding performance degradation caused by resource preemption.

[0080] Based on the kernel module dependencies in the configuration parameter, the virtualization modules and network driver modules required by the containerization engine are loaded and initialized. The kernel module dependencies include KVM virtualization modules, OverlayFS storage driver modules, and macvlan network driver modules. For example, for a start ARM array server, the KVM module adapted to the ARM architecture is loaded to realize hardware-assisted virtualization and improve instance running efficiency; the OverlayFS module is initialized to support joint mounting of container images, realizing fast deployment and isolation of instance storage; the macvlan driver module is activated to support subsequent configuration of independent network mode. The initialization of the kernel module is completed by executing the preset modprobe command, ensuring that the module loading sequence and parameter configuration meet the running requirements of the target hardware architecture.

[0081] The containerization engine invokes a container creation interface to generate multiple Android instances according to an instance resource isolation policy. Each instance is assigned a unique container identifier and is bound to an independent data storage directory and property file when created. The path of the data storage directory is generated according to a preset naming rule, for example, the path " / data / cce / data / c1" is assigned to instance 1 and the path " / data / cce / data / c2" is assigned to instance 2. The directory stores private data of the instance, including application data, temporary files, and runtime logs, to ensure physical isolation of data between different instances. The property file adopts a prop format (for example, build.prop) recognizable by the Android system, and the file defines custom parameters that override the native system properties of the Android system, such as device model, screen resolution, and network configuration. The property file is mounted to a specified path (for example, / system / etc / ) of the instance, and the access property is set to 600 by the permission control module to prevent unauthorized tampering.

[0082] Based on the custom parameters defined in the property file, the native properties of the Android system are overridden. The containerization engine injects the parameters in the property file into the property service of the Android system when the instance is started, for example, the ro.product.model property in the property file is modified to identify the unique device model of the instance, or the persist.sys.display.resolution property is adjusted to adapt to the display requirements of different instances. The property override process is implemented by mounting a read-only file system (such as tmpfs), ensuring that the modification only takes effect during the runtime of the instance and does not affect the configuration of the host system or other instances. This mechanism enables each Android instance to independently configure system parameters, meets the differentiated business requirements in the multi-instance scenario, and maintains the stability of the host system environment.

[0083] In summary, the embodiments of the present application construct an efficient and secure multi-Android instance running environment on a single-chip platform through the synergistic effect of image loading, resource allocation, kernel initialization, instance creation, and property configuration. Each instance realizes double isolation at the physical and logical levels through independent resource quotas, data storage directories, and property files, ensuring the independence and stability of the instances. The initialization of the kernel virtualization module and the network driver further optimizes the performance and network flexibility of the instances, providing reliable technical support for complex application scenarios.

[0084] In some instances, based on a preset network mode type, a network resource allocation strategy for each Android instance is determined, including:

[0085] When the preset network mode type is the shared network mode, the network resource allocation strategy of the Android instance is determined as a shared IP address allocation strategy, where the shared IP address allocation strategy comprises sharing an IP address of the host system with the Android instance, and generating an external access interface based on a preset port mapping rule;

[0086] When the preset network mode type is the independent network mode, the network resource allocation strategy is determined as an independent network parameter configuration strategy, and the independent network parameter configuration strategy comprises allocating an independent MAC address and an IP address for the Android instance, and defining a gateway, a DNS, and a routing rule based on a container network interface plug-in.

[0087] For example, when the preset network mode type is the shared network mode, the network resource allocation strategy of the Android instance is determined as a shared IP address allocation strategy. Specifically, the shared IP address allocation strategy comprises sharing an IP address of the host system with the Android instance, and generating an external access interface through a preset port mapping rule. The IP address of the host system serves as a public network identifier, which is shared by all the Android instances using the shared network mode. To avoid port conflicts, the preset port mapping rule dynamically allocates external access ports according to instance identifiers. For example, the HTTP service port 80 of instance 1 is mapped to the 8080 port of the host system, and the same service port of instance 2 is mapped to the 8081 port. This strategy forwards the network requests of the instances through the network stack of the host system, realizes sharing the same IP address between the instances but distinguishing the services through different ports, is suitable for scenarios requiring close cooperation with the host system or simplifying external access, reduces the occupation of IP resources, and effectively simplifies network configuration and improves communication efficiency.

[0088] When the preset network mode type is the independent network mode, the network resource allocation strategy of the Android instance is determined as an independent network parameter configuration strategy. Specifically, the independent network parameter configuration strategy comprises allocating a globally unique MAC address and an independent IP address for each Android instance, and defining complete network parameters through a container network interface plug-in. The container network interface plug-in creates a virtual sub-interface based on a physical network interface of the host system, binds the virtual sub-interface for each instance, and configures an independent IP address, a subnet mask, and a default gateway. Meanwhile, the container network interface plug-in defines a DNS server address and a custom routing rule of the instance, for example, routes the traffic of a specific network segment to a specified gateway. Each instance has an independent network identity and communication link, and the network traffic between the instances is isolated through the virtual sub-interface, avoiding IP conflicts and resource preemption. The independent network mode is suitable for scenarios requiring strict network isolation or independent network configuration, such as multi-tenant environments or security-sensitive applications, ensuring that the network behavior of the instances is completely independent and controllable.

[0089] In some examples, in response to the instance management instruction, a lifecycle operation is performed on the Android instance, including:

[0090] Based on the type identifier of the instance management instruction, a target Android instance and a target operation type are determined;

[0091] Based on the data storage directory and the attribute file associated with the target Android instance, the instance running state parameters are parsed;

[0092] When the target operation type is a start operation, based on the instance resource isolation strategy and the network parameter configuration strategy, instance start parameters are generated, and an instance start command is executed through a containerization engine interface;

[0093] When the target operation type is a stop operation, based on the process identifier in the instance running state parameters, an instance stop command is generated and the running process of the target Android instance is terminated;

[0094] When the target operation type is a delete operation, based on the path identifier of the data storage directory, the storage resources of the target Android instance are released and the associated containerized instance configuration is removed.

[0095] For example, when an instance management instruction is received, the type identifier embedded in the instruction is first parsed to determine the target Android instance to be operated and the type of lifecycle operation to be performed. The type identifier is dynamically generated by the instruction generation module according to the user's operation intention, for example, "start instance A" is mapped to an identifier containing the instance identifier "A" and the operation type "start" through a preset instruction coding rule. By querying the instance registry, the system matches the type identifier with the created Android instances to determine the unique identifier (such as container ID or instance name) of the target instance and the target operation type (such as start operation identifier 0x01, stop operation 0x02, delete operation 0x03). For example, the container identifier can be "c1" or "c2", corresponding to the path identifier of the instance data storage directory (such as / data / cce / data / c1). By matching the container identifier with the records in the instance configuration database, the associated resources and running state of the target instance are determined, providing a clear execution object and action type for subsequent operations.

[0096] The data storage directory of the target instance stores its private data and runtime logs, and the attribute file (such as build.prop) defines configuration parameters that override the Android system attributes. By reading the status record file (such as runtime_status.log) in the data storage directory, the current running state parameters of the instance are obtained, including the process identifier (PID), resource occupancy rate, and network configuration details. At the same time, the key parameters (such as persist.sys.resource_limit) in the attribute file are parsed to determine the resource quota limit and network mode type of the instance. For example, the attribute file defines that the CPU core quota is 2 cores, the memory upper limit is 4 GB, and the network mode is independent mode. This step provides the real-time state and configuration benchmark of the instance for subsequent operations, ensuring the accuracy and safety of operation execution.

[0097] If the target operation type is startup, instance startup parameters are generated according to the instance resource isolation strategy and network parameter configuration strategy. The resource isolation strategy defines the CPU core number, memory capacity, and storage space quota of the instance, and the network parameter configuration strategy specifies the network mode and related parameters of the instance. The startup parameters include the container image path, resource quota (such as --cpus=2, --memory=4G), network configuration item (such as --net=macvlan), and mount directory information (such as -v / data / cce / data / c1 / property: / system / etc). Through the containerization engine interface (such as Docker API), the instance creation command is called to inject the startup parameters into the containerization engine, triggering the instance startup process. The containerization engine initializes the running environment of the instance based on the parameters, mounts the data storage directory and attribute file, and starts the Android system process. For example, the command "docker run --name c1 --cpus=2 --memory=4G --net=macvlan -v / data / cce / data / c1 / property: / system / etc qsandroid:1.0" is executed, and after startup is completed, the instance enters the running state, and its resource usage and network behavior strictly follow the preset strategy.

[0098] If the target operation type is stop, the main process of the target instance is located according to the process identifier (such as PID) in the instance running state parameter, a stop command (such as "docker stop c1") is generated, the process identifier is obtained by querying the runtime state interface of the containerization engine, and it is ensured that it is associated with the actual running process of the target instance. The stop command is sent to the target instance through the containerization engine interface, a SIGTERM signal is sent to the process, and the instance is waited for to perform resource release and data persistence operations; if the instance does not respond within a preset timeout, a SIGKILL signal is forcibly sent to terminate the process. After the stop operation is completed, the instance state record is updated to "stopped", and the CPU and memory resources occupied by the instance are released, but the data storage directory and attribute file are retained for subsequent restart or data migration.

[0099] The deletion operation locates the storage resource of the target instance through the path identifier of the data storage directory (such as / data / cce / data / c1). A delete command (such as "docker rm-f c1") is executed to remove the container configuration and runtime image of the instance through the containerization engine interface. At the same time, all files in the data storage directory are recursively deleted to completely release the storage space. If the instance is in a running state, the stop operation is performed first and then the resource is deleted to ensure the atomicity of the operation. After the deletion is completed, the record of the target instance is removed from the instance configuration database, and the resource quota table of the host system is updated to mark the number of CPU cores and the memory capacity that have been released for dynamic allocation by other instances.

[0100] In summary, the above steps dynamically trigger the start, stop or delete operation of the target Android instance by parsing the instance management instruction, and realize the fine management and control of the multi-instance life cycle. Based on the data storage directory and attribute file, the running state parameter is parsed to ensure the consistency of the operation and the instance configuration; through the containerization engine interface, standardized commands are executed to ensure the controllability and efficiency of the operation; the resource release and configuration removal mechanism completely eliminates the residual influence of the instance and maintains the stability of the system environment. The process takes into account the flexibility and safety of the operation, and provides efficient and reliable technical support for single-chip platform multi-instance management.

[0101] In some instances, further comprising:

[0102] In response to a version upgrade request of the container engine, based on the hardware architecture information of the host system and the upgraded container engine installation package, a target container engine version is determined;

[0103] Based on the target container engine version, all currently running Android instances are deleted and the associated data storage directory and attribute file are retained;

[0104] Based on the path identifier of the data storage directory and the configuration parameters of the attribute file, the Android instance is recreated through the interface of the upgraded container engine to load the reserved data storage directory and attribute file, and the running state of the instance is restored.

[0105] For example, when detecting the version upgrade request of the container engine, the metadata information embedded in the upgraded container engine installation package is first parsed, including the version number of the target container engine, the supported hardware architecture type, and the kernel module dependency. Based on the hardware architecture information of the host system (such as chip type, instruction set architecture, and memory distribution characteristics), the target container engine version that is adapted to the current hardware environment is selected through the preset version compatibility verification rule. For example, if the host system is a Xilinx ARM array server, the container engine version optimized for ARMv8 architecture and supporting KVM virtualization is extracted from the installation package as the target version. During the verification process, by comparing the hardware architecture identifier with the compatibility list of the container engine, it is ensured that the target version is completely adapted to the physical characteristics of the host system, avoiding running abnormities or performance loss caused by version mismatch.

[0106] After determining the target container engine version, all running Android instances are traversed through the container engine interface, instance stop commands are generated and executed in sequence to terminate the instance process and release the occupied hardware resources. After the stop operation is completed, the system calls the container deletion command to remove the container configuration and runtime image of all instances, but retains the data storage directory and attribute file associated with each instance. The path identifier of the data storage directory (such as “ / data / cce / data / c1”) and the configuration parameters of the attribute file (such as custom attributes in build.prop) are stored in the persistent storage area of the host system according to the preset naming rules, ensuring data integrity and traceability during the upgrade process. This step realizes the decoupling of container engine upgrade and instance data by isolating the life cycle of container configuration and instance data, ensuring the security and reusability of user data.

[0107] After the upgraded container engine is initialized, all instance data directories reserved in the host system are traversed according to the path identifiers of the data storage directories, and the corresponding attribute files are parsed to obtain the original configuration parameters (such as resource quota, network mode type, and system attribute override items) of the instance. Through the interface of the upgraded container engine, the Android instance is recreated, and the data storage directory is mounted to the specified path of the instance to restore the private data and runtime environment of the instance. The configuration parameters in the attribute file are injected into the newly created instance to override the default attributes of the Android system, ensuring that the instance behaves consistently before and after the upgrade. For example, if the instance is originally configured in independent network mode, a separate MAC address and IP address are allocated for it in the new container engine, and the same gateway and routing rules are defined through the container network interface plug-in. Finally, all instances are restored to a running state based on the upgraded container engine, and their data, configuration, and network environment are fully compatible with those before the upgrade, achieving seamless upgrade and business continuity. This step ensures business continuity during the upgrade process through complete migration of data and configuration, avoiding the risk of data loss or configuration reset.

[0108] In some examples, further comprising:

[0109] Based on the resource quota limit, the CPU core occupancy rate and the memory capacity usage rate of each Android instance are collected in real time;

[0110] Based on a preset resource threshold rule library, a first resource overrun state corresponding to the CPU core occupancy rate and a second resource overrun state corresponding to the memory capacity usage rate are determined;

[0111] When the first resource overrun state or the second resource overrun state meets a preset adjustment condition, a new CPU core quota or a new memory capacity quota is generated based on a dynamic resource allocation algorithm;

[0112] Based on the new CPU core quota or the new memory capacity quota, the resource quota limit is updated to optimize the resource allocation of the single-chip hardware platform.

[0113] For example, through the monitoring interface of the containerization engine, the CPU core occupancy rate and the memory capacity usage rate of each Android instance are collected in real time. The CPU core occupancy rate is calculated by counting the CPU time slice proportion occupied by the instance process in a preset sampling period, reflecting the actual consumption of CPU resources by the instance; the memory capacity usage rate is calculated by analyzing the resident memory set (RSS) and swap partition (Swap) occupancy of the instance process, and obtaining the accurate value from the memory management module of the host system. The collection process is continuously executed at fixed time intervals (such as once per second) to ensure the real-time and continuity of the resource usage data, providing dynamic input for subsequent resource state determination.

[0114] Based on the preset resource threshold rule base, the first resource overrun state corresponding to the CPU core number occupancy rate and the second resource overrun state corresponding to the memory capacity usage rate are determined. The preset resource threshold rule base defines the threshold interval and the overrun determination condition of different resource types, for example, the CPU core number occupancy rate exceeding 80% is determined as the first resource overrun state, and the memory capacity usage rate exceeding 75% is determined as the second resource overrun state. The real-time collected occupancy rate data is matched with the threshold in the rule base, if the occupancy rate of a certain resource type continuously exceeds the threshold and reaches a preset duration (for example, continuously for 3 sampling periods), the corresponding overrun state identifier is triggered. This step avoids misjudgment caused by instantaneous fluctuation through rule matching and time window verification, and ensures the accuracy of the overrun state determination.

[0115] When the first resource overrun state or the second resource overrun state meets the preset adjustment condition, a new CPU core number quota or memory capacity quota is generated based on a dynamic resource allocation algorithm. The dynamic resource allocation algorithm calculates the allocatable incremental resource according to the total resource remaining amount of the current host system and the instance priority weight. For example, if the CPU core number occupancy rate of a certain instance continuously overruns and the host system has idle CPU cores, additional cores are allocated to it according to the priority weight; if the memory capacity is insufficient, the quota of low-priority instances is reduced in proportion to release resources. After the algorithm outputs the new quota value, the feasibility of the quota allocation is verified by the resource conflict detection module to ensure that the new quota does not exceed the upper limit of the physical resources of the host system and does not conflict with the quotas of other instances. This step realizes the fairness and maximum efficiency of resource allocation through dynamic algorithm and conflict detection mechanism.

[0116] Based on the new quota generated by the dynamic resource allocation algorithm, the resource quota limit in the instance resource isolation strategy is updated. Specifically, the CPU core number upper limit or the memory capacity upper limit of the target instance is modified through the containerization engine interface, for example, the CPU core number of instance A is adjusted from 2 cores to 3 cores, and the memory is expanded from 4 GB to 6 GB. After the update is completed, the cgroups configuration of the instance is re-bound to ensure that the resource isolation strategy takes effect immediately. At the same time, the quota adjustment log is recorded and synchronized to the resource management database of the host system, providing historical reference for subsequent resource monitoring and reallocation. This step optimizes the resource utilization of single-chip hardware platforms through real-time adjustment and strategy effectiveness mechanism, guarantees the performance requirements of high-load instances, and at the same time maintains the resource balance and system stability among multiple instances.

[0117] Please refer to Figure 2 A containerized multi-instance management device structure schematic diagram is provided for the embodiments of the present application, comprising:

[0118] The configuration parameter acquisition unit 21 is configured to acquire the hardware architecture information of the host system and the configuration parameters of the containerization engine.

[0119] The plurality of instance deployment units 22 deploy the containerization engine to support running a plurality of Android instances on a single chip based on the hardware architecture information and the configuration parameters, wherein each Android instance is configured with an independent data storage directory and an attribute file, and the attribute file is used to overwrite the Android system attribute;

[0120] The allocation policy determination unit 23 determines a network resource allocation policy of each Android instance based on a preset network mode type, wherein the network mode type includes a shared network mode or an independent network mode.

[0121] The lifecycle operation unit 24 is configured to perform lifecycle operation on the Android instance in response to an instance management instruction, so as to realize resource isolation and independent running of the plurality of instances.

[0122] Please refer to Figure 3 The electronic device 300 provided in the embodiment of the present application includes a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor 320. When the processor 320 executes the computer program 311, the steps of any method for containerized multi-instance management are implemented.

[0123] Since the electronic device described in the embodiment is the device used to implement the containerized multi-instance management device in the embodiment of the present application, the specific implementation of the electronic device and its various forms can be understood by those skilled in the art based on the method described in the embodiment of the present application. Therefore, how the electronic device implements the method in the embodiment of the present application will not be described in detail, as long as the device used by those skilled in the art to implement the method in the embodiment of the present application belongs to the scope of the present application.

[0124] In the specific implementation process, the computer program 311 can implement any embodiment in the first aspect when executed by the processor.

[0125] It should be noted that in the above embodiments, the description of each embodiment has its own emphasis, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0126] Those skilled in the art should understand that the embodiments of the present application can provide methods, systems or computer program products. Therefore, the present application can adopt a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer readable program code.

[0127] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart Figure 1 one or more flows and / or blocks. Figure 1 one or more blocks or steps with the functions specified in the flowchart

[0128] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart Figure 1 one or more flows and / or blocks. Figure 1 one or more blocks or steps with the functions specified in the flowchart

[0129] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart Figure 1 one or more flows and / or blocks. Figure 1 one or more blocks or steps with the functions specified in the flowchart

[0130] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart Figure 1 The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart

[0131] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through a wired or wireless manner. The computer-readable storage medium can be any available medium that can be stored by the computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium, an optical medium or a semiconductor medium, etc.

[0132] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0133] In several embodiments provided in the present application, it should be understood that the disclosed devices, apparatuses and methods can be implemented in other ways. For example, the apparatus embodiments described above are only schematic. The division of units is only a logical function division. Actual implementation can have another division manner. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other form.

[0134] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or they can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0135] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be in the form of hardware and / or software functional units.

[0136] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device to perform all or part of the steps of the embodiments of the method of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, and various media that can store program codes.

[0137] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

[0138] Although the preferred embodiments of the present specification have been described, those skilled in the art can make additional changes and modifications to these embodiments once they know the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present specification.

[0139] Obviously, those skilled in the art can make various modifications and changes to the present specification without departing from the spirit and scope of the present specification. Thus, if these modifications and changes of the present specification fall within the scope of the claims of the present specification and their equivalent technologies, the present specification also intends to include these modifications and changes.

Claims

1. A containerized multi-instance management method, characterized in that, include: Obtain the host system's hardware architecture information and the containerization engine's configuration parameters; Based on the hardware architecture information and the configuration parameters, a containerization engine is deployed to support multiple Android instances running on a single chip. Each Android instance is configured with an independent data storage directory and attribute file, and the attribute file is used to override Android system attributes. Based on the preset network mode type, a network resource allocation strategy for each Android instance is determined, wherein the network mode type includes shared network mode or independent network mode. In response to instance management commands, lifecycle operations are performed on the Android instance to achieve resource isolation and independent operation of multiple instances.

2. The method according to claim 1, characterized in that, The acquisition of the host system's hardware architecture information and containerization engine configuration parameters includes: Based on the firmware interface of the host system, obtain hardware architecture identifiers and chip characteristic parameters; Based on a preset configuration rule base, determine the containerization engine type and version constraints that match the hardware architecture identifier; Based on the chip characteristic parameters and the version constraints, configuration parameters for the containerization engine are generated, wherein the configuration parameters include image loading path, resource quota limits and kernel module dependencies.

3. The method according to claim 2, characterized in that, The deployment of a containerization engine based on the hardware architecture information and configuration parameters to support multiple Android instances running on a single chip includes: Based on the image loading path, load the Android image that matches the hardware architecture identifier; Based on the resource quota limit, an independent number of CPU cores, memory capacity and storage space are allocated to each Android instance to generate an instance resource isolation strategy; Based on the aforementioned kernel module dependencies, initialize the kernel virtualization module and network driver module of the containerization engine to establish the foundation for the operation of container instances; Based on the instance resource isolation strategy, multiple Android instances are created in the containerization engine, wherein each Android instance is bound to an independent data storage directory and attribute file; Based on the aforementioned attribute file, Android system attributes are overridden to adapt to the operational requirements of single-chip multi-instance.

4. The method according to claim 1, characterized in that, The method for determining the network resource allocation strategy for each Android instance based on a preset network mode type includes: When the preset network mode type is shared network mode, the network resource allocation strategy of the Android instance is determined to be a shared IP address allocation strategy, wherein the shared IP address allocation strategy includes sharing the IP address of the host system with the Android instance and generating an external access interface based on a preset port mapping rule; When the preset network mode type is standalone network mode, the network resource allocation strategy of the Android instance is determined to be a standalone network parameter configuration strategy. The standalone network parameter configuration strategy includes allocating a standalone MAC address and IP address to the Android instance, and defining gateway, DNS and routing rules based on the container network interface plugin.

5. The method according to claim 3, characterized in that, The lifecycle operations performed on the Android instance in response to instance management instructions include: Based on the type identifier of the instance management instruction, determine the target Android instance and the target operation type; Based on the data storage directory and attribute file associated with the target Android instance, the instance running status parameters are parsed. When the target operation type is a startup operation, instance startup parameters are generated based on the instance resource isolation strategy and network parameter configuration strategy, and the instance startup command is executed through the containerization engine interface. When the target operation type is a stop operation, an instance stop command is generated based on the process identifier in the instance running status parameters, and the running process of the target Android instance is terminated. When the target operation type is a deletion operation, the storage resources of the target Android instance are released and the associated containerized instance configuration is removed based on the path identifier of the data storage directory.

6. The method according to claim 1, characterized in that, Also includes: In response to a container engine version upgrade request, the target container engine version is determined based on the host system's hardware architecture information and the upgraded container engine installation package. Based on the target container engine version, delete all currently running Android instances while retaining the associated data storage directory and attribute files; Based on the path identifier of the data storage directory and the configuration parameters of the attribute file, the Android instance is recreated through the upgraded container engine interface to load the retained data storage directory and attribute file and restore the instance's running state.

7. The method according to claim 3, characterized in that, Also includes: Based on the resource quota limit, the CPU core utilization and memory capacity utilization of each Android instance are collected in real time. Based on a preset resource threshold rule library, the first resource over-limit state corresponding to the CPU core utilization rate and the second resource over-limit state corresponding to the memory capacity utilization rate are determined. When the first resource over-limit state or the second resource over-limit state meets the preset adjustment conditions, a new CPU core quota or memory capacity quota is generated based on the dynamic resource allocation algorithm. Based on the new CPU core quota or memory capacity quota, update the resource quota limit to optimize resource allocation on the single-chip hardware platform.

8. A containerized multi-instance management device, characterized in that, include: The configuration parameter acquisition unit is used to acquire the hardware architecture information of the host system and the configuration parameters of the containerization engine; Multiple instance deployment units deploy a containerization engine based on the hardware architecture information and the configuration parameters to support multiple Android instances running on a single chip. Each Android instance is configured with an independent data storage directory and attribute file, and the attribute file is used to override Android system attributes. The allocation strategy determination unit determines the network resource allocation strategy for each Android instance based on a preset network mode type, wherein the network mode type includes a shared network mode or an independent network mode. The lifecycle operation unit is used to perform lifecycle operations on the Android instance in response to instance management instructions, so as to achieve resource isolation and independent operation of multiple instances.

9. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program stored in the memory, implements the steps of the containerized multi-instance management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the containerized multi-instance management method as described in any one of claims 1 to 7.

Images