Linux container-based Android and open source gap dual-system cooperative operation method

Abstract

The invention discloses a Linux container-based Android and open source gap dual-system collaborative operation method, relates to the technical field of operation system collaboration, and aims to reduce resource occupation and improve collaboration and switching coherence, and the method comprises the following steps: step 1, by taking an Android as a host, creating a container isolation running domain, starting a namespace and managing resources by a control group; the method comprises the following steps: presetting a binder virtualization and three-state template; 2, deploying an open source gap in a container, mounting a shared directory in a directory binding manner, configuring bridging or address translation, and establishing copy-on-write and snapshot identifiers; and step 3, establishing a cross-system binder channel, and setting a service registration agent in a service manager and completing mapping of a handle and an authority domain by combining a shared memory and a local socket. And step 4, executing system switching without restarting, enabling one foreground and the other background through a foreground interface and continuous quota assignment, freezing a background session, limiting the speed of background heartbeat, and returning according to a snapshot when an exception occurs.

Description

Technical Field

[0001] This invention relates to the field of operating system collaboration technology, specifically a method for the collaborative operation of a dual-system Android based on a Linux container and the open-source HarmonyOS. Background Technology

[0002] In various scenarios such as in-vehicle central control, government and enterprise tablets, educational tablets, and industrial handheld devices, terminals need to both continue the Android ecosystem and incorporate the distributed and domestically developed capabilities of the open-source HarmonyOS. These devices are constantly online, have limited size, are sensitive to power consumption and latency, and require uninterrupted operation of critical services such as camera, navigation, and teaching demonstrations when switching between scenarios. In these scenarios, users expect a single device to quickly switch between two systems, share necessary data and network, have a clear security domain, and provide a stable experience; while manufacturers hope to control maintenance and testing costs without increasing hardware complexity.

[0003] Existing dual-system deployments mainly fall into two categories: The first is virtual machines, which run two systems in parallel, either fully or semi-virtualized. However, this introduces a second kernel and driver stack, resulting in high computational and memory overhead, slow startup and switching, and lengthy graphics and multimedia links. The second is partitioned installation, where the systems are placed on different partitions. Switching requires a reboot, leading to poor session continuity, rudimentary file and network sharing, and difficulties in cross-system calls. Containerization has also been explored, achieving lightweight isolation using the same kernel, but it largely remains at the level of single-ecosystem support, lacking feasible approaches for deep collaboration among heterogeneous systems. These issues have been clearly identified in technical documentation.

[0004] The root cause is that when two operating systems serve the same user and peripherals in parallel under the same kernel, they lack a low-level collaborative framework that covers process-level addressable and authorized communication, controlled file and network sharing, foreground / background switching without restarting, and dynamic resource allocation.

[0005] Specifically, this manifests in several ways: First, the semantics of cross-system process calls are lacking, service discovery, handle association, and identity permission mapping are unreliable, and control commands experience amplified delays at boundaries. Second, relying solely on coarse-grained directory mapping and network forwarding easily leads to unauthorized access and data contention. Third, the inability to constrain the background process and freeze its state during switching results in foreground lag, sudden increases in power consumption, session interruptions, and device contention, impacting stability and maintenance. Under the conditions of using Android as the host, two systems sharing the same kernel, and targeting the aforementioned terminal scenarios, there are issues such as unaddressable and unauthorized cross-system process-level communication, coarse-grained file and network sharing with unauthorized access risks, and a lack of orchestratable resource constraints and state maintenance during switching, ultimately leading to imbalances in latency, power consumption, and stability. Summary of the Invention

[0006] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a method for the collaborative operation of Android and open-source HarmonyOS based on Linux containers. This method aims to reduce resource consumption and improve the smoothness of collaboration and switching. It includes using Android as the host, creating a container-isolated runtime domain, enabling namespaces and managing resources with control groups, and pre-configuring binder virtualization and tri-state templates. HarmonyOS is deployed in the container, with directory-binding shared directories, bridging or address translation configured, and copy-on-write and snapshot identifiers established. A cross-system binder channel is established, combining shared memory and local domain sockets, setting up a service registration agent in the service manager and completing handle and permission domain mapping. System switching is performed without restarting, using a foreground interface and continuous quota assignment to make one system foreground while the other is in the background, freezing background sessions and limiting background heartbeat rates, and reverting to snapshots in case of anomalies. This solves the technical problems described in the background section.

[0007] (II) Technical Solution To achieve the above objectives, the present invention provides the following technical solution: The method for co-operating between Android and open-source HarmonyOS based on Linux containers includes: using Android as the host, creating a container isolation runtime domain on the host, enabling processes, network, and mount namespaces, and using a control group to manage processor, memory, and input / output quotas, and pre-setting binder virtualization and tri-state resource templates. Deploy and adapt the open-source HarmonyOS in the isolated operating domain so that it shares the kernel with Android; mount the selected shared directory using directory binding, configure the network by bridging or address translation, and establish copy-on-write and snapshot identifiers; A cross-system binder mechanism between Android and open-source HarmonyOS is established as the control channel. Combining local domain sockets and shared memory, service registration agents are set up in the service managers on both sides to complete the mapping of service names, handles and permission domains.

[0008] Perform system switching without restarting, make one side the foreground and the other the background through the foreground interface, continuously assign values ​​to the control group parameters according to the three-state resource template, freeze the background session and limit the background heartbeat, and roll back according to the snapshot in case of an anomaly.

