Partition management method and device, electronic equipment and computer readable storage medium

Abstract

The embodiment of the invention discloses a partition management method and device, electronic equipment and a computer readable storage medium, and relates to the technical field of computers. The method comprises the following steps: creating a customized partition; modifying a compiling rule corresponding to a system-on-chip (SoC) module to decouple the SoC module from a native partition of a system, compiling the SoC module and integrating the SoC module to the customized partition; modifying a partition mounting configuration file of the system, and configuring mounting information of the customized partition; and mounting the SoC module in the customized partition to the native partition according to configured mounting information on the basis of a dynamic mounting technology of an OverlayFS (Overlay File System). Therefore, according to the scheme, decoupling of the SoC module and the native partition can be realized.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a partition management method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] During system development, system-on-chip (SoC) modules are typically deployed in native partitions of the system, such as system or system_ext. If SoC modules and systems are developed in parallel, frequent code merging and conflict handling are required, which significantly impacts development progress and efficiency.

[0003] In related technologies, some SoC modules have been moved to the vendor partition, achieving decoupling of these SoC modules. However, many SoC modules still have a strong coupling relationship with the native partition and cannot be completely decoupled to the vendor partition. Therefore, the problem of frequent code merging and conflict handling still exists. Summary of the Invention

[0004] This application provides a partition management method, apparatus, electronic device, and computer-readable storage medium that can decouple the SoC module and the native partition.

[0005] In a first aspect, embodiments of this application provide a partition management method, including: Create custom partitions; Modify the compilation rules corresponding to the system-on-a-chip (SoC) module to decouple the SoC module from the system's native partition and compile and integrate the SoC module into the customized partition; Modify the partition mount configuration file of the system to configure the mount information of the customized partition; Based on the OverlayFS stacked file system dynamic mounting technology, the SoC module in the customized partition is mounted to the native partition according to the configured mounting information.

[0006] In one embodiment, modifying the compilation rules corresponding to the system-on-a-chip (SoC) module includes: Locate the Soong configuration file related to the compilation and integration of the SoC module from the Soong compilation rules; By modifying the Soong configuration file, the output path of the compiled SoC module is changed from the native partition to the customized partition; Locate the configuration file corresponding to the SoC module from the Makefile compilation rules, and add the compilation rules for the SoC module to the configuration file; Based on the output path of the compiled SoC module and the compilation rules of the SoC module, the SoC module is compiled and integrated into the customized partition.

[0007] In one embodiment, modifying the system's partition mount configuration file to configure the mount information of the customized partition includes: Add the mount information of the customized partition to the partition mount configuration file of the system; Add a mount entry for the customized partition; Add an OverlayFS rule to specify that the SoC modules in the customized partition will be overlaid and mounted. The source directory in the OverlayFS is determined as the directory of the SoC module in the customized partition, and the target directory is determined.

[0008] In one embodiment, the customized partition includes multiple sub-partitions; the number of SoC modules is multiple; the number of native partitions is multiple. The process of compiling and integrating the SoC module into the customized partition includes: According to the respective functions of the multiple SoC modules, the multiple SoC modules are compiled and integrated into the sub-partitions corresponding to the functions of the SoC modules; The step of mounting the SoC module in the customized partition to the native partition according to the configured mounting information includes: According to the configured mounting information, the SoC modules in each of the sub-partitions are mounted to the native partitions corresponding to the sub-partitions.

[0009] In one embodiment, after mounting the SoC modules in each of the sub-partitions to the corresponding native partitions of the sub-partitions, the method further includes: Obtain the directory of the sub-partition; Obtain the directory of the native partition corresponding to the sub-partition; The directory of the sub-partition is used to overwrite or supplement the directory of the native partition corresponding to the sub-partition.

[0010] In one embodiment, after mounting the SoC module in the customized partition to the native partition according to the configured mounting information, the method further includes: Monitor the operating status of the SoC module; When the SoC module is not running, it is supported to unload the SoC module in the customized partition from the native partition.

[0011] In one embodiment, the method further includes: If the customized partition fails to mount or there is a path conflict, a rollback operation is performed from the native partition. The state of the SoC module is restored to the state coupled to the native partition.

[0012] In one embodiment, after compiling and integrating the SoC module into the customized partition, the method further includes: Package the image of the customized partition.

[0013] Secondly, embodiments of this application provide a partition management device, including: Create a module for creating custom partitions; The modification module is used to modify the compilation rules corresponding to the system-on-a-chip (SoC) module, so as to decouple the SoC module from the native partition of the system and compile and integrate the SoC module into the customized partition; The configuration module is used to modify the partition mount configuration file of the system and configure the mount information of the customized partition. The mounting module is used to mount the SoC module in the customized partition to the native partition according to the configured mounting information based on the OverlayFS dynamic mounting technology of the stacked file system.

[0014] Thirdly, embodiments of this application also provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the partition management method described above.

