Embedded intelligent device, system starting method and device thereof and medium

Abstract

The invention relates to embedded intelligent equipment, a system starting method and device thereof and a medium, and the method comprises the steps: responding to a system starting signal, and loading and running a system kernel of a pre-configured first operating system to drive hardware resources of the embedded intelligent equipment; in a first user space environment created by a system kernel starting initialization process, independent file system resources are created for a second operating system, and the second operating system and the first operating system are heterogeneous; mapping an access path of a runtime resource of the file system resource to a global file path of the first user space environment by creating a symbolic link, and constructing a second user space environment corresponding to a second operating system; and the initialization process is ended, so that support is provided for application programs of the first user space environment and the second user space environment based on the shared access capability of the system kernel to the hardware resources. According to the method and the device, millisecond-level dynamic switching of the double systems without restarting is realized, and meanwhile, the native performance and efficient resource utilization are ensured.

Description

Technical Field

[0001] This application relates to the field of smart homes, and more particularly to an embedded smart device and its system startup method, apparatus, and medium. Background Technology

[0002] In the field of embedded smart devices, especially in interactive terminals such as central control screens in smart homes, Android is typically used as the main operating system to provide a rich ecosystem of graphical applications and a user-friendly interface. However, as the complexity of device functions increases, many scenarios require calling command-line tools, local services, or hardware control programs developed based on standard Linux, which often cannot run directly in the Android environment. Therefore, the industry has explored various technical solutions to achieve multi-system support.

[0003] A common approach is to create a Linux root file system within the Android system using chroot technology and then access the Linux graphical interface via remote desktop protocols such as VNC. While this approach is relatively simple to implement, it essentially runs the Linux environment on top of the Android system. This results in the Linux environment becoming heavily dependent on the Android kernel, unable to independently utilize specific kernel features, experiencing latency in graphical transmission, and being limited by Android's security mechanisms, making it difficult to obtain full permissions and leading to poor compatibility.

[0004] Another approach is to utilize virtual machine or container technologies, such as running another system on Android via a hypervisor or Docker. This approach achieves environment isolation through a virtualization layer, but it introduces significant performance overhead, consuming additional memory and processor resources, making it unsuitable for resource-constrained embedded devices. Furthermore, the virtualized environment has limited direct access to hardware, impacting the real-time performance of peripheral control.

[0005] Another approach borrows from the dual-boot method of traditional personal computers, creating separate partitions on the storage device to install Android and Linux systems respectively, and selecting the bootloader. This approach achieves complete isolation between the systems, but each switch requires a device restart, which can take several minutes and cannot meet users' needs for real-time switching. Furthermore, the two systems cannot share applications and library files, resulting in low storage space utilization. Identical functionalities also require separate development and maintenance, leading to higher costs.

[0006] In summary, traditional technologies all have significant drawbacks in embedded intelligent devices, including high performance degradation, poor compatibility, low switching efficiency, and severe resource waste. Therefore, there is an urgent need in this field for a solution that enables lightweight coexistence of dual systems and rapid dynamic switching without restarting the device or introducing virtualization overhead. Summary of the Invention

[0007] The primary objective of this application is to solve at least one of the above-mentioned problems by providing an embedded intelligent device and its system startup method, apparatus, and medium.

[0008] To achieve the various objectives of this application, the following technical solution is adopted: A startup method for an embedded intelligent device system provided for one of the purposes of this application includes the following steps: In response to the system startup signal, the system kernel of the pre-configured first operating system is loaded and run to drive the hardware resources of the embedded intelligent device; Within the first user space environment created by the system kernel's initialization process, an independent file system resource is created for the second operating system, which is heterogeneous with the first operating system. By creating symbolic links, the access paths of the runtime resources of the file system resources are mapped to the global file paths of the first user space environment, thereby constructing a second user space environment corresponding to the second operating system. The initialization process is terminated, thereby providing support for applications in the first user space environment and the second user space environment based on the system kernel's ability to share access to the hardware resources.

[0009] An embedded intelligent device system startup apparatus, proposed to meet one of the purposes of this application, is an embedded intelligent device system startup method, comprising: The startup loading module is configured to respond to the system startup signal and load the system kernel of the pre-configured first operating system to drive the hardware resources of the embedded intelligent device. The initial configuration module is configured to create independent file system resources for the second operating system within the first user space environment created by the system kernel's startup initialization process, wherein the second operating system is heterogeneous with the first operating system; The link mapping module is configured to map the access path of the runtime resources of the file system resources to the global file path of the first user space environment by creating symbolic links, thereby constructing a second user space environment corresponding to the second operating system. The system supports a startup module that is configured to terminate the initialization process, thereby providing support for applications in the first user space environment and the second user space environment based on the system kernel's ability to share access to the hardware resources.

[0010] In another aspect, an embedded intelligent device provided for one of the purposes of this application includes a controller, the controller including a processor and a memory, the processor calling and running a computer program in the memory to perform the steps of the embedded intelligent device system startup method.

[0011] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the described embedded intelligent device system startup method, which, when called by a computer, executes the steps included in the corresponding method.

[0012] This application achieves lightweight coexistence and dynamic switching of dual systems in embedded intelligent devices by building and integrating two user-space environments on the same system kernel, bringing several significant advantages, including but not limited to: First, this application fundamentally avoids the performance overhead caused by traditional virtualization or container technologies. Since the dual environments directly share the underlying kernel and hardware driver services, the application's access requests to the hardware do not need to go through any intermediate conversion layer, thus achieving near-zero loss of native performance. It is particularly suitable for resource-constrained embedded scenarios and ensures the real-time response of the system.

[0013] Secondly, compared to dual-partition solutions that require a restart to switch systems, this application uses path mapping and integration at the file system level to allow two user space environments to run in parallel immediately after system startup. When switching runtime environments is required, only the application's execution context needs to be adjusted. This process is completed within milliseconds without interrupting the current device operation or requiring a restart, greatly improving the smoothness of the user experience and meeting the urgent need for seamless function switching in application scenarios such as smart homes.

[0014] Furthermore, this application effectively solves the resource waste problem caused by system isolation. By mapping the critical runtime resources of the second system to the global path of the first system through symbolic links, the two operating systems can share the same underlying kernel and library files, avoiding the need to allocate independent and complete storage space for each system, significantly improving the utilization efficiency of storage resources and reducing hardware costs. At the same time, this organic integration method also overcomes the inherent defects of chroot and other solutions, such as restricted permissions and incomplete functionality due to environment dependence on the host system, providing applications with a more equitable and complete runtime environment. Attached Figure Description

[0015] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the embedded intelligent device system startup method of this application; Figure 2 This is a schematic block diagram of the embedded intelligent device system startup device of this application; Figure 3This is a schematic diagram of the structure of an embedded intelligent device used in this application. Detailed Implementation

[0016] The technical solution of this application can be widely applied to various embedded smart devices, especially in interactive terminals in the smart home field such as central control screens and smart panels, where it has significant value. These devices typically use embedded chips as their processors, such as system-on-a-chip (SoC) models like PX30 or RK356, and are equipped with necessary memory, storage, and various peripheral interfaces. Embedded smart devices connect to other smart devices in the home network via a local area network or bus, undertaking tasks such as centralized control, information display, and edge computing.

[0017] This application provides a method for booting an embedded device system, aiming to achieve collaborative operation of a first operating system and a second operating system on a single hardware platform. For ease of understanding, the basic concepts involved in this application are first explained. The first operating system typically refers to a system optimized for mobile devices, such as the Android system, which provides a rich ecosystem of graphical applications. The second operating system refers to a system heterogeneous to the first operating system, such as a standard GNU / Linux distribution, which provides different software development environments and system services. The system kernel, as the core of the operating system, is responsible for managing hardware resources and providing a runtime environment for upper-layer applications. The user space environment refers to the software environment above the system kernel, providing the necessary libraries, tools, and configurations for application execution.