[0009] Furthermore, an independent instance of the binder device file system is mounted in the inter-process communication namespace, an instance node is generated and the instance identifier is registered; the instance node path and permissions are written into the resource and security whitelist, and maintained by the container lifecycle hooks during creation, destruction and restart.

[0010] Furthermore, establish resource and security whitelists: the directory whitelist is generated in topology order according to parent-child paths and used for directory binding mounting order; the network whitelist is listed by protocol, port, and direction; and the device capability whitelist is recorded in pairs of device nodes and agent handles and written to disk.

[0011] Furthermore, open-source HarmonyOS is deployed with a read-only root and a copy-on-write layer, and a snapshot identifier is generated after configuring network bridging or address translation. The snapshot identifier is then paired with the container's network identity at that time and recorded in the rollback list.

[0012] Furthermore, service registration agents are set up in front of the service managers of Android and open-source HarmonyOS respectively, and cross-system endpoints are created one by one by reading the service directory to form a list in which service names and endpoints correspond one-to-one, and the list is persistently stored on both sides for querying.

[0013] Furthermore, based on the service registration results, handle mapping and permission domain mapping are established. Container-side handles are generated according to the handshake process, and mapping entries, user identifiers, and security domain labels are recorded on both sides. Reference counting and recycling rules are set, and the entries are included in the handle mapping table.

[0014] Furthermore, the data channel includes shared memory and local domain sockets: shared memory is used and allocated in the page pool when message pages are aligned and file descriptor handover is not required; otherwise, local domain sockets are used and event notification and file descriptor handover are completed through this channel, with the path and endpoints registered in the manifest.

[0015] Furthermore, the switching admission process includes receiving the switching instruction, reading the service mapping list and handle mapping table, confirming that all necessary services have cross-system endpoints and that the corresponding handles have mappings on the container side, and then triggering the session freezing and resource assignment process.

[0016] Furthermore, resource assignment adopts a time-continuous method, in which the background quota vector is transformed into the front-end quota vector according to the preset segmented weight sequence, and the target files of the three control groups of processor, memory and input / output are written and recorded component by component according to time slice.

[0017] Furthermore, session freezing and restoration include generating a freeze list and recording the window stack, activity context, and session handle; during restoration, the freeze list is rebuilt item by item and a callback verification is triggered; the freeze list is managed by number, and unfreezing and rollback are performed in numerical order.

[0018] (III) Beneficial Effects This invention provides a method for the collaborative operation of two systems, Android and open-source HarmonyOS, based on a Linux container, which has the following beneficial effects: Using Android as the host and enabling the open-source HarmonyOS to share the same kernel within the container isolation runtime domain, along with the pre-defined binder device virtualization and tri-state resource templates in the inter-process communication namespace, a single kernel shared stack and an orchestratable base are formed, reducing redundant driver loading and multi-kernel maintenance paths.

[0019] By establishing controllable boundaries within the isolated operating domain through namespaces and control groups, and combining resource and security whitelists, the visibility scope and permissions of directories, networks, and devices are fixed as textual rules, providing a definite starting point and unified standard for subsequent directory binding mounting, network bridging, address translation, and device proxying.

[0020] On the container side, the host's selected directory is mounted by the directory binding method, and the network identity is configured by the network bridging or address translation method. At the same time, the device agent is introduced for sensitive devices. A read-only root is used in conjunction with write-on-write replication to generate a snapshot identifier, forming a controlled shared and rollbackable deployment site, which facilitates cross-version and cross-model migration.

[0021] A collaborative structure with a cross-system binder mechanism as the control channel is established. Service registration agents are set on both sides of the service manager to complete the mapping of service name, handle and permission domain. The data plane adopts shared memory and local domain sockets to be distributed according to volume and semantics, realizing an integrated path for service-level addressability, bidirectional callback and stable transfer of large volume of data.

[0022] In system switching without restarting, the switching access is first performed based on the service mapping list and the handle mapping table. Then, the background quota vector is smoothly transitioned to the foreground quota vector by assigning values ​​continuously over time. At the same time, a session freeze list is generated and heartbeat rate limiting is enabled in the background, so that the resources and sessions of the foreground and the background are connected in a controlled manner in the same time sequence. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the process of the dual-system collaborative operation method of Android and open-source HarmonyOS according to the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figure 1 This invention provides a method for the collaborative operation of dual systems, Android and open-source HarmonyOS, based on Linux containers. The method includes: Step 1: Building a container isolation runtime domain with a shared kernel under Android as the host, uniformly enabling processes, network, and mount namespaces and setting quotas with control groups, and pre-setting binder device virtualization, resource and security whitelists, container lifecycle hooks and three-state resource templates to provide a manageable foundation for subsequent deployment and collaboration.

[0026] To ensure that the open-source HarmonyOS system does not interfere with the host in terms of processes, network, mounting, and user views after entering the container, while allowing the host to impose hard boundary restrictions on the container's processor, memory, and I / O resources, namespace isolation is used as the view isolation layer, and control group quotas are used as the resource constraint layer, with the two aligned one-to-one to create domains. In terms of processing logic, the target namespace set is first determined, and then each item in the set is enabled. Subsequently, a corresponding control group directory is created, a three-state resource template is written, and the container's initial process is placed into the corresponding control group, so that view isolation and resource boundaries take effect within the same lifecycle. Finally, a visible structure is formed in which view isolation and resource quotas take effect in pairs.