[0015] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the partition management method described above.

[0016] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described in embodiments of this application.

[0017] The embodiments of this application have the following beneficial effects: By creating custom partitions and modifying the compilation rules of SoC modules, SoC modules can be decoupled from the system's native partitions and compiled and integrated into the custom partitions. By modifying the system's partition mount configuration file and configuring the mount information of the custom partitions, the SoC modules in the custom partitions are mounted to the native partitions according to the configured mount information using the OverlayFS dynamic mounting technology. This allows for maintaining functional synergy between the SoC modules and the native partitions through the mounting mechanism while simultaneously decoupling them, significantly reducing the frequency of code merging and conflict handling, lowering the collaboration costs of parallel development of the SoC modules and native partitions, and improving development efficiency. Furthermore, custom partitions support independent updates, so repairing or upgrading SoC modules does not require updating the entire native partition, reducing update package size and risk. Isolating SoC module resources through custom partitions avoids direct contamination of the native partitions, facilitating access control and resource allocation, and enhancing system stability. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the steps of a partition management method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture of a partition management method provided in an embodiment of this application; Figure 3 This is a schematic flowchart of a partition management method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the partition management device provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0021] To facilitate understanding, some terms will be explained first.

[0022] SoC (System-on-a-Chip) module: An integrated circuit that integrates all or most of the functions of a computer or other electronic system. An SoC module can be either a dedicated integrated circuit containing a complete system and all embedded software, or a technology used to implement the entire design process from defining system functions to software / hardware partitioning.

[0023] A partition is a logical division of a storage device (such as a hard drive or flash memory). Each partition can independently manage its file system and is used to isolate different types of data (such as system files and user data), improving storage efficiency and data security.

[0024] Native partitions: Physical or logical partitions created directly on the storage device, directly recognized and managed by the operating system, without relying on additional virtualization or mapping technologies. In this embodiment, native partitions may include system-native partitions such as the system partition, system_ext partition, and product partition.

[0025] Dynamic partitioning: A flexible storage solution based on partition mapping tables (GPT) that allows partitions to be resized without reformatting the entire device. Dynamic partition managers enable the dynamic creation, deletion, and resizing of partitions, improving the flexibility of storage management.

[0026] Mounting refers to the process by which the operating system associates a storage device (or partition) with a directory in the file system. After the association, users can access the data in the storage device (or partition) through that directory. The mount point is the access point of the storage device (or partition) in the file system. Unmounting is the process of releasing this association.

[0027] OverlayFS: Allows multiple directories (such as read-only lower directories and writable upper directories) to be merged into a unified view. Modifications to the upper directory will overwrite the lower directory, enabling temporary modifications to the underlying file system without affecting the original data.

[0028] Makefile: A script file used to specify the compilation process. A project contains countless source files, which are placed in several directories according to type, function, and module. Makefile defines a series of rules to specify which files need to be compiled first, which files need to be compiled later, which files need to be recompiled, and even perform more complex operations. Makefile can execute operating system commands.

[0029] Soong is a build system for Android that replaces the traditional Makefile. Soong build rules define module dependencies, build options, and output targets through Blueprint files, supporting parallel compilation and more flexible module configuration, thus improving the build efficiency of the Android system.

[0030] In embedded systems (such as smart devices), SoC modules typically contain core applications (apps), shared libraries (libs), and configuration files (etc). These modules are often stored in the system's native partitions (such as system and system_ext partitions). However, with SoC modules stored in native partitions, upgrades or customizations often require a complete re-flash of the native partition. Frequent adjustments to the functionality of multiple modules can lead to partition conflicts if storage paths are not separated. Users cannot dynamically load or unload modules, limiting system scalability. The partition management method proposed in this application can achieve file system decoupling, dynamic loading, and flexible management.

[0031] In one embodiment, such as Figure 1 As shown, a partition management method is provided. Although the logical order is illustrated in the step diagram, in some cases, the steps shown or described can be performed in a different order than that shown in the figures. These will be described in detail below. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0032] according to Figure 1 The partition management method shown includes at least steps S110 to S140, which are described in detail below: In step S110, a custom partition is created.

[0033] A custom partition can be a dynamic partition. A dynamic partition can be created in the system by configuring relevant settings. The name of this dynamic partition can be customized, for example, it could be named Chipoverlay.

[0034] Optionally, within the Android system, device and board configurations can be modified, and a dynamic partition list can be configured. This allows the system to create dynamic partitions based on these configurations when building the Android system image. Specifically, modifying the device configuration can include enabling a flag for dynamic partitions in device.mk; modifying the board configuration can include setting the size of the dynamic partitions in BoardConfig.mk; and configuring the dynamic partition list can include adding the names of the created dynamic partitions to the list. In this way, dynamic partitions can be created as customized partitions.