[0018] This application enables a pre-configured system kernel to support both heterogeneous user-space environments simultaneously. In conjunction with this, an independent file system resource is created for the second operating system during system startup, and its runtime resources are organically integrated into the global file path view of the first operating system through path mapping mechanisms such as symbolic links. This is not simply file storage, but rather the construction of a unified runtime framework that allows applications in both environments to directly call hardware drivers based on the same system kernel, thus logically forming two different user-space environments that are both isolated and share basic resources.

[0019] The computer program implemented based on the method of this application can be integrated into the firmware of an embedded smart device and loaded and executed by the bootloader when the device starts up. This program is responsible for completing a series of processes from system initialization and environment building to service coordination. The higher-level value of this application lies in the seamless collaboration of various applications running on this unified framework. For example, users can simultaneously use the rich applications of Android and the professional tools of Linux on the same interface without worrying about the underlying system switching details, thus achieving an efficient and seamless user experience.

[0020] Having clarified the above application scenarios and core concepts, the following will further elaborate on the implementation details of the technical solution of this application in conjunction with specific embodiments.

[0021] Please see Figure 1 In some embodiments, the embedded intelligent device system startup method of this application can be implemented as an application program running in the processor of the embedded intelligent device. The method includes: Step S3100: In response to the system startup signal, load and run the system kernel of the pre-configured first operating system to drive the hardware resources of the embedded intelligent device; Once the embedded smart device powers on or receives a system boot signal such as a reset signal, the loading process can begin. This system boot signal is a hardware-level trigger event that prompts the bootloader to transfer control to the pre-configured kernel of the first operating system. Pre-configuration here refers to the fact that the system kernel has undergone necessary optimizations and customizations during the compilation phase for the specific scenario of dual-system coexistence. Specifically, this pre-configuration includes, but is not limited to, the following: First, the kernel configuration enables the kernel features and driver modules necessary to simultaneously support the operation of both the first and second operating system user spaces, such as ensuring compatibility with Android-specific drivers and standard Linux system calls; second, the kernel can integrate specific patches or modules to better manage shared access to hardware resources in the subsequently created dual-user-space environment.

[0022] Loading and running the pre-configured system kernel is fundamental to all subsequent steps. Once the system kernel is loaded into memory and begins execution, its primary task is to initialize and drive the hardware resources of the embedded intelligent device. These hardware resources include the central processing unit, memory controller, storage devices, various input / output interfaces, and device-specific peripherals such as graphics processing units, audio codecs, or network controllers. The kernel provides a stable and unified hardware access interface to upper-layer software through its built-in drivers and hardware abstraction layer.

[0023] In this process, the system kernel boot procedure follows the standard Linux kernel boot sequence, but its ultimate goal is to prepare for building a hybrid environment that supports dual-system coexistence. Unlike traditional kernels that only serve a single operating system, the system kernel in this embodiment clearly states from the beginning that it needs to support two heterogeneous user space environments. Therefore, when initializing its own data structures and managing hardware resources, the kernel reserves or configures corresponding mechanisms to ensure that the two user space environments created subsequently can share these underlying resources equally and efficiently without conflicts.

[0024] The system kernel implemented in this application is, in practice, a modification of the native Android kernel. Although Android is based on the Linux kernel, it has undergone extensive customization and trimming to meet the specific needs of mobile devices. While these customizations support a rich mobile ecosystem, they also result in poor compatibility with certain components of standard Linux distributions. Therefore, to achieve dual-system coexistence, this application makes targeted modifications to the native Android kernel, making it a unified foundation capable of simultaneously and effectively supporting both the Android user space and the standard Linux user space.

[0025] The first step involves adjusting the kernel configuration and adding functional modules. In practice, developers reconfigure the kernel's compilation options, including enabling options that might be disabled or not included by default in the standard Android kernel, such as full FUSE filesystem support, specific pseudo-terminal device number extensions, and full POSIX standard feature support. These options are fundamental to the proper functioning of many standard Linux applications and system services. Simultaneously, drivers or subsystems compiled as modules are forcibly compiled into the kernel image as needed to ensure they are accessible to all user-space environments in the early stages of initialization, avoiding environment dependency differences caused by module loading timing issues.

[0026] Secondly, a specific mechanism for dual-environment resource management is integrated into the kernel. This is achieved by enhancing the process management or namespace modules within the kernel. While this application does not rely on full container virtualization technology to avoid performance overhead, it introduces a lightweight context labeling mechanism. The kernel can label processes from different userspace environments for differentiation during scheduling, resource quota management, or security policy application. For example, the kernel can extend its security module to define label-based access control rules, ensuring that applications in the Android environment and applications in the Linux environment have both the necessary permissions and are subject to reasonable constraints when accessing specific device nodes, thereby maintaining overall system security.

[0027] Furthermore, corresponding adaptations have been made to the kernel-level drivers or middleware layers for critical shared resources such as graphics display. Specifically, the kernel's graphics driver framework or memory management subsystem is modified beforehand. The goal is to allow multiple independent graphics compositors or display servers, such as Android's SurfaceFlinger and Linux's standard Wayland or X Server, to access and share the same display buffer or GPU resources in a collaborative rather than exclusive manner. To this end, a simple arbitration layer is also implemented in the kernel, responsible for receiving display submission requests from different environments and coordinating them according to predefined strategies, providing underlying support for subsequent upper-layer graphical interface fusion services.

[0028] Furthermore, adaptive modifications are made to ensure the integrity and compatibility of system calls. The Android system sometimes uses its proprietary Bionic C library, whose implementation of certain system calls differs from the standard Glibc. The kernel needs to ensure that its system call interface can simultaneously meet the requirements of these two different C libraries to avoid application crashes due to inconsistent behavior. This application adaptively traces back and restores certain system call behaviors modified by Android vendors that deviate from standard Linux specifications, and provides an additional compatibility layer to adapt to different calling conventions.

[0029] By modifying the native kernel as described above, the original native kernel, which was exclusive to the Android ecosystem, has been transformed into a more comprehensive and compatible system kernel. It retains the ability to drive the Android application ecosystem while providing native-level support for the standard Linux userspace environment. It should be noted that, given the complexity and tediousness of the system kernel modification process, and the need for flexible adjustments to adapt to different requirements, this application only provides the above example of the system kernel customization process based on its own practical experience. Since this application has clearly defined the functions that the system kernel needs to implement, those skilled in the art can implement their own system kernel customization based on these functional examples. Therefore, the above examples are only for a deeper understanding of the specific implementation of this application and should not be used to limit the scope of protection of this application.

[0030] Step S3200: Within the first user space environment created by the system kernel startup initialization process, an independent file system resource is created for the second operating system, which is heterogeneous with the first operating system. After the system kernel successfully loads and completes basic hardware driver initialization, the kernel initiates the initialization process. This initialization process is led by the first user-space process started by the kernel, such as the init process of the Android system, which parses and executes its initialization configuration file. In this process, the creation and basic configuration of the first user-space environment are first completed. This environment includes the first operating system, such as the Android system, and all the basic directories, system libraries, daemons, and configuration files necessary for its operation.

[0031] Within the established first user space environment framework, independent file system resources are further created for the second operating system. Here, file system resources are a collective concept, referring to the complete set of all files and directories required for the second operating system to run independently. Their independence is reflected in the fact that these resources are physically stored separately from the core file system of the first operating system, thus avoiding direct interference such as file overwriting and version conflicts. In one embodiment, creating independent file system resources specifically includes a series of ordered operations.

[0032] First, the initialization process creates and mounts a temporary file system in memory according to its configuration script. This temporary file system is typically of type tmpfs, which has the advantage of extremely fast read and write speeds, and all content is stored in volatile memory and automatically cleared after a system restart, making it ideal for storing temporary data generated during system operation. This temporary file system provides high-speed and secure storage space for temporary files generated by the secondary operating system during subsequent operation, such as cache files, socket files, or lock files.

[0033] Secondly, on the non-volatile storage medium of the embedded intelligent device, specifically within the user data partition, a directory structure is created for persistently storing the root file system of the second operating system. For example, a custom directory named "dreame" can be created under the system's user data partition (the "data" partition), and further subdirectories such as "target" can be created under it, forming a complete directory tree skeleton to house the second operating system. This step provides the physical storage location for the entity files of the second operating system.