[0027] Let the set of namespaces used to establish isolation be denoted as This includes process namespaces, network namespaces, mount namespaces, and user namespaces; the set of pre-mount paths prepared for subsequent binder device virtualization and container root file system is denoted as... The process revolves around a single chain of target-enable-verify: First, a set of targets is given, then the container management script enables them in sequence, and immediately verifies whether isolation is effective after each target is enabled; if the verification passes, a pre-mount path is generated in the mount namespace for subsequent device nodes and directory placeholders; Invoke the container management script in the host terminal, specifying the namespace set. The script creates isolation for each of the four names and writes the verification results back to the log; then, it establishes a set of pre-mount paths within the mount namespace. The placeholder directories in the container are divided into two categories: one for subsequent binder device virtualization nodes and the other for placeholder directories in the container root file system and whitelist directory. To ensure that the establishment of isolation measures is verifiable, an isolation completeness index is defined: Where: Isolation completeness index : Indicates the percentage of entries with namespaces enabled. If and only if This is considered as all isolation targets being in place; group activation is then enabled. : Represents the set of namespace entries that have been successfully enabled and verified in the current container session, with a value range of four subsets; Target set target : Indicates the set of namespace entries to be used, fixed as a universal set of four items, a fixed set; set cardinality symbol : Indicates the number of elements in the set, which is a natural number; the processing method is recorded simultaneously when writing back the log. The value is If the process proceeds to the next step, a rollback will be triggered. In application, by using explicit sets and placeholder paths, the effectiveness of view isolation is transformed into an observable final state, and subsequent device nodes have fixed anchor points with the root file system, thus avoiding non-repeatable issues caused by inconsistent paths in later deployment phases. If a user namespace is not enabled due to policy restrictions, a weighted overlay method using a device access whitelist can be used to narrow the visible scope, while still maintaining the namespace set. With isolation completeness index The judgment criteria remain unchanged.

[0028] Resource boundaries are established immediately after view isolation is completed. To ensure rapid value assignment between foreground, background, and frozen states during subsequent transitions, explicit definitions of resource template matrices and quota vectors are introduced: the system resource budget vector is denoted as... Includes processor budget, memory budget, and input / output budget; the ratio vector of the three-state resource template is denoted as... ,in Belongs to the state set, front-end and back-end frozen. Therefore, the quota vector for each state is defined as follows: Where: resource budget vector : Represents the upper bound triple of resources that the host can allocate to the container, including the processor budget. Memory budget Input / output budget Each component takes values ​​in the range of positive numbers; state ratio vector : Indicates the state The following three types of resources each account for a certain percentage and their respective weights. And with Same dimension; quota vector : Indicates the state The actual resource quota written to the control group, dimensions and Same; element-wise product operator : Represents the operation of multiplying corresponding components; state set It is fixed to include three status labels; Create three sets of control group directories under the kernel pseudo-filesystem path, and set the quota vectors accordingly. The three components are written directly to the corresponding files; the background state is selected by default when the container's initial process is added. To avoid interfering with the host during the deployment phase; include a state ratio vector in the project handover. The text description and generator function description are provided. The generator function uses piecewise linear interpolation to map from three segments—static, smooth, and frozen—to a three-state ratio, which is convenient for subsequent steps to call. When applied, the explicit definition of resource budgets and ratio templates forms traceable and reusable assignment rules, enabling the reconfiguration of the overall resource boundaries to be completed simply by switching states during switching, avoiding the uncontrollability caused by writing item by item.

[0029] After the domain is built, it is necessary to reserve a security boundary and a controllable entry point for subsequent deployment and communication to avoid containers introducing potential unauthorized access to the host, and to avoid uncertainty caused by confusion of device nodes and service entry points during subsequent cross-system communication. Therefore, the process revolves around three key aspects of virtualization: whitelist, hooks, and binder device virtualization. First, a resource and security whitelist is built to clearly define the boundaries of directories, networks, and device capabilities. Then, container lifecycle hooks are registered to provide fixed entry points for creation, destruction, and restart. Finally, the instantiation of binder device virtualization is completed, and the instance identifier is incorporated into the whitelist system to ensure that subsequent cross-system communication occurs on the controlled device node. To ensure that access boundaries are declarable, verifiable, and transferable, the directory whitelist, network whitelist, and device capability whitelist are defined as collection directories. ,network With equipment Directory whitelists are presented as mount paths and their permissions; network whitelists are presented as protocols, ports, and directions; and device capability whitelists are presented as device nodes and capability tags. Based on this, access permission functions are introduced. Where: Access permission function Input is the item to be accessed. The output is binary. This indicates permission. Indicates prohibited; item to be accessed. : Represents an abstraction of an access request, which can point to a directory entry, network entry, or device capability entry, and its function is to compare it with a whitelist; directory whitelist collection directory. : A set consisting of mount path and permission tuples, with values ​​taken from placeholder paths in the foreground feed, used to restrict file system access; Network whitelist collection network A set of protocol, port, and direction tuples used to restrict network access; a set of device capability whitelists. : A set consisting of device nodes and capability tag tuples, used to restrict access to hardware capabilities; a configuration text file carries three types of whitelists, and the container management script immediately performs reachability checks on the three types of whitelists after creation; the check adopts item-by-item probing, without writing actual data, only testing the existence of the path and the policy hit; all results are written to the log and handed over with the electronic work order; When applied, the whitelist is transformed from a documented convention into a runtime verifiable judgment by formalizing access permission functions. Any subsequent access can be quickly compared in the container management script or daemon process, reducing the gray area.