[0035] In step S120, the compilation rules corresponding to the system-on-a-chip (SoC) module are modified to decouple the SoC module from the system's native partition and compile and integrate the SoC module into the customized partition.

[0036] In related technologies, the drivers, firmware, or dedicated services of SoC modules are compiled by default along with the system's native partition (such as the system's native system partition), resulting in a high degree of coupling between the SoC module and the system's native partition.

[0037] In this embodiment of the application, modifying the compilation rules corresponding to the SoC module can change the compilation path and dependencies of the SoC module from the native partition to the custom partition. This can decouple the SoC module from the native partition of the system and compile and integrate the SoC module into the custom partition.

[0038] In step S130, the partition mount configuration file of the system is modified to configure the mount information of the customized partition.

[0039] In step S140, based on the OverlayFS dynamic mounting technology, the SoC module in the customized partition is mounted to the native partition according to the configured mounting information.

[0040] Although custom partitioning can decouple the SoC module from the native partition, the core dependencies between the SoC module and the native partition cannot be completely severed. For example, the core module of the SoC needs to rely on the boot process of the native partition. Therefore, the SoC module can be mounted to the native partition to maintain the functional linkage between the SoC module and the native partition.

[0041] The system's partition mount configuration file can be modified to configure the mount information of the customized partition, set the mount point, and then, based on OverlayFS dynamic mounting technology, mount the SoC modules in the customized partition to the native partition according to the configured mount information. Based on OverlayFS, multiple directories can be merged into a unified view while maintaining the independence of each layer. This achieves both the union of the SoC modules in the customized partition and the native partition, and ensures the isolation between the SoC modules in the customized partition and the native partition.

[0042] By adopting the technical solution of this application embodiment, and through creating a customized partition and modifying the compilation rules of the SoC module, the SoC module can be decoupled from the system's native partition and compiled and integrated into the customized partition. By modifying the system's partition mount configuration file and configuring the mount information of the customized partition, the SoC module in the customized partition is mounted to the native partition according to the configured mount information based on the OverlayFS dynamic mounting technology. In this way, while maintaining the functional linkage between the SoC module and the native partition through the mounting mechanism, the decoupling of the SoC module and the native partition is achieved, significantly reducing the frequency of code merging and conflict handling, lowering the collaborative cost of parallel development of the SoC module and the native partition, and improving development efficiency. Furthermore, the customized partition supports independent updates, so the repair or upgrade of the SoC module does not require updating the entire native partition, reducing the update package size and lowering update risks. Isolating the resources of the SoC module through the customized partition avoids direct pollution of the native partition, facilitating access control and resource allocation, and enhancing system stability.

[0043] Figure 2 This is a schematic diagram of the architecture of a partition management method provided in an embodiment of this application. Based on the above technical solution, as an embodiment, refer to... Figure 2 The customized partition includes multiple sub-partitions; the number of SoC modules is multiple; the number of native partitions is multiple. Compiling and integrating the SoC modules into the customized partition may include: compiling and integrating the multiple SoC modules into the sub-partitions corresponding to the functions of the SoC modules, according to their respective functions. Mounting the SoC modules in the customized partition to the native partitions according to the configured mount information may include: mounting the SoC modules in each sub-partition to the corresponding native partition according to the configured mount information.

[0044] When creating a custom partition, it can be divided into multiple subpartitions. The Blueprint file can define which native partition each subpartition should be mounted to. Blueprint is a build description language and parsing tool that provides syntax definitions for build rules (such as module types, dependencies, compilation parameters, etc.) and basic parsing capabilities. Blueprint files are configured to define module rules, including module types, storage paths, and partition mappings.

[0045] For example, subpartitions can include an app subpartition, a lib subpartition, and an etc subpartition. The app subpartition can primarily store application-related content, the lib subpartition can primarily store library-related content, and the etc subpartition can primarily store configuration file-related content. In other embodiments, other subpartitions or different names may also be available. The app subpartition can be defined to be mounted to the system's native system_ext partition or product partition; the lib subpartition can be defined to be mounted to the system's native system partition; and the etc subpartition can be defined to be mounted to the system's native product partition.

[0046] Multiple sub-partitions can be defined to store different content types. When compiling and integrating multiple SoC modules into a custom partition, the specific partition into which each SoC module should be compiled and integrated can be determined based on its individual function. Thus, when compiling each SoC module, the compiled code and other data can be stored in the sub-partition corresponding to the function of that SoC module.

[0047] When mounting a SoC module from a custom partition to a native partition, it essentially means mounting the directory of the subpartition containing the SoC module to the directory of the corresponding native partition, according to the configuration in the Blueprint file.

[0048] By adopting the technical solution of this application embodiment, SoC modules with different functions are split into different sub-partitions, and their compilation, updates and maintenance do not interfere with each other. By mounting SoC modules to the corresponding native partitions according to their functions, the division of responsibilities of the native partitions can be better matched, ensuring that the dependencies between modules and system framework and hardware services are clear and reducing the complexity of cross-partition calls.