[0034] Finally, the complete root filesystem, including the second operating system, such as a streamlined GNU / Linux distribution, is deployed to the previously created directory structure. This complete root filesystem is a self-contained collection of software that must include the binary executables of the second operating system, such as the system core toolset bash, cp, mv, etc., various dynamic link libraries and static library files, such as the C standard library glibc, and system-level and application-level configuration files, such as network configuration and environment variable settings. Deployment methods can include, but are not limited to, the following: In one embodiment, a pre-made root filesystem image file can be decompressed to the target directory; in another embodiment, the filesystem package can be downloaded from a server over a network and expanded; in yet another embodiment, the filesystem can be directly written to a specified location on the storage medium during device manufacturing.

[0035] Step S3300: By creating symbolic links, the access path of the runtime resources of the file system resources is mapped to the global file path of the first user space environment, thereby constructing a second user space environment corresponding to the second operating system. After successfully creating independent file system resources for the second operating system, symbolic links are then created to organically integrate these resources into the global file path view of the first user space environment, thus logically constructing the second user space environment. This process utilizes the file system characteristic of symbolic links to achieve transparent path redirection, enabling the runtime resources of the second operating system to be correctly discovered and accessed by the system.

[0036] A symbolic link is a special file whose content contains path references to another file or directory. When an application or system tool attempts to access the symbolic link, the operating system can automatically resolve it and redirect it to the actual target it points to. In this embodiment, the specific operations for creating symbolic links include, but are not limited to, the following: First, a series of symbolic links pointing to key directories in the root file system of the second operating system are created under the root path of the first user space environment. For example, a symbolic link named bin can be created in the root directory, pointing to an actual binary directory in the root file system of the second operating system, such as pointing to a specific path in the previously created directory structure. Similarly, a symbolic link can be created for the usr directory, pointing to the user program directory of the second operating system, and a symbolic link can be created for the lib directory, pointing to the library file directory of the second operating system. These mappings of key directories ensure that when the system searches for executable files or library files in standard paths, it can seamlessly find the corresponding resources provided by the second operating system.

[0037] The path mapping mechanism described above essentially constructs a virtual root file system view for the second operating system, conforming to its expected structure. This view is overlaid on the native file system of the first operating system, together forming a unified global file path namespace. When applications in the second operating system run, their access requests to standard system paths, such as attempting to execute commands located in the bin directory or loading dynamic libraries located in the lib directory, are automatically redirected to the actual file locations in the second operating system via symbolic links. This redirection is transparent to the application itself; the application can run normally without any modification, as if it were in a native second operating system environment.

[0038] The process of constructing a second user-space environment includes not only mapping file paths but also configuring the runtime environment. Based on the created symbolic links, the search paths for applications running on the second operating system can be defined. This can be achieved by setting specific environment variables, such as the PATH environment variable which defines the search order for executable files, and the LD_LIBRARY_PATH environment variable which specifies the loading path for dynamic link libraries. In one embodiment, these environment variables can be explicitly set to include the directories mapped via symbolic links in the script or program that launches the second operating system application. For example, setting the PATH environment variable to include a symbolic link path pointing to the bin directory of the second operating system ensures that the shell or launcher can find the correct executable file in that path.

[0039] Step S3400: End the initialization process, thereby providing support for applications in the first user space environment and the second user space environment based on the shared access capability of the system kernel to the hardware resources.

[0040] After successfully loading the system kernel, initializing hardware resources, creating the first user space environment, deploying the independent file system resources of the second operating system, and building the second user space environment through symbolic links, the system initialization process enters its final stage. The completion of the initialization process signifies that the system has formally transitioned from an initial state with only basic boot capabilities to a ready state that provides stable and complete operational support for upper-layer applications.

[0041] The completion of the initialization process is manifested in the fact that the first user-space process started by the system kernel, such as Android's init process, has completed all the critical initialization scripts and actions in sequence. These actions include, but are not limited to, starting the core system daemon, configuring network interfaces, setting file system permissions, and most importantly, completing the construction and integration of the aforementioned dual-user-space environment. At this point, system control is transferred from the pure initialization sequence to the normal operation phase, which awaits the processing of dynamic events and user interactions.

[0042] The direct technical effect of ending the initialization process is that, based on the system kernel's ability to share hardware resources, it provides support for applications in both the first and second user space environments. This support is a comprehensive capability. First, it means that the application's runtime environment is ready. Applications from both the first and second operating systems can now be loaded and executed. When an application is invoked, the application loader can find the correct executable file and dependent libraries in its corresponding user space environment, thanks to the symbolic link mappings and runtime search path definitions established in previous steps.

[0043] Secondly, the core support capability lies in application access to hardware resources. Since both user-space environments share the same pre-configured system kernel, any system call issued by an application, whether from the first or second user-space environment, will be handled by this unified kernel. For example, when an application in the first operating system requests to open a camera device file, or a command-line tool in the second operating system attempts to read or write a GPIO port, these requests are ultimately handled by the same kernel driver. This architecture fundamentally avoids the system call translation overhead of virtualization solutions and eliminates the hardware state continuity issues that dual-partition solutions cannot achieve due to the need for reboots, thus achieving truly lossless native performance and seamless hardware sharing.

[0044] Finally, the system boots up and enters a stable operating state. At this point, the embedded intelligent device has the ability to simultaneously support applications from two heterogeneous ecosystems. Users or system services can launch applications from either environment as needed. These applications run as if they were in their respective native systems, yet can directly and efficiently share underlying hardware resources. This state provides an indispensable foundational platform for subsequent higher-level functions, such as scheduling decisions for environment coordination services and interface composition for graphical interface fusion services.

[0045] As can be seen from the above embodiments, this application achieves efficient coexistence and collaborative operation of two systems on a single hardware platform through a series of innovative technical means. Compared with traditional technical solutions, it has achieved significant technical advantages in many aspects, including but not limited to: First, this application completely eliminates the performance overhead of system virtualization, achieving native-level access efficiency to hardware resources. Traditional virtual machine or container solutions isolate the environment by introducing a virtualization layer between the hardware and the operating system. This intermediate layer inevitably introduces additional computational burdens such as instruction translation and memory address mapping, resulting in performance losses typically ranging from 10% to 30%, which is unacceptable for embedded devices with limited computing resources. This application takes a different approach, using a pre-configured single system kernel and leveraging symbolic links for path integration at the file system level. This allows applications in two user-space environments to directly initiate system calls to the same system kernel without any intermediate translation. This architecture ensures that applications have the shortest access path to critical resources such as hardware drivers, memory, and processors, with almost zero performance loss, providing crucial real-time guarantees for embedded applications.

[0046] Secondly, this application achieves millisecond-level dynamic environment switching without requiring a device restart, significantly improving user experience and system flexibility. Traditional dual-partition boot solutions require a complete shutdown and reboot of the current system when switching operating systems, a process that takes several minutes and cannot meet the demands of instant interaction. This application simplifies environment switching to adjusting the application's runtime context by pre-constructing a coexisting dual-user space environment. When an application in another environment needs to run, there is no need to interrupt currently running services or processes; the application is simply loaded into the corresponding environment through mechanisms such as environment coordination services. This switching is completed instantaneously in the background, and the user only perceives the rapid launch of the application, thus achieving seamless and smooth switching between different ecosystem applications. This provides an ideal technological foundation for application scenarios requiring the integration of multiple functions, such as smart home control screens.

[0047] Furthermore, this application significantly improves storage space utilization efficiency and reduces hardware costs through a clever resource integration mechanism. In dual-partition schemes, each operating system requires a complete root file system, system libraries, and applications, resulting in significant storage space redundancy. This application, however, maps the critical runtime resources of the second operating system to the global path of the first operating system, allowing both environments to share the same underlying system kernel and many basic system library files. This design avoids the need to allocate independent, complete storage space for each system, and is estimated to save 30% to 40% of storage space. In the context of cost-sensitive embedded devices, this advantage is crucial for product competitiveness.