[0030] Cross-system communication will be performed in subsequent steps, but its device nodes need to be established and incorporated into the security boundary in this step. Therefore, the number of binder device instances is defined first. The instance identifier set is And specify the mount point path for each instance; Subsequently, three types of lifecycle hooks are registered during container creation: hook creation generates instances and registers identifiers, hook destruction unloads instances and cleans up control group remnants, and hook restart sequentially executes unloading and regeneration; to ensure instance and state transitions are coordinated, the instance identifier set and state set are... The data is associated to form mapping entries and written to the log; to verify the completeness of the generated data, an instance integrity metric is introduced: Where: Instance integrity index This represents the ratio of the number of successfully mounted binder device instances to the planned number. ; Instance identifier set : Represents the set of instance identifiers that have been created and verified within the mounted namespace; the number of binder device instances. : Indicates the number of instances to be created, which is a positive integer; During hook creation, generate them sequentially under the pre-mount path. For each instance, verify the visibility of each node and add the verified identifiers to the instance identifier set. ; Create a hook to calculate instance integrity metrics And write back to the log, if This triggers a rollback; in the destruction hook, all instances are unloaded in reverse order and the collection is cleared; in the restart hook, destruction is called first, followed by creation. In application, by explicitly defining the number of instances and the set of identifiers, and by ensuring their completeness, a fixed correspondence is established between the virtualization of the binder device and the container lifecycle. This ensures that subsequent cross-system communication will only occur on the controlled device nodes. Measurable effects and measurement conditions: Under normal temperature and fixed firmware version conditions, the creation-destruction-reboot process is repeatedly executed, and the logs are observed. Does the value match the number of instance identifiers? No external measuring instruments are required; only system logs are needed. Step 2: Enable the open-source HarmonyOS to start stably within the isolated operating domain and access host resources in a controlled manner. Establish file and network channels through directory binding mounts and network bridging or address translation, introduce device agents, read-only roots and copy-on-write, and generate snapshot identifiers to form a controllable environment that can be rolled back.

[0031] Since the open-source HarmonyOS within the container needs to reuse the host kernel and access resources in a controlled manner, it is necessary to verify the isolation completeness of step one and the integrity of the binder instance before startup. At the same time, the background state quota vector should be initialized to avoid interfering with the host foreground. Based on this, the open-source HarmonyOS startup process needs to be divided into four segments: root file system loading, environment variable injection, service directory initialization, and initialization process launch. Each segment should end with a visible prompt and a scrollable scrollback.

[0032] Using the isolation completeness index and instance integrity index output from step one as criteria, a startup determination index is given, and the state quota vector is assigned in one go upon passing the determination, thereby binding startupable and controllable resources into an action chain. First, the startup determination index is defined. Where: Isolation completeness index : Indicates the activation ratio of the namespace collection. If and only if the value is This indicates that all view isolation targets are in place; instance integrity index : Indicates the mounting completion percentage of the virtualization instance of the binder device; value range If and only if the value is This indicates that all device nodes are visible; Startup Judgment Indicators :for and The minimum value, ,when The time indicates that both isolation and instance conditions are met, allowing entry into the container startup sequence; minimum value operator Take the smaller of two real numbers; Execute the startup script in the host terminal. The script first reads the log from the previous step. and Calculate the start-up criteria And output the result as a single-line prompt; when At that time, the script immediately changes the state quota vector. Write to each target file in the control group and lock the container's initial process to belong to this state; then load the read-only root image and copy-on-write layer, set the container's timezone and local environment variables, and start the initialization process; if If the condition is not met, the startup will be refused and a message indicating that the startup condition has not been met will be displayed, and the system will wait for manual intervention or automatic rollback.

[0033] When applying it, the judgment indicator is activated. The single criterion links the four actions of isolation, instance, quota, and loading into a single chain, ensuring that startability and controllability advance and retreat together, avoiding inconsistencies such as a container already running but missing device nodes or unrestricted resources entering the foreground; at the same time, it integrates the state quota vector The assignment is moved to before loading to reduce the disturbance to the host during the startup phase.

[0034] To ensure that open-source HarmonyOS user-space services can correctly access hardware resources within the container without exceeding permissions, device interface adaptation and service directory initialization are integrated into a single operation.

[0035] First, load a device abstraction layer that matches the host kernel version inside the container, and explicitly declare a list of allowed device nodes. This list must match the set of device capability whitelist symbols. Consistency is achieved; then, a proxy layer is established for services involving camera, sensor, positioning and other capabilities, which routes calls from the open source HarmonyOS side to the host side proxy process, and performs permission verification, handle registration and call auditing at the proxy process; then, a service directory structure is generated in the container file system, with each service in the directory corresponding to its proxy endpoint, and the mapping relationship is recorded in text form. After the directory is generated, it is written to disk with a single line prompt.

[0036] The script executes the device adaptation script, which reads the device capability whitelist set. The script compares and establishes proxy handles item by item, and then calls the service directory generator to scan the registered proxy handles to generate directory entries. The script outputs the proxy handle number and the number of directory entries at the end, which serve as the input reference for the next step of cross-system binder collaboration.

[0037] When applied, the entry point for device access is moved from the kernel node to the proxy layer. Combined with the one-to-one mapping in the service directory, a stable boundary is formed that is visible in user space and controllable in host space, providing a clear entry point and an auditable path for subsequent cross-system calls.

[0038] After the open-source HarmonyOS starts, it needs to access file and network resources without violating the host's isolation boundaries, and couple the copy-on-write layer with network identity to provide a workable path for rollback and network recovery. Therefore, it starts with a directory-binding mount topology to ensure that the mounting order and paths of directories with different permissions do not conflict; then it establishes a selection relationship between network identity configuration, port policy, and address mode to ensure that network inbound and outbound channels are consistent with the whitelist policy; finally, it establishes a correspondence between copy-on-write and network identity at specific time points to ensure that the network-side configuration can be automatically restored after a rollback.