[0049] Based on the above technical solution, as an embodiment, after mounting the SoC modules in each of the sub-partitions to the native partitions corresponding to the sub-partitions, the method may further include: obtaining the directory of the sub-partition; obtaining the directory of the native partition corresponding to the sub-partition; and using the directory of the sub-partition to overwrite or supplement the directory of the native partition corresponding to the sub-partition.

[0050] In the OverlayFS rule, the directory of the sub-partition where the SoC module is located in the customized partition is set as the source directory, and the directory of the native partition corresponding to the sub-partition is set as the base directory. The system can merge these two directories through OverlayFS to form the target directory, so that the content of the sub-partition of the customized partition and the content of the native partition form a unified view, and the sub-partition of the customized partition can overwrite or supplement the content of the native partition.

[0051] OverlayFS's merge layer is a unified view formed by combining and mounting multiple underlying directories. The system accesses the integrated file system through the merge layer. For example... Figure 2 As shown, the merge layer appears as a single directory externally, and internally it automatically handles the overwrite relationship of files in different layers, such as... Figure 2 In the lowerdir1 layer, which has a higher priority, files with the same name in the lowerdir2 layer will be obscured. The merge layer does not actually store files; it only dynamically merges the contents of each layer, thus maintaining the independence of the lower layers while enabling transparent access to the upper layers.

[0052] The technical solution of this application embodiment can merge multiple independent directories into a unified view, allowing the system to directly access the integrated content without having to pay attention to the underlying structure, thus simplifying the complexity of using the file system.

[0053] Figure 3 This is a schematic flowchart of a partition management method provided in one embodiment of this application. Based on the above technical solution, as an embodiment, refer to... Figure 3 The modification of the compilation rules corresponding to the System-on-a-Chip (SoC) module may include: locating the Soong configuration file related to the compilation and integration of the SoC module from the Soong compilation rules; adjusting the output path of the compiled SoC module from the native partition to the customized partition by modifying the Soong configuration file; locating the configuration file corresponding to the SoC module from the Makefile compilation rules and adding the compilation rules of the SoC module to the configuration file; and compiling and integrating the SoC module into the customized partition based on the output path of the compiled SoC module and the compilation rules of the SoC module.

[0054] Soong is a concrete implementation based on Blueprint. It's a build system developed on top of Blueprint, leveraging Blueprint's syntax and parsing capabilities to implement specific compilation logic for Android's unique needs (such as multi-architecture support, module dependency management, and Android-specific module types). Android build Soong configuration files (such as .bp files) follow Blueprint syntax, which Blueprint parses into abstract build rules. Soong then combines these rules with Android's build logic to generate specific compilation commands, ultimately completing the source code compilation.

[0055] The type of SoC module (such as driver, service, library, etc.) can be determined. The corresponding Soong configuration file can be found in the device configuration directory of the Android source code or the code directory provided by the SoC manufacturer. The Soong configuration file contains the SoC module's compilation type, dependencies, and output settings. Soong configuration files related to the compilation and integration of the SoC module can be filtered by the SoC module's name or functional keywords.

[0056] In the Soong configuration file corresponding to the SoC module, locate the configuration item that controls the output path (such as the parameter that specifies the module installation directory), change the SoC module from the path corresponding to the native partition (such as / system / lib) to the target path of the custom partition (such as / Chipoverlay / lib), and ensure that the installation rules of the SoC module are adapted to the new path so that the compilation system can correctly identify the output location.

[0057] Locate the Makefile compilation rules related to the SoC module in the SoC module source code directory or device configuration directory. Locate the configuration file corresponding to the SoC module from the Makefile compilation rules, and add the SoC module compilation rules to the configuration file. Specify the module's compilation dependencies, the processing method of generated files (such as copying or packaging), and the association with custom partition construction (such as specifying which subpartition the SoC module output should be included in).