[0048] Furthermore, this application overcomes the fundamental shortcomings of traditional Chroot and other similar solutions, achieving equal coexistence and full functional support for dual environments. In Chroot-based solutions, the second environment heavily relies on the kernel of the first environment, cannot utilize specific kernel features, and is limited by the host system's security mechanisms, making it difficult to obtain full root privileges and resulting in poor compatibility. This application, by using a system kernel tailored for dual-environment coexistence and organically integrating it at the file system view level, enables the second user space environment to directly use all kernel functions and enjoy equal resource access permissions. This provides a complete runtime environment for Linux applications requiring specific kernel versions or modules, solves the compatibility problem, and expands the application scope of embedded devices.

[0049] Based on any embodiment of the method in this application, within a first user space environment created by the system kernel, an independent file system resource is created for the second operating system, including: Step S3210: The system kernel starts the initialization process according to the initialization configuration file, creates and mounts a temporary file system in memory to provide temporary file storage for the operation of the second operating system; The system kernel initiates the initialization process based on the initialization configuration file, creating and mounting a temporary file system in memory. This temporary file system is primarily used to provide temporary file storage for the second operating system. The initialization configuration file can be an `init.rc` file, which encapsulates the corresponding scripts. In one embodiment, the temporary file system uses the `tmpfs` type. This system is a virtual memory-based file system where all data is stored in volatile memory, thus offering extremely high read and write speeds. The temporary file system can be created using the `mkdir` command to create the mount point directory, for example, creating a `tmp` directory in the root directory, and then using the `mount` command to mount it to that directory as a `tmpfs` file system. This temporary file system provides dedicated storage space for various temporary data generated by the second operating system during operation, such as application caches, session socket files, and process lock files. Since these data have short lifecycles and high I / O performance requirements, placing them in a memory file system significantly improves system response speed. Furthermore, the automatic clearing of `tmpfs` after a system restart ensures natural cleanup of temporary data without additional management overhead.

[0050] Step S3220: Create a directory structure within the user data partition of the embedded intelligent device for storing the root file system of the second operating system; The process continues by creating a directory structure within the user data partition of the embedded intelligent device to store the root file system of the second operating system. The user data partition is typically a read-write area on the device's non-volatile storage medium, specifically designed to store user data and modifiable system data. Creating the directory structure provides an organized and stable storage location for the persistent files of the second operating system. In one embodiment, the initialization process can create a specific top-level directory, such as "dream," under the user data partition, and further create subdirectories such as "target" within this directory, forming a complete directory tree skeleton. This clearly defines the ownership path of the second operating system files at the physical storage level, completely separating them from the core read-only system partition of the first operating system. This fundamentally avoids problems such as name conflicts, version conflicts, or accidental deletions that may result from mixed file storage, ensuring the independence and integrity of the two system resources.

[0051] Step S3230: Deploy the complete root file system containing the binary executable file, library files, and configuration files of the second operating system as an independent file system resource into the directory structure.

[0052] Finally, the complete root file system, containing the binary executable files, library files, and configuration files of the second operating system, can be deployed as an independent file system resource within the aforementioned directory structure. This complete root file system is a self-consistent software assembly and the physical foundation upon which the second operating system runs. The deployment method can be flexibly chosen according to actual production or deployment needs. In one embodiment, during the device production stage, a pre-made root file system image containing all necessary files can be directly burned or decompressed into the target directory. In another embodiment, for devices that support network updates, the file system package can be downloaded from a designated server via protocols such as HTTP or FTP during the first boot, and then verified and decompressed locally. In yet another embodiment, an incremental deployment approach can be adopted, first deploying a minimal basic root file system, and then dynamically installing additional software packages according to user needs. Regardless of the method used, the ultimate goal is to completely house all components required for the second operating system to run, including but not limited to shell tools, system daemons, shared libraries, and environment configuration files, within the specified directory structure, making it an independent file system resource that can be referenced at any time.

[0053] Through the above embodiments, an independent file system resource with both high-speed temporary storage capability and stable persistent storage space is systematically constructed for the second operating system. This ensures that the operating environment of the second operating system is fully guaranteed in terms of resource isolation, data persistence and I / O performance, thus laying the foundation for seamless integration through symbolic links. This is one of the key prerequisites for this application to achieve lightweight coexistence of dual systems and dynamic switching without restarting.

[0054] Based on any embodiment of the method in this application, by creating symbolic links, the access path of the runtime resources of the file system resources is mapped to the global file path of the first user space environment, thereby constructing a second user space environment corresponding to the second operating system, including: Step S3310: Create a symbolic link pointing to the corresponding directory in the root file system of the second operating system under the root path of the first user space environment; Symbolic links are special files provided by the file system, whose content is simply the pathname of another file or directory. When the system or an application attempts to access the symbolic link, the system kernel automatically resolves it and redirects it to the actual target it points to. In practice, the key standard directories upon which the second operating system depends are first identified, and corresponding symbolic links pointing to these standard directories are created in the root directory of the first user space environment. In one embodiment, symbolic links pointing to the second operating system's binary executable file directory can be created; for example, a symbolic link named "bin" can be created in the root directory of the first user space environment, pointing to the "usrbin" directory in the second operating system's root file system. Similarly, symbolic links pointing to the second operating system's library file directory can be created; for example, a symbolic link named "lib" can be created pointing to the actual library file directory. Symbolic links pointing to the second operating system's user program and header file directories can also be created; for example, a symbolic link named "usr" can be created pointing to the "usr" directory in the second operating system. The creation of these symbolic links essentially creates aliases or entry points for the core resources of the second operating system within the global file path view of the first user space environment.

[0055] Step S3320: Based on the created symbolic links, define an application run search path for the second operating system, wherein the search path contains directories mapped through the symbolic links.

[0056] Creating symbolic links alone provides static access points, but for an application to run, the system needs to actively search for the required executables and libraries within these entry points. This necessitates configuring appropriate runtime search paths. These search paths are a set of environment variables that inform the shell interpreter or dynamic linker which directories to search for commands or shared libraries in. In one embodiment, the search path for executables is defined by setting the PATH environment variable. In scripts that launch applications on the second operating system or in specific interactive shell environments, the value of the PATH environment variable is set to include directories mapped via symbolic links, such as symbolic link paths pointing to the bin directory of the second operating system. Equally important, the loading path for dynamic link libraries is defined by setting the LD_LIBRARY_PATH environment variable to include symbolic link paths pointing to the lib directory of the second operating system. This setting ensures that when attempting to run commands on the second operating system, the executable is loaded from the correct location, and that during program execution, the dynamic linker loads its dependent shared libraries from the correct directories, thus avoiding conflicts with library files from the first operating system.

[0057] This embodiment successfully integrates the static file resources of the second operating system into the system's runtime environment dynamically. This organically integrated application cleverly utilizes the symbolic link characteristics of the file system and the configuration mechanism of environment variables to build a complete and usable runtime context for the applications of the second operating system in a lightweight and zero-performance-loss manner. This enables the parallel existence and instantaneous invocation of dual-system applications without the need to copy files or restart the device, helping this application overcome the shortcomings of traditional dual-system solutions such as slow switching and resource waste.

[0058] Based on any embodiment of the method in this application, before ending the initialization process, the following is included: Step S4100: Generate the system configuration files necessary for the second operating system to run; After the logical construction of the second user space environment is basically completed, in order to ensure that the second operating system can run normally and securely, the generation and integration of the system configuration files necessary for its operation can be completed before the end of the entire system initialization process.

[0059] To this end, the first step is to generate the system configuration files necessary for the second operating system to run. These configuration files differ from static program binaries or library files; they contain key parameters, strategies, and dynamic information required for system operation. In one embodiment, the system configuration files to be generated include a network domain name resolution configuration file. This file, typically named resolv.conf, specifies the DNS server addresses used by the system when performing domain name resolution. Generating this file can be as simple as writing a text file containing the resolution server addresses and other information to a specific location. In another embodiment, the system configuration files to be generated are user account configuration files, such as the passwd file. This file defines valid user account information within the system, including username, user ID, group ID, home directory, and default shell. For a minimal second operating system environment, a basic version can be generated first, for example, containing only the root account configuration information, to ensure basic availability of system management functions. These configuration files can be dynamically created in the initialization script using commands such as echo, or copied from a pre-set template file.