[0039] Directory-based binding mounts must ensure that the parent-child relationship between the upper-level read-only directory and the lower-level read-write directory is not reversed and remains consistent with the whitelist set; therefore, a directory mapping function is defined: Where: directory mapping function : Accepts an element from a directory whitelist set and returns a pre-mounted path within the mount namespace, binding permissions to paths in a one-to-one correspondence; directory whitelist set : From the whitelist set in step one, each element is a path-permission tuple, representing a set of controlled paths with either read-only or read-write permissions; Pre-mounted path set. : The placeholder path set from step one, where each element is a specific path in the container's mounting namespace; First, compile the directory whitelist. All elements are sorted according to their parent-child path relationships to obtain a topology sequence. Then, mount commands are called sequentially to bind read-only paths first, followed by read-write paths. Any privilege escalation requests are rejected and logged. Mapping functions are also used. The execution record is written to the log for backtracking; after mounting, the existence of the path and the consistency of permissions are verified for each mapping result.

[0040] In application, through mapping functions The deterministic mapping and execution of the topology sequence ensure that the paths and permissions of directory-bound mounts present a hierarchical relationship of read-only above and read-write below, without cross-over or permission drift; at the same time, the correspondence between paths and permissions is externalized into log text, which is convenient for review and maintenance.

[0041] The network mode needs to be selected between bridging and address translation, and must be consistent with the port policy file; meanwhile, copy-on-write provides a rollback point, requiring that the network identity can be restored to its original configuration after a rollback. Therefore, a network identity selection function is defined: And the snapshot generation function: Where: Network identity selection function When the mode selection symbol is used Output bridged identity vector ,when Output address translation identity vector Both contain components such as address, subnet mask, gateway, and port mapping description; mode selection symbol. : A binary variable whose set of values ​​is , Indicates bridging. This represents address translation, which serves to make a mutually exclusive choice between two modes; bridging identity vectors. : Represents the network identity of the container in bridged mode. The component values ​​are within the range of valid network configuration values, specifically generated by the on-site network allocator; Address Translation Identity Vector : Represents the network identity and port mapping description of the container in address translation mode; Snapshot generation function : Mark the time Mapped to snapshot identifier This is used as a rollback reference for the copy-on-write layer; the function is a monotonically increasing map. The value is the system time series from startup to the present, and the snapshot identifier. A short, persistent identifier string; snapshot identifier The specific construction involves a concatenated hash of a monotonic timestamp and a metadata digest of the root file system's copy-on-write layer, ensuring monotonic timing and content traceability; the list records... With network identity For pairings, rollback is performed on the paired entries.

[0042] Based on network whitelist set symbols In conjunction with the strategy file, first determine the mode selection symbol. Then the network identity selection function is calculated. It writes to the container network interface in components; after the write-time replication layer is ready, it performs a snapshot as the container network and records the data. and The paired entries are written to the rollback manifest; in the event of an abnormal rollback, the identifier of the most recent snapshot is read from the manifest. And restore the corresponding network identity component.

[0043] When applied, a network identity selection function is used. Combine mode selection and identity configuration into a single action, then use a snapshot generation function. By fixing the generation time of the network identity as a snapshot identifier, the two subsystems of network and storage are synchronized on the timeline, ensuring that the network configuration and file system state remain consistent after rollback, reducing manual reconfiguration.

[0044] Step 3: Establish service-level interoperability between Android and open-source HarmonyOS using a cross-system binder mechanism as the control channel; set up a service registration proxy to map service names to endpoints, handles, and permission domains; and use shared memory and local domain sockets to divert large volumes of data, supporting event and file descriptor handover and link health and degradation.

[0045] Since the control plane needs to complete service-level calls and callbacks between the Android host and the open-source HarmonyOS within the container, the service directory and device capability whitelist produced in step two must be checked item by item, and the binder main channel is used as the only control entry point to ensure that the call path and permission boundaries are consistent. Service mapping determination and registration are completed first, and then handle mapping and permission domain mapping are performed. The two are connected to each other so that the closed loop of addressable, authorized, and callback is achieved on the same channel.

[0046] A registration agent is set up in front of the service managers on both sides. By reading the service directory generated in step two, the service name set is matched one by one with the cross-system endpoint set, and the pairing is solidified into a textual list. To form clear startable conditions, a service mapping completeness indicator is introduced to determine whether all required services have endpoints on the binder's main channel. The set of required services is defined as follows: The registered cross-system endpoint set is ,but: Where: Service mapping completeness index : Range of values If and only if the value is This indicates that all required services have completed cross-system endpoint registration; a set of cross-system endpoints has been registered. : Consists of endpoint names that have been registered and can be queried by the service managers on both sides. The elements are strings, and the size of the set is a natural number; Essential services collection : Consists of the required service names marked in Step 2's service directory, with each element being a string and the set size being a natural number; the set's cardinality is indicated by the symbol. : Indicates the number of elements in the set; The Android host-side registration proxy reads the service directory from step two, parses the service names line by line, and generates a registration request; the container-side registration proxy receives the request, establishes an endpoint on the binder's main channel, and sends back the endpoint identifier; both proxies write to their local manifests and output a registration completion message in the logs; subsequently, either side calculates... And print the value in the prompt line. Only then can the handle and permission domain mapping stage be entered; if If so, the registered endpoint list will be terminated and rolled back.