[0058] Ensure that the modified output path in the Soong configuration matches the custom partition build rules defined in the Makefile to guarantee that the compiled SoC module files will be integrated into the custom partition's directory. By building the system's dependency chain (e.g., referencing Soong's output variables in the Makefile), the SoC modules will be automatically integrated into the custom partition after compilation.

[0059] By adopting the technical solution of this application embodiment, the path conflict or dependency break can be avoided through the configuration collaboration of Soong and Makefile, ensuring that the integrated customized partition can be correctly recognized and loaded by the system. This decouples the compilation output of the SoC module from the native partition and isolates the customized partition from the native partition, preventing abnormalities of the SoC module from affecting the system's native partition.

[0060] Based on the above technical solution, as an example, refer to Figure 3 After compiling and integrating the SoC module into the custom partition, the method may further include: packaging an image of the custom partition.

[0061] After compiling and integrating the SoC module into the custom partition, the custom partition can be created as an image. The image file can serve as a "standard template" for the custom partition, allowing for quick replication of the same partition configuration across multiple devices of the same model. For example, in mass production, there is no need to compile and integrate the SoC module on each device individually; the deployment of the custom partition can be completed directly by flashing the image, ensuring that the partition content of all devices is consistent and reducing human error.

[0062] An image file is a complete snapshot of a partition and can be used as a long-term backup. When a customized partition suffers from file corruption, configuration errors, or other problems, there is no need to recompile or manually repair it; simply restoring the image will restore the partition to its normal state, significantly reducing system failure recovery time.

[0063] As an independent file, the image can be stored separately from the partition data during system runtime, avoiding accidental modification of partition content. Furthermore, an unflashed image will not affect the current system operation, facilitating the verification of new configurations in a test environment before batch application to the production environment.

[0064] Based on the above technical solution, as an example, refer to Figure 3 The modification of the system's partition mount configuration file to configure the mount information of the customized partition may include: adding the mount information of the customized partition to the system's partition mount configuration file; adding a mount entry for the customized partition; adding an OverlayFS rule to specify that the SoC module in the customized partition is mounted overlay; determining the source directory in the OverlayFS as the directory of the SoC module in the customized partition, and determining the target directory.

[0065] Partition mount configuration files are usually associated with startup scripts or partition tables. Based on these, the partition mount configuration file responsible for mounting partitions in the system can be determined. The partition mount configuration file records the basic information of each partition, including the partition's device path (such as the partition identifier of the corresponding disk), file system type, mount point (the partition's own mount directory), and mount parameters (such as read and write permissions, whether to mount automatically, etc.), to ensure that the system can recognize and mount the partition when it starts up.

[0066] In the partition mount configuration file, add a mount entry for the custom partition, specifying the device path, target mount point, file system type, and mount options (such as default permissions and error handling) for the custom partition. This ensures that the custom partition is automatically mounted to the specified directory during the system startup process, providing a foundation for subsequent overlay operations.

[0067] The system locates the OverlayFS configuration file (which may be a startup script or a dedicated file system configuration file). A new OverlayFS rule is added to this file, clearly defining the overlay hierarchy: the directory containing the SoC module in the custom partition is set as the source directory, the corresponding target directory in the native partition is set as the base directory, and a merged target directory is specified as the directory actually accessed by the system. The OverlayFS rule precisely maps the paths: the directory of the sub-partition containing the SoC module within the custom partition is set as the source directory, and the directory of the native partition corresponding to that SoC module is set as the base directory. The system merges these two directories using OverlayFS to form the target directory, creating a unified view of the module content of the custom partition and the base content of the native partition in the target directory. Furthermore, the custom content can overwrite or supplement the native content.

[0068] The technical solution adopted in this application's embodiments enables the overlay of customized partitions and native partitions by configuring mount information and OverlayFS rules. This allows the system to access the regular paths of the native partitions, enabling the use of SoC modules without modifying application code or the system framework, thus ensuring compatibility and consistency of function calls. The native partition is a read-only layer, and the customized partition is overlaid on top of it. This avoids directly modifying the original files of the native partition. Even if the customized partition encounters problems, simply removing or disabling the OverlayFS rules will restore the system to its native state, preventing the native system from becoming unusable due to corruption of customized content. Furthermore, multiple customized partitions can be configured for different scenarios. By switching the source directory of OverlayFS, users can quickly switch between different versions of customized partitions without redeploying the entire system, improving the flexibility of scenario adaptation.

[0069] Based on the above technical solution, as an embodiment, after mounting the SoC module in the customized partition to the native partition according to the configured mounting information, the method may further include: monitoring the running status of the SoC module; and when the SoC module is in a non-running state, supporting the unloading of the SoC module in the customized partition from the native partition.

[0070] The SoC module in the customized partition is mounted to the native partition based on the OverlayFS dynamic mounting technology. The system records this mounting relationship, so the system can track the running status of the SoC module, such as whether it is called by the process and its resource usage, thereby realizing real-time monitoring of the running status of the SoC module.

[0071] When the SoC module is detected to be in a non-running state, the OverlayFS mount relationship can be removed, thereby unloading the SoC module of the customized partition from the native partition.

[0072] The technical solution adopted in this application supports the unloading of mounted SoC modules, which can release system resources, avoid abnormalities caused by long-term mounting of non-running SoC modules, and enhance system stability. This unloading operation does not require a system restart; SoC modules can be temporarily unloaded as needed, and the SoC can be remounted to restore functionality, providing a flexible means for dynamic functional adjustments and simplifying management processes.

[0073] Based on the above technical solution, as an example, when the customized partition fails to mount or there is a path conflict, a rollback operation is performed from the native partition; the state of the SoC module is restored to the state coupled to the native partition.