[0060] Step S4200: Integrate the system configuration file into the global configuration path already constructed in the second user space environment through a file system linking or mounting mechanism, wherein the system configuration file includes a network domain name resolution configuration file and / or a user account configuration file.

[0061] Furthermore, the generated system configuration file can be integrated into the global configuration path already constructed in the second user space environment through file system links or mount mechanisms. Simply generating the configuration file is insufficient; it must be placed in the standard system configuration path that the applications of the second operating system expect to find in order to take effect. This can be achieved using file system links or mount mechanisms.

[0062] In one embodiment, symbolic links can be created. For example, the generated `resolv.conf` file can be placed in a location on the temporary file system `tmpfs`, and then a symbolic link named `resolv.conf` can be created in the standard configuration directory `etc` of the second user space environment, pointing to this temporary file. In another embodiment, for configuration files requiring higher isolation or security, a binding mount mechanism can be used. For example, the generated `passwd` file can be placed in a secure location on the data partition, and then the `mount --bind` command can be used to mount the file to the `etcpasswd` path in the second user space environment. This approach completely redirects access to the mount point to the source file, providing different semantics and characteristics than symbolic links. Either of these mechanisms seamlessly integrates externally generated configuration files into the standard configuration namespace of the second operating system.

[0063] Therefore, the above embodiments supplement the operation of the second operating system with indispensable strategies and dynamic information layers, ensuring that the second operating system not only has executable program files, but also correct network connectivity and basic user management capabilities, transforming it from a static collection of files into a fully functional runtime environment ready for immediate use. This significantly improves the practicality and robustness of the entire dual-system solution and is an important guarantee for ensuring that applications on the second operating system can run without errors and with high performance.

[0064] Based on any embodiment of the method in this application, after the initialization process is completed, the following is included: Step S5100: Load and run the environment coordination service for arbitration resource and scheduling applications; After the system initialization process is successfully completed and both the first and second user space environments are ready, the embedded intelligent device can shift from static environment construction to dynamic application scheduling and management. For this purpose, a dedicated service, namely the environment coordination service, needs to be loaded and run to undertake this responsibility.

[0065] The environment coordination service is implemented as a persistent background system daemon, designed to arbitrate resources and schedule applications, acting as an intelligent command center in a dual-system environment. This service can be loaded and run by the system's initialization process, such as Android's init process, after the basic system services have started, based on the service definitions in its initial configuration file. In one embodiment, the service can be a standalone executable file, directly forked and executed by the init process; in another embodiment, it can be loaded and initialized as an extension module of a core system service, such as ActivityManagerService.

[0066] This environment coordination service is responsible for arbitrating resources. In a scenario where two environments share the same set of hardware resources, when applications from different user space environments may concurrently request access to certain mutually exclusive resources, such as a specific sensor device or audio playback channel, the environment coordination service needs to arbitrate according to a preset strategy to determine which application's request will be prioritized, thereby avoiding conflicts and ensuring system stability and determinism. This requires the service to have a global resource view and decision-making capabilities.

[0067] Meanwhile, a more critical responsibility of the environment coordination service is application scheduling. To this end, it needs to determine in which user space environment a specific application should be launched, based on user intent or system events. To achieve this, the service can initialize and maintain necessary internal states and data after startup. In one embodiment, a predefined mapping table can be read, recording the correspondence between known application package names or executable file paths and their required runtime environments. In another embodiment, more complex judgment logic can be integrated, such as analyzing the format of the application's binary file or its dependent libraries, to dynamically infer its host environment.

[0068] The loading and operation of the environment coordination service marks the system's formal transition from the basic platform preparation phase to the intelligent operation phase focused on user services. Subsequently, it can receive environment switching requests, intelligently determine and schedule applications to achieve seamless integration and efficient collaboration between the two systems.

[0069] Step S5200: Listen for environment switching requests triggered by enabling the target application through the environment coordination service; After the environment coordination service is successfully loaded and running, it continuously listens for specific events from inside or outside the system, namely environment switch requests. The purpose of this request is to enable a specific target application and implicitly or explicitly indicate that it needs to be prepared for or switched to a suitable runtime environment.

[0070] Listening for environment switching requests through the environment coordination service means that the service needs to establish one or more event listening mechanisms to capture these requests in a timely manner. The specific implementation of the listening can vary depending on the source of the request and the system design. In one embodiment, the environment coordination service can run as a local socket server or a D-Bus service. When a user clicks an application icon in the foreground graphical user interface, or when a system automation rule is triggered, the graphical interface fusion service or rule engine sends a structured message to the communication endpoint registered with the environment coordination service via inter-process communication. This message constitutes an environment switching request and contains the identifier of the target application.

[0071] In another embodiment, the listening mechanism can be based on file system events. For example, the environment coordination service can monitor a specific directory. When an application needs to be launched, the relevant launcher or script creates a specific flag file or writes a command in that directory. The environment coordination service detects this change through the file system monitoring interface and reads the file content to parse detailed information about the environment switching request. Alternatively, listening can be based on system broadcasts or specific signals. The environment coordination service can register with the system to receive global broadcast messages about application launch intentions, or listen to a specific named pipe to read request commands written by other processes.

[0072] Regardless of the specific monitoring technology used, the goal remains the same: to ensure that the environment coordination service can reliably receive instructions intended to launch applications and potentially involve environment switching, acting as a resident, accessible central dispatch point.

[0073] Step S5300: In response to the environment switching request, the environment coordination service determines the target user space environment required by the target application based on the attributes of the target application, and instructs the application loader to load and execute the target application in the target user space environment.

[0074] When the environment coordination service detects an environment switching request through its listening mechanism, its core scheduling logic is triggered. In response to the request, the environment coordination service executes the corresponding decision-making and execution process, namely, determining the required target user space environment based on the target application's attributes, and ultimately instructing the application loader to complete the application startup.

[0075] The process of determining the target user space environment essentially involves mapping the attributes of the target application to the correct runtime environment. The application attributes here are the basis for this determination, and their specific forms can vary. In one embodiment, the application attribute can be its package name or the full path of the executable file. The environment coordination service can maintain a predefined mapping table that associates known application identifiers with specific user space environments. For example, when requesting to launch an application with the package name com.example.android.app, the mapping table is consulted to determine that it should run in the first user space environment; while when requesting to launch an interpreter with the path / usr / bin / python3, it is mapped to the second user space environment. In another embodiment, the application attribute can be its file format or dependencies. The environment coordination service can integrate simple analysis logic, such as using the file command to check the executable file's format; if it is the Android-specific ELF format, it belongs to the first user space environment; if it is the standard Linux ELF format, it belongs to the second user space environment; or checking its dynamic link library dependencies; if it depends on Android-specific libraries, it is determined to belong to the first user space environment. By comprehensively judging one or more of the above attributes, the environment coordination service can accurately allocate a suitable target user space environment for any target application.

[0076] Once the target user-space environment is identified, the environment coordination service instructs the application loader to load and execute the target application within that environment. The application loader is a system component responsible for launching specific processes. The environment coordination service itself typically does not create processes directly; instead, it issues instructions to the system service responsible for process management or a specific launcher component via inter-process communication.

[0077] In one embodiment, the environment coordination service can send a launch intent to the system's ActivityManagerService or a standard process incubator, attaching an explicit environment tag or specific launch parameters to indicate in which userspace environment the new process should be created. In another embodiment, the environment coordination service can directly call a custom wrapper script or helper program designed to accept environment identifiers and application paths as parameters, and constrain the runtime context of the new process to the target userspace environment before execution by setting specific environment variables. Regardless of the communication mechanism used, the ultimate goal is to ensure that the target application's process is created and runs in the correct target userspace environment, thereby enabling it to access the correct files, libraries, and configurations within that environment.