[0047] When applying this, use the service mapping completeness metric. As a visible threshold, the correspondence between the service catalog and the binder's main channel is transformed from a documented convention into a runtime verifiable condition; by fixing the service-endpoint mapping through dual-sided proxies and text lists, the possibility of inconsistencies in subsequent call paths is reduced.

[0048] After the service mapping is approved, it is necessary to ensure that cross-system calls maintain consistency in handles and permission domains. That is, the handle on the Android host side has a traceable counterpart on the container side, and the mapping of user identity, group and security domain does not result in unauthorized access.

[0049] To this end, a handle mapping table and a permission domain mapping table are constructed, and a weighted survivability index is used to determine the mapping status. Let the Android host handle set be... The container-side handle set is Assign weights to each Android host handle (Generated based on the importance tags in the service directory, with the tag source consistent with the service directory in step two), Definition: In the formula: handle survivability index : If and only if the value is This indicates that all weighted Android host handles are mapped on the container side; weight : Handle The importance coefficient, a positive number, originates from the importance tag mapping in the service directory and serves to highlight the coverage of critical handles; indicator functions. When the mapping function The output belongs to Time to take Otherwise, take 0; Mapping function : Transfer Android host handle Mapped to a container-side handle, the function is a deterministic lookup table or a named generation process; a deterministic process of handshake generation + lookup table backfilling (handshake allocates a new container-side handle and writes it to a bidirectional table) is used to establish... One-to-one correspondence; set , : These are the registered handle sets on the Android host side and container side, respectively, with elements being integers or structured identifiers; Scan collection on the Android host side Through mapping function Generate container-side handles and register them in the collection. Simultaneously, based on the permission domain mapping table, the Android host user identifier and security domain label are mapped to equivalent or restricted identifiers on the container side, and reference counts and recycling rules are recorded on both sides; then, handle survivability metrics are calculated. And output a prompt line; when the handle survivability index When entering the data plane configuration, when Roll back the latest batch of mapping operations and print the missing list.

[0050] In application, handle survivability indicators are used. The weighted approach prioritizes the survival of critical handles, reducing the risk of disrupting the overall chain establishment due to delayed mapping of individual non-critical handles; permission domain mapping and handle mapping are implemented simultaneously, avoiding inconsistent states where the handle can be addressed but not authorized.

[0051] After the control plane establishes the link, it is still necessary to establish a stable path for large-volume data transfer and form a complementary relationship with small-volume control messages. Therefore, it is necessary to make a calculable diversion judgment between message volume and time urgency, and provide deterministic backoff and degradation processes in the event of failure, so that the data plane can maintain a predictable transfer order under different loads.

[0052] To distribute small control messages to the binder main channel and large data volumes to shared memory or local domain socket channels, a flow distribution probability is introduced to measure the preference for selecting the data plane. The threshold is used for engineering implementation. Let the message volume be... The time urgency is ,definition Where: Diversion probability : Range of values This indicates the preference for choosing the data plane (shared memory or local domain sockets). The larger the value, the more it tends to be data-driven; volume coefficient Positive numbers indicate the strength of the impact of message volume on the routing decision; Size threshold : A non-negative real number, representing the equilibrium point for data surface selection triggered by volume; urgency coefficient Positive numbers indicate the strength of the impact of time urgency on the diversion decision; urgency threshold. : A non-negative real number representing the balance point between time urgency and the diversion decision; message volume : A non-negative real number, given by the message metadata; Time urgency : A non-negative real number, which can be obtained by converting the maximum sending time limit declared by the caller; exponential function : Natural exponential function; When the diversion probability When directly selecting the main channel of the binder; when When entering the data plane, the volume reallocation function makes a choice between shared memory and local domain sockets (e.g., based on page alignment and the presence or absence of file descriptors); threshold solving can be performed... The parsing is as follows In engineering, binary search can be used to find the volume interval and the urgency interval that satisfy the conditions in a finite discrete set; the parameters to be found The strategy is defined and written into the strategy file by the project team during the acceptance phase, and no self-adjustment is performed during the runtime.

[0053] In application, the diversion probability is used. The continuous expression incorporates volume and urgency into the same judgment formula, thereby unifying different business forms under the same rule; The analytical representation of the threshold provides a clear implementation path for threshold solving, without relying on empirical thresholds passed down orally.

[0054] After the data plane channel is established, it is necessary to ensure the continuity of cross-system callbacks and file descriptor handover, and in the event of a failure, to retry at deterministic backoff intervals and degrade to a more conservative transmission path. Therefore, an exponential backoff sequence is used for the retry interval, assuming the first... The retry interval is ,definition: Where: retry interval : Positive number, indicating the first Waiting time before the next retry; baseline interval : Positive number, representing the initial waiting time, given by the strategy file; amplification factor. Greater than The real number represents the magnification factor of the retreat; the retry sequence number. : A non-negative integer, representing from The initial number of retries; In a shared memory channel, event notifications are sent via local domain sockets, and file descriptors are carried along the same path; when a link health check detects a timeout or anomaly, a backoff sequence is entered, and retry intervals are recorded. Wait and retry; after exceeding the preset number of attempts, automatically downgrade to a smaller split of the binder's main channel or use only the local domain socket channel; the downgrade action is recorded in the log and paired with the snapshot identifier for easy backtracking.

[0055] In application, exponential backoff makes the retry rhythm during failures clearly controllable, avoiding continuous resource consumption; events and file descriptors are transferred on the same path, reducing the possibility of state splitting; degradation and snapshot identifier pairing provide fixed anchor points for recovery and rollback.