[0074] Custom partition mounting may fail if the custom partition is corrupted or the mount information is misconfigured. File name conflicts may occur when files in the custom and native partitions have the same name and cannot be reconciled via OverlayFS. In case of custom partition mounting failure or path conflicts, a rollback operation can be performed. This automatically disables the custom partition's mount logic and rolls back from the native partition, restoring the SoC module's operating state to its original state coupled with the native partition. This ensures uninterrupted hardware functionality and prevents complete SoC-related function failure due to custom configuration issues.

[0075] By employing the technical solution of this application embodiment, when a customized partition fails to mount or there is a path conflict, the rollback operation ensures that the core hardware functions are not interrupted, preventing the device from becoming completely unusable due to customization issues. This provides a fallback for customized partition solutions; even if the customized configuration has defects (such as path design conflicts or partition corruption), the system can automatically switch to a verified native state, reducing the risk of system crashes caused by customization operations. Furthermore, the rollback operation allows for state recovery without manual intervention, reducing debugging costs and downtime caused by mounting problems.

[0076] like Figure 2As shown, compile-time hook modules can define the location, storage structure, and mount path of SoC modules through rule definitions, providing basic support for runtime dynamic operations. SoC modules are assigned to independent partitions (including system, system_ext, and product partitions) to avoid direct binding between modules and system functions. The system partition includes core applications (such as system services and operating system drivers); the system_ext partition includes modules related to extended functions to enhance existing functionality; and the product partition includes device or product-specific configuration information.

[0077] The Blueprint file (Android.bp) defines module rules, including module type, storage path, and partition mapping. Each module is assigned to a corresponding partition based on its functional characteristics. For example, the app module is mounted to the system_ext or product partition; the lib module is mounted to the system partition; and configuration files are managed by the product partition. The ChipOverlay.mk file can specifically list the mapping rules between SoC modules and sub-partitions. For example, software modules are mounted to the system_ext / lib folder; and configuration files are mounted to the product / etc folder.

[0078] `base_rules.mk` defines the basic module rules to ensure correct partition mapping during compilation of each module. `ChipOverlay.mk` provides customized compilation rules for the SoC chip platform, specifying the module mounting location. The compilation tool uses the Soong system to divide modules and mounting paths according to the rules, providing support for dynamic loading at runtime.

[0079] The runtime Overlay module can utilize OverlayFS technology to dynamically mount modules, presenting a unified partition structure (logical view) and supporting flexible module management. The final content seen by the user through the file system is the overlay result of all modules (logical file view), without the user needing to be aware of the independent storage paths of individual modules. The lowdir1 layer mounts from ChipOverlay to the target file system path, for example, mounting a module from the system_ext partition to the system_ext / lib folder, presenting it as a partial system function module. The layer containing customized partitions supports dynamic loading and unloading at runtime, facilitating module expansion. The lowdir2 layer is the original module storage path under the partition, not participating in the runtime mounting logic, serving as a backup source for partition data. The lowdir2 layer can preserve the independence of partition content, supporting failure rollback or partition unloading operations.

[0080] The file management module is responsible for scheduling dynamic mount operations and provides functions such as module backup and recovery, path conflict resolution, real-time detection, and unmounting. Module backup and recovery: When mount failure or path conflict occurs, it automatically rolls back or restores from the lowdir2 layer. Path conflict resolution: It supports a dynamic module path replacement mechanism to ensure file security when mounting multiple partitions. Real-time detection and unmounting: It monitors the module's running status and supports quick unmounting of modules to release resources when not running. The file management module can also integrate more functions, such as partition backup.

[0081] Compile-time modules can use blueprint files (Android.bp) to define module mounting rules, specifying module types and storage locations. The compiler generates partitioning results based on the baseline rules and records the module mappings in the ChipOverlay.mk file.

[0082] At runtime, OverlayFS can be used to dynamically mount modules from independent partitions to system logical partitions. The mounted content is integrated to form a unified logical view (merge layer), with apps, libraries, and configuration files as prominent modular representatives. The file management module monitors the mount status in real time and provides module backup and recovery support.

[0083] By employing the technical solution of this application embodiment, through partitioned storage and runtime dynamic mounting, the SoC module can be separated from the native partition, improving the flexibility of module management. Users can dynamically load or unload modules without re-flashing the partition. The file management module can ensure automatic recovery in case of path conflicts, enhancing the security of the file system.

[0084] In one embodiment, the partition management method includes: creating a customized partition (dynamic partition) named chipoverlay in the system; locating and modifying relevant Soong files, adding or adjusting module definitions; locating and modifying relevant Makefile files, updating compilation rules; compiling and integrating the SoC module into the chipoverlay partition; packaging the chipoverlay partition into an image; modifying fs_mgr to add mounting of the chipoverlay partition; and modifying fs_mgr to mount the SoC module to the system's target directory via overlayFS. By packaging the SoC module into a customized partition and mounting it using OverlayFS technology, the merging conflict problem in the parallel development process of SoC manufacturers and developers is solved, improving the system's development efficiency and module maintenance convenience; and decoupling the SoC module from the system module is achieved, facilitating independent development and upgrades.