[0078] The above embodiments, building upon the existing dual-system coexistence, further construct a centralized, intelligent, dynamic application management framework. This framework can automatically and accurately identify the runtime environment requirements of applications and instantly schedule them to execute in the correct user space environment. This achieves seamless integration and automated management of cross-system application startup without manual user intervention or system restarts. This not only greatly simplifies user operations and improves interaction fluency but also effectively avoids application runtime errors caused by environment mismatches, significantly enhancing the practicality, robustness, and user experience of the entire dual-system solution.

[0079] Based on any embodiment of the method in this application, after the initialization process is completed, the following is included: Step S6100: Load and run the graphical interface fusion service; After the system initialization process is successfully completed, both the first and second user space environments are built and ready, and the environment coordination service used for arbitration and scheduling is loaded and running, unlike the traditional approach of using two operating systems mutually exclusively, this application further addresses a key presentation layer problem: how to integrate the graphical interface content from two independent user space environments and present it to the user in a unified manner. To this end, a specially customized graphical interface fusion service is loaded and run.

[0080] The graphical interface fusion service is implemented as a unified graphics compositor, receiving and managing graphics data streams from different sources. The loading and execution of this service can be triggered by the system initialization process during the late startup phase. In one embodiment, the service can be implemented as a standalone, high-privilege system daemon. The initialization process, such as Android's init process, directly derives and executes the service's executable file by making system calls via fork and exec, based on the service definition in its initial configuration file. In another embodiment, the graphical interface fusion service can also be designed as a deep extension of existing core graphics system services. For example, it can be loaded and initialized as an enhancement module of Android SurfaceFlinger, or integrated into the system as a Wayland compositor with special permissions.

[0081] Step S6200: Receive graphical interface output data from the first user space environment and the second user space environment through the graphical interface fusion service. The graphical interface fusion service receives graphical interface output data from various user-space environments through its specific implementation technology. In one embodiment, the service runs as a synthesizer, creating and listening to one or more inter-process communication endpoints. For example, it can run as a Wayland display server instance, listening for connection requests on a specific Unix domain socket. In this case, the graphics system in the first user-space environment, such as a modified Android SurfaceFlinger, is configured as a Wayland client, connecting to the socket and submitting its synthesized application interface as a Wayland buffer to the graphical interface fusion service. Simultaneously, the native Wayland client application in the second user-space environment, or its own Wayland synthesizer, can also connect to the same or different endpoints, submitting graphical content from the Linux environment. In this way, the service aggregates graphical data streams from two independent environments within a unified protocol framework.

[0082] In another embodiment, the receiving mechanism can be based on virtual display devices. The graphical interface fusion service utilizes the kernel's display driver, such as a DRM or FrameBuffer driver, to create multiple virtual display outputs. Each user-space environment's graphics system is configured to render its content onto a designated virtual display. For example, the Android system outputs its content to virtual display 1, while the Linux environment outputs its content to virtual display 2 via a lightweight X Server or Wayland compositor. The graphical interface fusion service, acting as a consumer of these virtual displays, periodically captures framebuffer data from each virtual display device via the DRM API or by directly reading the FrameBuffer memory. This approach achieves isolated acquisition of graphics data at the underlying level.

[0083] Regardless of the specific implementation used, the graphical interface fusion service can handle potential format differences between data sources when receiving graphical interface output data from various user space environments. For example, a graphics buffer from an Android environment might use a specific pixel format, while one from a standard Linux environment might use another. Therefore, the service can integrate a format conversion module to uniformly convert all received graphics buffers into an internally consistent format for subsequent compositing and display.

[0084] Step S6300: Combine the graphical interface output data and display them in the same graphical user interface.

[0085] After the graphical interface fusion service successfully receives graphical interface output data from the first user space environment and the second user space environment, it continues to be responsible for integrating these graphical data streams from different sources and with independent content, and finally presenting them as a unified and coherent graphical user interface on the device's physical display screen. The graphical interface fusion service first processes and composites the received graphics buffer. In one embodiment, the service acts as a unified compositor, creating corresponding layers for each source of graphics data stream. For example, output from an Android environment is assigned a background layer, while terminal window output from a Linux environment is assigned a foreground layer. Internally, the service maintains a global compositing scene graph, determining the position, size, and stacking order of each layer based on a preset layout strategy or dynamic window management state. Subsequently, the compositing engine traverses the scene graph, blending the contents of each layer into a final framebuffer in the correct order. This process may include alpha blending, scaling, rotation, and other graphics transformation operations to ensure that visual elements from different sources can coexist harmoniously in the same frame.

[0086] In another embodiment, the merged display can employ a more dynamic view management strategy. For example, the graphical interface fusion service can default to a split-screen layout, dividing the physical screen into two areas to display the desktop content of two user space environments respectively. Alternatively, an overlay mechanism can be implemented, where the interface of one environment is displayed full-screen as the main desktop, while the key application windows of the other environment are displayed as floating windows that are always on top of the main desktop. These strategies allow users to see and operate applications in both environments simultaneously, breaking down the visual barriers between systems.

[0087] Finally, the synthesized final image frame is submitted to the display hardware for output. The graphical interface fusion service drives the screen refresh by calling the system's underlying display driver interface to swap the frame buffer containing the merged content to the foreground. In one embodiment, the service directly submits the final frame to the kernel's display subsystem. In another embodiment, under a more complex architecture, the synthesized frame may first be submitted to a lower-level display controller for final timing adjustments before being output to the screen.

[0088] As can be seen, by leveraging the graphical interface fusion service capabilities of the above embodiments, the user ultimately sees not an environment-specific interface on the embedded smart device's display, but an organically integrated view. For example, Android application icons and widgets may be displayed side-by-side with a Linux terminal window, or a Linux graphical application window may be embedded within the Android desktop environment. This merged display not only provides visual uniformity, but more importantly, it lays a direct foundation for subsequent intuitive cross-environment interaction, enabling users to interact naturally with applications in both environments as if operating a single system.

[0089] Based on any embodiment of the method in this application, after merging the graphical interface output data for display in the same graphical user interface, the method includes: Step S7100: Receive user interaction operations on the graphical user interface through the graphical interface fusion service; After the graphical interface fusion service merges and displays graphical interface output data from different user space environments onto the same graphical user interface, in order to achieve further intelligent interaction and understand user interaction intentions, the graphical interface fusion service receives user interaction operations on the graphical user interface as the starting point for subsequent logical judgments and system responses.

[0090] As the final graphical composite and display provider, the graphical interface fusion service naturally becomes the primary receiver of user input events. Therefore, a mechanism can be established to capture the input events corresponding to the original interactive operations. In one embodiment, the service can directly listen to the event source of the input device. For example, the service can open and read device files, such as devinputeventX, to directly obtain the raw input event data stream from the touchscreen, mouse, or keyboard. In another embodiment, on a system with a mature input management framework, the graphical interface fusion service can register with the system's input manager as a global input event listener. When the user touches or presses a key anywhere on the screen, the input manager will preferentially dispatch this event to the window with focus, or, in this scenario, to the graphical interface fusion service, which is the root display service.

[0091] The received interactive operations are typically low-level, unparsed raw events, such as a touch event containing coordinate information or a keyboard scan code. The graphical interface fusion service needs to perform preliminary processing and interpretation of these raw events. In one embodiment, the service includes an input event routing module. This module first determines which area of ​​the screen the event occurred in based on its coordinate information, and then determines which specific interface element it applied to. For example, by comparing the coordinates with the positions and ranges of layers in the current composite scene, it can be determined whether the user clicked an icon on the desktop background representing the first user space environment or a terminal window in the second user space environment.

[0092] After initial event localization, the graphical interface fusion service needs to determine the next processing logic based on the type and goal of the interaction. For certain system-level global gestures or clicks on specific control areas, such as the status bar or navigation bar, the service can handle them directly. However, for operations targeting specific application interface elements, the service needs to prepare for subsequent steps, such as recording the identifier of the operated element and its associated information.