[0056] Step 4: After the switchover is approved, the backend quota vector is smoothly transitioned to the frontend quota vector by continuously assigning values ​​over time. The system frontend and backend replacement is completed through the frontend interface. At the same time, a session freeze list and a backend heartbeat rate limiting policy are generated and used. In case of an anomaly, a rollback is performed based on the snapshot identifier and a consistent running environment is restored.

[0057] To avoid situations where services become unavailable and forced switching occurs, or where resources are not assigned and the front-end becomes unstable, the switching action must be preceded by an admission decision, and after admission is granted, the back-end quota vector should be smoothly transitioned to the front-end quota vector in a time-continuous manner.

[0058] Therefore, we first give the switching admission index that is consistent with step three, which is coupled with the service mapping completeness and handle survivability. Then we define a time-continuous resource assignment function and specify the determination method and disk placement method of the weight function, so as to connect whether it can be switched and how to switch into a single chain.

[0059] The acceptance criteria for a handover action must simultaneously meet the lower bounds of service mapping completeness and handle survivability, and, in conjunction with the ratio of the orchestration target quota to the initial quota, provide a single criterion for execution. Therefore, handover acceptance metrics are defined. Where: Switching access criteria : Used to determine whether to allow access from the backend to the foreground; a positive real number; when Allowing entry into the switching process at that time; Service mapping completeness index : Indicates the percentage of essential services that have completed cross-system endpoint registration. Handle survivability index : Indicates the proportion of the weighted Android-side handle that is mapped to the container-side, with a value range of 1. ; Front-end quota vector : Derived from the definition of state set and quota vector, it represents the triplet of processor, memory, and input / output quota in the foreground state, with components taking positive values; background quota vector Same as above, representing the credit limit triplet in the background state, with positive values ​​for the components; 1-norm symbol. The operation of summing vector components is used to measure the total amount. After receiving a user trigger, the switching daemon first reads the service mapping list and handle mapping table to calculate the service mapping completeness index and handle survivability index. Then, it reads the three-state quota template to generate the front-end quota vector and the back-end quota vector, and calculates the switching admission index. When the switching admission index reaches the threshold, it will trigger session freezing and resource assignment. If it does not reach the threshold, it will output an admission denial prompt and maintain the status quo.

[0060] When applied, the switching admission criteria combine cross-system addressability, authorization, and resource availability in the same criterion to avoid making irreversible switching decisions based on a single list; at the same time, the service-side indicators are corrected with the total quota ratio to improve the sensitivity of the criteria to the expected front-end load.

[0061] To avoid front-end lag caused by sudden resource fluctuations, a time-continuous weighting function is used to smoothly transition the back-end quota vector to the front-end quota vector. A time-continuous resource assignment function is defined. Where: Time-continuous quota vector : Indicates time The quota triplet is written to the control group; the quota vector is written to the backend. Front-end quota vector Same as above; Weighting function : is a monotonically non-decreasing function, is The value is 0 at the start time and 0 at the end time. Specifically, piecewise linear interpolation (starting segment, transition segment, and convergence segment) is used, with segment boundaries given by the strategy file. The weight function is the time weight for smoothly transitioning the background quota to the foreground quota during switching, and the baseline is piecewise linear, as follows: Among them: switching time The relative time after receiving the switching instruction; start time End time Given by the policy file and ; Monotonic and non-decreasing, with a value range of [missing information]. Based on this During this period, quotas are continuously interpolated from the backend to the frontend and written to the control group according to time slices.

[0062] After the session freeze is complete, the switching daemon calls the control group file write function according to the time slice sequence in the policy file, and writes the three components of the time-continuous quota vector in sequence. The weight function uses piecewise linear interpolation, and the interpolation coefficients can be generated by a one-dimensional interpolation solver and written to disk as text. After all time slices have been written, a prompt line indicating that the resource assignment is complete is recorded.

[0063] In application, the discrete three-state template is transformed into an executable continuous curve through the time-continuous quota vector, thereby reducing abrupt changes at the physical level and forming a traceable assignment trajectory at the management level; the textualized weight function is stored on disk for easy review and reproduction.

[0064] The switchover is not the end point. It is also necessary to ensure that the background session can be recovered, the background network maintains the necessary connectivity and does not exceed the rate limit, and when an anomaly is detected, it can be restored to the previous stable snapshot according to the determined backoff and rollback path.

[0065] Therefore, the session freeze-consistency check-recovery and keep-alive rate limiting-abnormal backoff-rollback execution are chained together to ensure that the state, network and snapshot are aligned on the timeline.

[0066] Session freezing requires writing the window stack, activity context, and session handles to a list on disk, and then performing set-level verification using consistency metrics before and after freezing. The set of handles before freezing is defined as follows: After restoration, the handle set is Then the consistency index Where: Consistency index : The closer the value is to 1, the more consistent the set of handles after freezing and recovery is with the set before freezing; the set of handles before freezing... : A set of handles from the session freeze list, with elements being structured identifiers; the set of handles after restoration. : A collection of handles obtained from an immediate scan after recovery, with elements in the same format as... Consistency; Set cardinality symbol : Indicates the number of elements in the set; During the freeze phase, three types of objects are written into the list and numbered; during the recovery phase, the list is read and handles are rebuilt item by item and callback verification is triggered; then the consistency index is calculated and a prompt line is output. If the policy lower limit is not reached, the list is rolled back to the previous freeze number or an exception is triggered. In application, consistency metrics transform the previously scattered state checks in logs into a single, readable measure, reducing the cost of manual review and providing explicit triggering conditions for anomaly backoff. When only window stacks need to be verified, the set can contain only window stack entries; when it needs to be expanded to network session handles, the set can be incorporated into the handle set exported by the network agent, maintaining consistent metric definitions.