[0085] The partition management method of this application embodiment can significantly optimize the partition management and module loading of embedded operating systems, and can also be extended to multiple application systems such as smart devices, Internet of Things (IoT), and cloud computing environment resource management.

[0086] To facilitate better implementation of the partition management method of this application, this application also provides a partition management device based on the above-described partition management method. The meanings of the terms used are the same as in the partition management method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0087] Please see Figure 4 , Figure 4 This is a schematic diagram of the partition management device provided in an embodiment of this application, wherein the partition management device includes: Create module 401 to create custom partitions; Modification module 402 is used to modify the compilation rules corresponding to the system-on-a-chip (SoC) module, so as to decouple the SoC module from the native partition of the system and compile and integrate the SoC module into the customized partition; Configuration module 403 is used to modify the partition mount configuration file of the system and configure the mount information of the customized partition; Mounting module 404 is used to mount the SoC module in the customized partition to the native partition according to the configured mounting information based on the OverlayFS dynamic mounting technology of the stacked file system.

[0088] In one embodiment, the modification module 402 includes: The first positioning unit is used to locate the Soong configuration file related to the compilation and integration of the SoC module from the Soong compilation rules; The path adjustment unit is used to adjust the output path of the compiled SoC module from the native partition to the customized partition by modifying the Soong configuration file; The second positioning unit is used to locate the configuration file corresponding to the SoC module from the Makefile compilation rules, and add the compilation rules of the SoC module to the configuration file; The compilation and integration unit is used to compile and integrate the SoC module into the customized partition based on the output path of the compiled SoC module and the compilation rules of the SoC module.

[0089] In one embodiment, the configuration module 403 includes: An information adding unit is used to add the mounting information of the customized partition to the partition mounting configuration file of the system. An entry adding unit is used to add mount entries for the customized partition; The rule adding unit is used to add OverlayFS rules to specify that the SoC module in the customized partition is overlaid and mounted to the target directory; The target determination unit is used to determine the target directory in the OverlayFS as the directory of the native partition, and to determine the source directory in the OverlayFS as the directory of the SoC module in the customized partition.

[0090] In one embodiment, the customized partition includes multiple sub-partitions; the number of SoC modules is multiple; the number of native partitions is multiple; the modification module 402 includes: A sub-partition unit is used to compile and integrate the multiple SoC modules into the sub-partition corresponding to the function of the SoC module according to their respective functions; The mounting module 404 includes: The mounting unit is used to mount the SoC modules in each of the sub-partitions to the native partitions corresponding to the sub-partitions according to the configured mounting information.

[0091] In one embodiment, the device further includes: The first directory acquisition module is used to acquire the directory of the sub-partition; The second directory acquisition module is used to acquire the directory of the native partition corresponding to the sub-partition; The overlay display module is used to overlay and display the directory of the sub-partition and the directory of the corresponding native partition.

[0092] In one embodiment, the device further includes: A status monitoring module is used to monitor the operating status of the SoC module; A support module is provided to support unloading the SoC module from the native partition from the customized partition when the SoC module is in a non-running state.

[0093] In one embodiment, the device further includes: The rollback module is used to perform a rollback operation from the native partition when the customized partition fails to mount or there is a path conflict. A recovery module is used to restore the state of the SoC module to the state coupled in the native partition.

[0094] In one embodiment, the device further includes: The packaging module is used to package the image of the customized partition.

[0095] By adopting the technical solution of this application embodiment, and through creating a customized partition and modifying the compilation rules of the SoC module, the SoC module can be decoupled from the system's native partition and compiled and integrated into the customized partition. By modifying the system's partition mount configuration file and configuring the mount information of the customized partition, the SoC module in the customized partition is mounted to the native partition according to the configured mount information based on the OverlayFS dynamic mounting technology. In this way, while maintaining the functional linkage between the SoC module and the native partition through the mounting mechanism, the decoupling of the SoC module and the native partition is achieved, significantly reducing the frequency of code merging and conflict handling, lowering the collaborative cost of parallel development of the SoC module and the native partition, and improving development efficiency. Furthermore, the customized partition supports independent updates, so the repair or upgrade of the SoC module does not require updating the entire native partition, reducing the update package size and lowering update risks. Isolating the resources of the SoC module through the customized partition avoids direct pollution of the native partition, facilitating access control and resource allocation, and enhancing system stability.

[0096] For specific limitations regarding the partition management device, please refer to the limitations on the partition management method above, which will not be repeated here. Each module in the aforementioned partition management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0097] In addition, this application also provides an electronic device, such as Figure 5 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically: The electronic device may include components such as a processor 501 with one or more processing cores and a memory 502 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 501 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 502, and by calling data stored in the memory 502, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 501 may include one or more processing cores; preferably, the processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 501.