[0093] Step S7200: When the interactive operation is applied to an application interface element representing a complete user space environment desktop, the graphical user interface is switched to full-screen display of the graphical interface output data of the target user space environment. After receiving user interaction commands through the graphical interface fusion service and determining that they act on application interface elements representing a complete user space environment desktop, it needs to respond to the user's explicit intent and provide a focused and immersive operating environment. At this point, the graphical interface fusion service performs the operation of switching the current graphical user interface to full-screen display of the graphical interface output data of the target user space environment.

[0094] The graphical interface fusion service first needs to identify the target user space environment associated with the interacting interface elements. In one embodiment, during the merging display, the service internally establishes clear layer identifiers for graphical outputs from different environments, each corresponding to its source user space environment. When a user clicks on an interface element, the specific layer is located by coordinate comparison, thus determining that the user intends to focus on the target user space environment represented by that layer. For example, on the merged desktop, if a user clicks on a Linux distribution terminal icon, the graphical interface fusion service identifies that the graphical data of the icon originates from a second user space environment, thereby determining the target user space environment as the second user space environment.

[0095] Next, the graphical user interface blending service can perform a display mode switch. It changes the current compositing and display mode from simultaneously displaying a blended view from multiple sources to displaying only the graphical output data from the target user space environment in full screen. In one embodiment, the graphical user interface blending service temporarily marks all non-target layers in its internal compositing scene graph as hidden and adjusts the position and size of the target layer so that it occupies the entire visible area of ​​the screen. Subsequently, the compositing engine generates the final output frame based solely on this full-screen target layer and submits it to the display hardware. In another embodiment, the switching can be implemented at a lower level. For example, the graphical user interface blending service can reconfigure the system display controller from a mode that receives and blends multiple graphical streams to one that receives and stretches a single graphical stream from a specific virtual display device in full screen. This method directly presents the complete display output of the target user space environment as the sole image source.

[0096] The effect of the switch is that the user will no longer see a blended interface of the two environments on the screen, but will instead see the native desktop or application interface of the target user space environment displayed in full screen. This provides the user with the complete visual space needed for focused operation in that environment. The entire process is handled in the background by the graphical interface fusion service, presenting a smooth visual transition effect, such as fade-in / fade-out or panning animations. This full-screen switching mechanism is a key interactive step in realizing the transition from overview mode to the specific operating environment, enabling the dual-system coexistence architecture to be presented to the user in an intuitive and easy-to-use way.

[0097] Step S7300: Send an environment switching request to the preloaded environment coordination service, specifying the target application corresponding to the interface element, so that the environment coordination service switches to the target user space environment for the target application. After the graphical interface fusion service identifies that the user's interaction is acting on an application interface element representing a complete user space environment desktop, and has switched the graphical user interface to full-screen display of the target user space environment, a background environment switching process needs to be initiated to ensure that the target application the user intends to launch can run in the correct environment. At this time, the graphical interface fusion service sends an environment switching request to the pre-loaded environment coordination service.

[0098] An environment switching request can be a structured message that instructs the environment coordination service to prepare for launching a specific target application and switch the system runtime context to the target user space environment required by that application. The request must explicitly specify the target application corresponding to the interacting interface element. In one embodiment, the graphical interface fusion service binds each icon or shortcut to a specific application identifier when rendering desktop interface elements. When a user clicks an icon, the service not only knows that the user has clicked on an area representing a second user space environment, but also precisely knows which specific application the user intends to launch, such as an application named terminal-emulator. Therefore, the request message sent to the environment coordination service will contain this application identifier.

[0099] The graphical interface fusion service needs to send environment switching requests through a pre-established inter-process communication channel with the environment coordination service. In one embodiment, the graphical interface fusion service acts as a local socket client, connecting to the Unix domain socket listened to by the environment coordination service, and serializing and sending a request message containing the target application identifier. In another embodiment, a higher-level IPC mechanism provided by the system can be used, such as sending an Intent to the environment coordination service via Binder. The Action field of this Intent indicates that it is an environment switching request, and its data field carries the package name or path of the target application.

[0100] Upon receiving this request, the environment coordination service triggers its internal scheduling logic. Based on the attributes of the target application specified in the request, it determines the target user-space environment required for the application to run and instructs the application loader to load and execute the target application within that environment. This series of operations ensures that when the user sees the application launch in a full-screen target environment interface, the program is indeed running in the correct, dedicated user-space environment, able to access the correct files and libraries, thus guaranteeing normal functionality and system stability.

[0101] Step S7400: When the interactive operation is applied to a specific control area of ​​the graphical user interface, the graphical user interface is switched from full-screen display to displaying graphical interface output data of each user space environment simultaneously.

[0102] When the graphical interface fusion service receives a user interaction that is not applied to a specific application interface element, but rather to a specific control area of ​​the graphical user interface, it indicates that the user's intention is not to launch an application, but rather to exit the current full-screen display mode and return to an overview interface where multiple user-space environments can be observed and manipulated simultaneously. In this case, the graphical interface fusion service performs an operation to switch the graphical user interface from full-screen display to simultaneously displaying the graphical interface output data of each user-space environment.

[0103] The specific control area is a predefined screen region used to receive system-level commands by the graphical interface fusion service. In one embodiment, this area can be a always-visible virtual navigation bar or status bar, displayed at the edge of the screen regardless of the current display mode. In another embodiment, this area can also be a hidden control panel that can only be activated by a specific gesture, such as swiping inward from the screen edge. When the user's touch, click, or other interactive events are captured by the graphical interface fusion service and, after coordinate parsing, it is determined that the landing point is within the specific control area, the corresponding mode switching logic is triggered.

[0104] In response to this interaction, the graphical interface blending service performs a display mode reversal. It restores the current compositing and display mode from a state where only a single user-space environment is displayed in full-screen mode to a blended view that simultaneously displays graphical interface output data from both the first and second user-space environments. In one embodiment, the service may internally reactivate non-target layers that were hidden or disabled when entering full-screen mode and adjust the size and position of all layers to rearrange them in the compositing scene graph according to a preset layout strategy, such as split-screen or picture-in-picture mode. The compositing engine then generates output frames based on this scene graph containing multiple visible layers. In another embodiment, the switching operation may involve reconfiguring the underlying display controller, for example, switching from receiving only a single graphics stream back to receiving and blending multiple graphics streams.

[0105] After the switch is complete, the user will see the merged graphical user interface on the screen again, which simultaneously contains the desktop content or application windows of both user-space environments. This mode switching mechanism provides users with the flexibility to quickly switch between different tasks and environments, allowing them to return to the overview and launch applications in another environment without closing the current full-screen application, greatly improving the efficiency and convenience of multitasking.

[0106] Building upon the underlying coexistence of dual systems, the above embodiments further construct an intuitive, flexible, and intelligent user interface interaction paradigm. This allows users to naturally perceive and operate two system environments simultaneously within a single view through a unified graphical interface. Users can also seamlessly switch between a focused single-environment full-screen mode and a global multi-environment overview mode via simple clicks or gestures, depending on task requirements. This not only perfectly solves the user experience interruption problem caused by interface fragmentation and cumbersome switching in traditional dual-system solutions, but also transforms the technical capability of dual-system coexistence into operational convenience that users can directly perceive and efficiently utilize. This significantly enhances the system's practicality and user-friendliness at the interaction level, representing a crucial leap from technical feasibility to superior user experience.

[0107] Please see Figure 2 This application provides an embedded intelligent device system startup apparatus, which is a functional embodiment of the embedded intelligent device system startup method of this application. The apparatus includes a startup loading module 3100, an initial configuration module 3200, a link mapping module 3300, and a startup support module 3400. The startup loading module 3100 is configured to load and run a pre-configured first operating system kernel in response to a system startup signal to drive the hardware resources of the embedded intelligent device. The initial configuration module 3200 is configured to create independent file system resources for a second operating system within a first user space environment created by the system kernel startup initialization process. The second operating system is heterogeneous with the first operating system. The link mapping module 3300 is configured to map the runtime resource access paths of the file system resources to the global file paths of the first user space environment by creating symbolic links, thus constructing a second user space environment corresponding to the second operating system. The startup support module 3400 is configured to terminate the initialization process, thereby providing support for applications in both the first and second user space environments based on the system kernel's shared access capabilities to the hardware resources.