[0067] The backend network needs to both keep sessions alive and limit rates to avoid disrupting the foreground. Therefore, it's necessary to extract network-side budget from frozen quotas and couple it with the heartbeat rhythm. Define the backend heartbeat budget. Where: Background heartbeat budget : Values ​​are positive real numbers, representing the network-side quota that can be consumed by the background heartbeat per unit time; weight vector Used to extract network-related components from the frozen quota. The values ​​are non-negative real-number vectors, and the sum of the three components is not limited to 1; frozen quota vector. : From the tri-state template, representing the triplet of processor, memory, and input / output quota in the frozen state, with the component values ​​being positive; During the background state maintenance, the heartbeat scheduler generates tokens according to the background heartbeat budget, and sends them after a delay if there are not enough tokens. When the link health check (using the exponential backoff interval of step 3) determines that it is abnormal, backoff is triggered and rollback is performed according to the downgrade-snapshot pairing list to restore the file and network identity corresponding to the most recent snapshot. After the rollback is completed, the background heartbeat budget is recalculated and keep-alive is restored.

[0068] In application, resource orchestration is bound to the heartbeat rhythm through the background heartbeat budget, achieving unified control of rate limiting and keep-alive. Backoff and fallback links are bound to snapshot identifiers, making the exception handling path standardized and traceable. When input and output components are subdivided into read and write, the weight vector dimension can be expanded accordingly, while the background heartbeat budget definition remains unchanged. When port grouping rate limiting is used, only the weight vector needs to be mapped to the quota component of the corresponding port group.

[0069] As a supplementary explanation, the volume coefficient Urgency coefficient Size threshold Urgent threshold retreat parameters Weight vector Three-state ratio vector Quota vector family Weighting function The segmentation points mentioned above all originate from the strategy file (text format), which is given during the acceptance phase. During runtime, the data is only read and written to disk, and no black-box self-adjustment is performed.

[0070] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0071] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0073] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0074] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for the collaborative operation of Android and open-source HarmonyOS based on Linux containers, characterized by: include, Using Android as the host, a container isolation runtime domain is created on the host, enabling processes, network, and mount namespaces, and managing processor, memory, and input / output quotas through a control group, with pre-configured binder virtualization and tri-state resource templates; Deploy and adapt the open-source HarmonyOS in an isolated operating domain, enabling it to share the kernel with Android; Mount the selected directory using directory binding, configure the network according to bridging or address translation, and establish copy-on-write and snapshot identifiers; A cross-system binding mechanism between Android and open-source HarmonyOS is established as the control channel. Combining local domain sockets and shared memory, service registration agents are set up in the service managers on both sides to complete the mapping of service names, handles and permission domains. Perform system switching without restarting, make one side the foreground and the other the background through the foreground interface, continuously assign values ​​to the control group parameters according to the three-state resource template, freeze the background session and limit the background heartbeat, and roll back according to the snapshot in case of an anomaly.

2. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 1, characterized in that: Mount the binder device file system independent instance in the inter-process communication namespace, generate instance nodes and register instance identifiers; write the instance node path and permissions into the resource and security whitelist, and maintain it by the container lifecycle hooks during creation, destruction and restart.

3. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 2, characterized in that: Establish resource and security whitelists: The directory whitelist is generated in topology order according to parent and child paths and is used for the order of directory binding and mounting. The network whitelist is listed by protocol, port, and direction. The device capability whitelist is recorded in pairs of device nodes and agent handles and written to disk.

4. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 3, characterized in that: Deploy open-source HarmonyOS with a read-only root and a copy-on-write layer, and generate a snapshot identifier after configuring network bridging or address translation. Record the snapshot identifier and the container's network identity at that time in a rollback list.

5. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 4, characterized in that: Set up service registration agents in front of the service managers of Android and open-source HarmonyOS respectively, read the service directory to create cross-system endpoints one by one, form a list of service names and endpoints that correspond one-to-one, and persist the data on both sides for querying.

6. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 5, characterized in that: Based on the service registration results, handle mapping and permission domain mapping are established. Container-side handles are generated according to the handshake process, and mapping entries, user identifiers and security domain labels are recorded on both sides. Reference counting and recycling rules are set, and the entries are included in the handle mapping table.

7. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 6, characterized in that: The data channel includes shared memory and local domain sockets: shared memory is used and allocated in the page pool when message pages are aligned and file descriptor handover is not required; otherwise, local domain sockets are used and event notification and file descriptor handover are completed through this channel, with the path and endpoints registered in the manifest.

8. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 7, characterized in that: Switching admission involves receiving a switching instruction, reading the service mapping list and handle mapping table, confirming that all necessary services have cross-system endpoints and that the corresponding handles have mappings on the container side, and then triggering the session freezing and resource assignment process.

9. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 8, characterized in that: Resource assignment adopts a time-continuous method, in which the background quota vector is transformed into the front-end quota vector according to the preset segmented weight sequence, and the target files of the three control groups of processor, memory and input / output are written and recorded component by component according to time slice.

10. The method for dual-system collaborative operation of Android and open-source HarmonyOS according to claim 9, characterized in that: Session freezing and resuming involves generating a freeze list and recording the window stack, activity context, and session handle; During restoration, the list is rebuilt item by item and a callback verification is triggered; the frozen list is managed by number, and unfreezing and rollback are performed in numerical order.

Images