[0098] The memory 502 can be used to store software programs and modules. The processor 501 executes various functional applications and data processing by running the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 502 may also include a memory controller to provide the processor 501 with access to the memory 502.

[0099] In one embodiment, the electronic device further includes a power supply 503 that supplies power to the various components. Preferably, the power supply 503 can be logically connected to the processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 503 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0100] In one embodiment, the electronic device may further include an input unit 504, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0101] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 501 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 502 according to the following instructions, and the processor 501 runs the applications stored in the memory 502, thereby implementing the steps in any of the partition management methods provided in the embodiments of this application.

[0102] Those skilled in the art will understand that Figure 5 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 electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0103] In one embodiment, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0104] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of this application.

[0105] In some embodiments, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

[0106] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0107] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0108] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the partition management methods provided in this application.

[0109] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0110] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0111] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the partition management methods provided in this application, the beneficial effects that any of the partition management methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0112] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0113] The foregoing has provided a detailed description of a partition management method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method of partition management, characterized by, The method comprises: creating a customized partition; modifying the compilation rules corresponding to the system-on-chip (SoC) modules to decouple the SoC modules from the native partitions of the system and compile and integrate the SoC modules into the customized partition; modifying the partition mounting configuration file of the system to configure the mounting information of the customized partition; mounting the SoC modules in the customized partition to the native partitions according to the configured mounting information based on the OverlayFS dynamic mounting technology.

2. The method of claim 1, wherein, The modification of the compilation rules corresponding to the system-on-chip (SoC) modules comprises: locating the Soong configuration file related to the compilation and integration of the SoC modules from the Soong compilation rules; adjusting the output path of the compiled SoC modules from the native partition to the customized partition by modifying the Soong configuration file; locating the configuration file corresponding to the SoC modules from the Makefile compilation rules and adding the compilation rules of the SoC modules in the configuration file; compiling and integrating the SoC modules into the customized partition based on the output path of the compiled SoC modules and the compilation rules of the SoC modules.

3. The method of claim 1, wherein, The modification of the partition mounting configuration file of the system to configure the mounting information of the customized partition comprises: adding the mounting information of the customized partition in the partition mounting configuration file of the system; adding the mounting entry of the customized partition; adding the OverlayFS rule to specify the overlay mounting of the SoC modules in the customized partition; determining the source directory in the OverlayFS as the directory of the SoC modules in the customized partition and determining the target directory.

4. The method of claim 1, wherein, The customized partition comprises multiple sub-partitions; the number of SoC modules is multiple; and the number of native partitions is multiple. The compilation and integration of the SoC modules into the customized partition comprises: compiling and integrating multiple SoC modules into the sub-partition corresponding to the function of the SoC module according to the function of each SoC module. The mounting of the SoC modules in the customized partition to the native partitions according to the configured mounting information comprises: mounting the SoC modules in each sub-partition to the native partition corresponding to the sub-partition according to the configured mounting information.

5. The method of claim 4, wherein, After mounting the SoC modules in each sub-partition to the native partition corresponding to the sub-partition, the method further comprises: obtaining the directory of the sub-partition; obtaining the directory of the native partition corresponding to the sub-partition; overriding or supplementing the directory of the native partition corresponding to the sub-partition with the directory of the sub-partition.

6. The method according to any one of claims 1 to 5, characterized in that, After mounting the SoC modules in the customized partition to the native partitions according to the configured mounting information, the method further comprises: monitoring the running state of the SoC modules; supporting the unloading of the SoC modules in the customized partition from the native partition when the SoC modules are in a non-running state.

7. The method according to any one of claims 1 to 5, characterized in that, The method further comprises: When the customized partition mounting fails or path conflicts, a rollback operation is performed from the native partition; The state of the SoC module is restored to the state coupled in the native partition.

8. The method according to any one of claims 1 to 5, characterized in that, After the SoC module is compiled and integrated into the customized partition, the method further comprises: Packing an image of the customized partition.

9. A partition management apparatus characterized by comprising: Comprise: A creating module for creating a customized partition; A modifying module for modifying a compilation rule corresponding to a system on chip (SoC) module, so as to decouple the SoC module from a native partition of a system and compile and integrate the SoC module into the customized partition; A configuring module for modifying a partition mounting configuration file of the system and configuring mounting information of the customized partition; A mounting module for mounting the SoC module in the customized partition to the native partition according to the configured mounting information based on an OverlayFS dynamic mounting technology.

10. An electronic device, comprising: A computer readable storage medium, a processor and a computer program stored on the computer readable storage medium and executable on the processor, wherein the processor implements the steps in the partition management method according to any one of claims 1 to 8 when executing the computer program.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps in the partition management method according to any one of claims 1 to 8.

Images