[0108] Based on any embodiment of the device in this application, the initial configuration module 3200 includes: a startup mounting module, configured to have the system kernel initiate an initialization process according to an initialization configuration file, creating and mounting a temporary file system in memory to provide temporary file storage for the operation of the second operating system; a target creation module, configured to create a directory structure for storing the root file system of the second operating system within the user data partition of the embedded intelligent device; and a file deployment module, configured to deploy the complete root file system containing the binary executable files, library files, and configuration files of the second operating system as an independent file system resource to the directory structure.

[0109] Based on any embodiment of the device in this application, the link mapping module 3300 includes: a link creation module, configured to create a symbolic link pointing to a corresponding directory in the root file system of the second operating system under the root path of the first user space environment; and a path definition module, configured to define an application running search path for the second operating system based on the created symbolic link, wherein the search path includes the directory mapped through the symbolic link.

[0110] Based on any embodiment of the device in this application, prior to the startup support module 3400, the device further includes: a configuration generation module, configured to generate system configuration files necessary for the operation of the second operating system; and a configuration integration module, configured to integrate the system configuration files into a globally configured path already constructed in the second user space environment through a file system linking or mounting mechanism, wherein the system configuration files include network domain name resolution configuration files and / or user account configuration files.

[0111] Based on any embodiment of the device in this application, prior to the support startup module 3400, this device further includes: a coordination loading module, configured to load and run an environment coordination service for arbitrating resources and scheduling applications; a request receiving module, configured to listen for environment switching requests triggered by enabling a target application through the environment coordination service; and a response switching module, configured to, in response to the environment switching request, have the environment coordination service determine the target user space environment required by the target application based on its attributes, and instruct the application loader to load and execute the target application in the target user space environment.

[0112] Based on any embodiment of the device in this application, prior to the support startup module 3400, this device further includes: a fusion loading module, configured to load and run a graphical interface fusion service; a graphical receiving module, configured to receive graphical interface output data from the first user space environment and the second user space environment through the graphical interface fusion service; and a merged display module, configured to merge the graphical interface output data and display it in the same graphical user interface.

[0113] Based on any embodiment of the device in this application, the merged display module further includes: an interaction receiving module, configured to receive user interaction operations on the graphical user interface through the graphical interface fusion service; a full-screen display module, configured to switch the graphical user interface to full-screen display of the graphical interface output data of the target user space environment when the interaction operation acts on an application interface element representing a complete user space environment desktop; a switching trigger module, configured to send an environment switching request specifying the target application corresponding to the interface element to a pre-loaded environment coordination service, so that the environment coordination service switches to the target user space environment corresponding to the target application; and a simultaneous display switching module, configured to switch the graphical user interface from full-screen display to simultaneous display of the graphical interface output data of each user space environment when the interaction operation acts on a specific control area of ​​the graphical user interface.

[0114] To address the aforementioned technical problems, embodiments of this application also provide a computer device, which may be an embedded intelligent device. For example... Figure 3 The diagram shows the internal structure of a computer device. This computer device includes a processor, a computer-readable storage medium, a memory, a network interface, and various communication components connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, they enable the processor to implement an embedded intelligent device system startup method. The processor of this computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of this computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the embedded intelligent device system startup method of this application. The network interface of this computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0115] In this embodiment, the processor is used to execute... Figure 2 The system contains the specific functions of each module and its submodules. The memory stores the program code and various data required to execute these modules or submodules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / submodules in the embedded intelligent device system startup device of this application. The server can call the server's program code and data to execute the functions of all submodules.

[0116] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the embedded intelligent device system startup method of any embodiment of this application.

[0117] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0118] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0119] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for starting an embedded intelligent device system, characterized in that, include: In response to the system startup signal, the system kernel of the pre-configured first operating system is loaded and run to drive the hardware resources of the embedded intelligent device; Within the first user space environment created by the system kernel's initialization process, an independent file system resource is created for the second operating system, which is heterogeneous with the first operating system. By creating symbolic links, the access paths of the runtime resources of the file system resources are mapped to the global file paths of the first user space environment, thereby constructing a second user space environment corresponding to the second operating system. The initialization process is terminated, thereby providing support for applications in the first user space environment and the second user space environment based on the system kernel's ability to share access to the hardware resources.

2. The embedded intelligent device system startup method according to claim 1, characterized in that, Within the first user space environment created by the system kernel, independent file system resources are created for the second operating system, including: The system kernel initiates the initialization process according to the initialization configuration file, creating and mounting a temporary file system in memory to provide temporary file storage for the operation of the second operating system; Create a directory structure within the user data partition of the embedded smart device to store the root file system of the second operating system; The complete root file system, which contains the binary executable files, library files, and configuration files of the second operating system, is deployed as a separate file system resource to the directory structure.

3. The embedded intelligent device system startup method according to claim 1, characterized in that, By creating symbolic links, the access paths of the runtime resources of the file system resources are mapped to the global file paths of the first user space environment, thereby constructing a second user space environment corresponding to the second operating system, including: Under the root path of the first user space environment, create a symbolic link pointing to the corresponding directory in the root file system of the second operating system; Based on the created symbolic links, an application search path is defined for the second operating system, wherein the search path contains directories mapped through the symbolic links.

4. The embedded intelligent device system startup method according to claim 1, characterized in that, Before ending the initialization process, the following steps are included: Generate the system configuration files necessary for the second operating system to run; The system configuration file is integrated into the global configuration path already constructed in the second user space environment through a file system linking or mounting mechanism. The system configuration file includes a network domain name resolution configuration file and / or a user account configuration file.

5. The embedded intelligent device system startup method according to any one of claims 1 to 4, characterized in that, After the initialization process is completed, the following is included: Load and run the environment coordination service for arbitration resource and scheduling applications; The environment coordination service listens for environment switching requests triggered by enabling the target application. In response to the environment switching request, the environment coordination service determines the target user space environment required by the target application based on its attributes, and instructs the application loader to load and execute the target application in the target user space environment.

6. The embedded intelligent device system startup method according to any one of claims 1 to 4, characterized in that, After the initialization process is completed, the following is included: Load and run the graphical interface integration service; The graphical interface fusion service receives graphical interface output data from the first user space environment and the second user space environment. The data output from the graphical interface is combined and displayed in the same graphical user interface.

7. The embedded intelligent device system startup method according to claim 6, characterized in that, After merging the graphical interface output data and displaying it in the same graphical user interface, the following steps are included: The graphical interface fusion service receives user interaction operations on the graphical user interface. When the interactive operation is applied to an application interface element representing a complete user space environment desktop, the graphical user interface is switched to full-screen display of the graphical interface output data of the target user space environment. Send an environment switching request to the preloaded environment coordination service, specifying the target application corresponding to the interface element, so that the environment coordination service switches to the target user space environment for the target application. When the interactive operation is applied to a specific control area of ​​the graphical user interface, the graphical user interface is switched from full-screen display to displaying graphical interface output data of each user space environment simultaneously.

8. A startup device for an embedded intelligent device system, characterized in that, include: The startup loading module is configured to respond to the system startup signal and load the system kernel of the pre-configured first operating system to drive the hardware resources of the embedded intelligent device. The initial configuration module is configured to create independent file system resources for the second operating system within the first user space environment created by the system kernel's startup initialization process, wherein the second operating system is heterogeneous with the first operating system; The link mapping module is configured to map the access path of the runtime resources of the file system resources to the global file path of the first user space environment by creating symbolic links, thereby constructing a second user space environment corresponding to the second operating system. The system supports a startup module that is configured to terminate the initialization process, thereby providing support for applications in the first user space environment and the second user space environment based on the system kernel's ability to share access to the hardware resources.

9. A computer device comprising a controller, the controller including a processor and a memory, characterized in that, The processor invokes and runs a computer program in the memory to perform the steps of the embedded intelligent device system startup method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, performs the steps included in the corresponding method.

Images