DAG-based ecological multi-party collaborative mobile terminal system upgrading method

Abstract

The application provides a mobile terminal system upgrade method based on ecological multi-party cooperation of DAG, which is characterized in that the method comprises two parts of an upgrade package publishing process and a terminal upgrade process, wherein the upgrade package publishing process specifically comprises publishing component upgrade packages, verifying and updating component dependencies, and updating verification information DAG data; the terminal upgrade process comprises the terminal acquiring a current system state DAG, the terminal requesting a upgradable component DAG data interface, the server calculating an upgrade path DAG data structure, the terminal accepting component upgrade DAG data structure, the terminal downloading related component upgrade packages to prepare for upgrade, and the terminal executing component upgrade; the application constructs upgrade dependency relationship data description and trust relationship data description of each component provider through a DAG data structure model, dynamically acquires upgrade packages according to subsystem components, performs credible analysis, thereby providing a verified optimal path, and ensuring stability and credibility of upgrade.

Description

Technical Field

[0001] This invention relates to the field of mobile terminal system upgrades, and is a method for dynamically constructing an upgrade list based on DAG data of the dependencies between subsystem upgrade components and the trust relationships between component manufacturers, minimizing the download of upgrade components; more specifically, it is a DAG-based multi-party collaborative mobile terminal system upgrade method. Background Technology

[0002] A complete terminal system consists of multiple subsystems, including device boot firmware, device firmware, device drivers, system kernel, system libraries, and embedded applications. In the mobile terminal system manufacturing field, these subsystems are provided by different stakeholders. For example, the device boot firmware is provided by the terminal manufacturer, the device hardware firmware by the SOC vendor, the device drivers by peripheral vendors, the kernel and system libraries by the OS vendor, and the embedded applications by professional service providers. A system upgrade package consists of upgrade components from one or more of these subsystems. For terminals, due to differences in hardware configuration and external device access, even for the same system version, different combinations of subsystem components may exist. Current solutions include: Solution 1, which provides a single upgrade package containing all necessary upgrade components, allowing the terminal to select and install them during the upgrade process. This often results in the transmission or storage of unnecessary packages during device upgrades; Solution 2, which creates different upgrade packages for each specific model, leads to complex system version management and the same system upgrade component appearing repeatedly in different upgrade packages on the upgrade release server, requiring additional storage capacity. Summary of the Invention

[0003] The purpose of this invention is to propose a mobile terminal system upgrade method based on DAG-based multi-party collaborative ecosystem, in order to solve the problems in the prior art where device upgrades often involve transmitting or storing unnecessary packages, which reduces work efficiency. Furthermore, different upgrade packages are required for each specific model, making system version management complex. Additionally, the same system upgrade component appears repeatedly in different upgrade packages on the upgrade release server, requiring additional storage capacity.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem includes two parts: an upgrade package release process and a terminal upgrade process. The upgrade package release process specifically includes S1, publishing the component upgrade package to the upgrade release server, S2, component dependency verification and updating, and S3, receiving verification information and updating DAG data. The terminal upgrade process includes the terminal obtaining the current system status DAG data, the terminal requesting the DAG data of upgradable components, the server calculating the DAG data of the upgrade path, the terminal receiving the component upgrade DAG data, the terminal downloading the relevant component upgrade package to prepare for the upgrade, and the terminal executing the component upgrade.

[0005] Step S1, publishing the component upgrade package to the upgrade release server, specifically includes: Subsystem component manufacturers release new versions to their own upgrade release servers. The service parses the upgrade package version, the versions of other dependent components, and other information to construct upgrade information, which is then registered with the central registration server built by the ecosystem operator. The upgrade information includes component descriptions of the upgrade package, a list of related dependent components, a list of compatibility with other components that have been tested and verified by the component manufacturers, and the component manufacturer's signature.

[0006] Step S2, component dependency verification and update, specifically includes: When dependent and dependent component manufacturers receive a dependency upgrade notification, if they are not on the certification list, they can conduct compatibility testing. This involves integrating the currently released versions of these components, as well as the currently released components (one or more versions) from their own manufacturer, onto the test equipment, running test cases on the agreed-upon API interfaces, analyzing the execution results of the test cases to determine compatibility / incompatibility, signing the results, and publishing them to the upgrade center registration server.

[0007] Step S3, receiving verification information to update DAG data, specifically includes: the upgrade information registration service receiving the upgrade information registration data from step S1 and the component dependency verification update information from step S2, and constructing the overall DAG data of the current upgrade component based on the above information.

[0008] The process of obtaining the current system state DAG for the terminal specifically includes: the terminal collecting version information of each component based on its own system configuration information, uploading the component information list to the central registration server, and obtaining the DAG data of the corresponding component of the local machine under the current state for upgrade preparation.

[0009] The terminal request for upgradeable component DAG data specifically includes: The terminal sends the complete DAG data of the current status of the components on its machine to the central registration server to obtain the DAG data of the overall component upgrade list; The terminal manually selects and uploads the DAG data of the component list for a portion of the path to the central registration server. When a user participates in an upgrade request, they only select the DAG data of the corresponding partial path that needs to be upgraded and upload it to the central registration server.

[0010] The server calculates the upgrade path DAG data, which specifically includes: The server calculates the upgrade path DAG data, which specifically includes: The central registration server obtains the list of installed and deployed components and their dependencies expressed using DAG data in the device, as well as information on all components and their dependencies expressed in DAG data stored in the central registration server. It then performs path search and path planning using graph algorithms to analyze the data and provide a feasible upgrade path expressed in DAG data. If the verification information is incomplete, the upgrade path returned by the server may not correspond to the full DAG data, but only to the sub-upgrade path of a part of the system. The information in the upgraded DAG data includes nodes and edges that form the upgrade path. The nodes in the path include specific information such as the download address of the version and the directed edges that provide the upgrade order. The server performs graph path calculation on the upgrade path of the DAG data representation and can provide information on the DAG data representation corresponding to the latest priority or the most stable priority upgrade path.

[0011] The process of upgrading DAG data for the terminal receiving component specifically includes: The terminal receives the upgrade path DAG data and verifies the information in the path of the DAG data. If the verification information or dependency information stored by the node is verified using a signature verification algorithm, and the verification is incorrect, it is considered that the DAG is not legally published DAG data or that the DAG data has been tampered with, and the upgrade process is terminated.

[0012] The process of the terminal downloading the relevant component upgrade package to prepare for the upgrade specifically includes: the terminal downloading the relevant upgrade package according to the address information of the component nodes in the DAG data, and then verifying it with the upgrade file signature information in the upgrade DAG data component nodes.

[0013] The upgrade of the terminal execution component specifically includes: If verification is successful, the terminal creates an upgrade script and related components based on the DAG data of the upgrade path. The system then selects one of the following upgrade methods based on the path information in the DAG data. ① The upgrade process will be executed automatically, and the automatic upgrade will restart. ② Automatic download for upgrades after the next restart; ③ Prompt the user to select an upgrade option.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention can atomically decompose the upgrade content and upgrade providers of a terminal system, construct upgrade dependency data descriptions and trust relationship data descriptions of various component providers through DAG data. This allows for dynamic acquisition and trust analysis of upgrade packages according to subsystem components. The terminal can obtain relevant subsystem component upgrade files from various parties in a timely manner, reducing the need to collect upgrade packages at the final release center for unified packaging. If a security issue arises at the release center, the provided upgrade path information may be tampered with, posing a threat of the system being upgraded to an insecure state. Because DAG data provides information authenticated by each component, it provides a verified optimal path, ensuring the stability and trustworthiness of the upgrade. Attached Figure Description

[0015] Figure 1 This diagram illustrates the interdependencies between various subsystem components during a terminal operating system upgrade. Figure 2 This is a diagram illustrating the compatibility of different versions of the present invention. Figure 3 This is a schematic diagram of the structure of the upgraded DAG data in this invention; Figure 4 This is a flowchart of the terminal upgrade process of the present invention; Figure 5 This is a schematic diagram of the overall architecture of the present invention; Figure 6 This is a schematic diagram of the central registration server and central registration database of the present invention; Figure 7 This is a schematic diagram of the component publishing server for the present invention; Figure 8 This is a schematic diagram of the terminal upgrade subsystem of the present invention. Detailed Implementation

[0016] To clarify the technical problems, technical solutions, implementation processes, and performance demonstrations, the present invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative. The present invention is not intended to limit the scope of the invention. Various exemplary embodiments, features, and aspects of this disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the drawings denote elements with the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0017] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0018] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0019] Example 1 like Figure 1 As shown, when upgrading a terminal operating system, a system upgrade package needs to contain multiple parts (subsystem components) during the upgrade packaging process. These parts are generally divided into application parts, system driver parts, system kernel and hardware-related firmware according to their layers. These parts are released from different manufacturers and the release time is not simultaneous. Therefore, when building the upgrade package, it is necessary to confirm that these parts have mutual dependencies. In addition, the same subsystem component may also have other dependencies such as manufacturer device configuration and manufacturer verification dependencies.

[0020] Therefore, whether a subsystem component can be upgraded is not simply a matter of version compatibility. Rather, it requires verification through multiple dependencies to confirm whether these components can be upgraded on the target terminal.

[0021] like Figure 2 As shown, green indicates verified availability. For example, driver version 2.1 of system A can be verified as available on OS 1.2.0 of system B, which is OS 2.0.1 of system C. OS 1.2.0 of system B can be installed on device D, OS 2.0.1 of system C can be installed on device E, and OS 1.9.0 of system C can be installed on device F. However, OS 2.0.1 of system C cannot be installed on device F.

[0022] To address the aforementioned issues, a DAG (Directed Acyclic Graph) dataset is needed to describe the system component status information, upgrade path information, build version, and other dependencies required during the upgrade process. The basic information of the current subsystem components is used as nodes in the graph, and version dependency information, module dependency information, and verification / license information are used as directed edges to form the dependency information between nodes, with the direction pointing from the dependent at the upper level to the dependent at the lower level.

[0023] Through collaboration between the terminal, the version metadata server, and the upgrade package distribution servers of each subsystem, a description file for the upgrade DAG data is constructed. After obtaining the description file of the upgrade path DAG data for the current relevant devices, the terminal obtains the upgrade subsystem packages, builds the final upgrade package locally, and completes the system upgrade.

[0024] Upgrade DAG data such as Figure 3As shown, nodes are used to refer to components, and node attributes record information about related components, such as component name, type, description, etc., as well as the signature that provides node information; directed edges are used to refer to component version dependencies, and edge attributes are responsible for recording the dependency relationships, including compatibility version requirements, compatibility certifiers, and the signature of the information provider.

[0025] The terminal sends DAG data (Directed Acyclic Graph) of its various components and their dependencies (hereinafter referred to as state DAG data) to the version management server for upgrade matching and verification. The entire upgrade process is as follows: like Figure 4 As shown, a method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem includes two parts: an upgrade package release process and a terminal upgrade process. The upgrade package release process specifically includes S1, publishing the component upgrade package to the upgrade release server, S2, component dependency verification and updating, and S3, receiving verification information and updating DAG data. The terminal upgrade process includes the terminal obtaining the current system state DAG, the terminal requesting the DAG data interface of upgradable components, the server calculating the upgrade path DAG data, the terminal receiving the component upgrade DAG data, the terminal downloading the relevant component upgrade package to prepare for the upgrade, and the terminal executing the component upgrade.

[0026] Step S1, publishing the component upgrade package to the upgrade release server, specifically includes: Subsystem component manufacturers release new versions to their own upgrade release servers. The service parses the upgrade package version, the versions of other dependent components, and other information to construct upgrade information, which is then registered with the central registration server built by the ecosystem operator. The upgrade information includes component descriptions of the upgrade package, a list of related dependent components, a list of compatibility with other components that have been tested and verified by the component manufacturers, and the component manufacturer's signature.

[0027] Step S2, component dependency verification and update, specifically includes: When dependent and dependent component manufacturers receive a dependency upgrade notification, if they are not on the certification list, they can conduct compatibility testing. This involves integrating the currently released versions of these components, as well as the currently released components (one or more versions) from their own manufacturer, onto the test equipment, running test cases on the agreed-upon API interfaces, analyzing the execution results of the test cases to determine compatibility / incompatibility, signing the results, and publishing them to the upgrade center registration server.

[0028] Step S3, receiving verification information to update DAG data, specifically includes: the upgrade information registration service receiving the upgrade information registration data from step S1 and the component dependency verification update information from step S2, and constructing the overall DAG data of the current upgrade component based on the above information.

[0029] The process of the terminal obtaining the current system status DAG data specifically includes: the terminal collecting version information of each component based on its own system configuration information, uploading the component information list to the central registration server, and the central registration server obtaining the DAG data of the corresponding component of the local machine under the current status for upgrade preparation.

[0030] The terminal request for upgradeable component DAG data specifically includes: The terminal sends the complete DAG data of the current status of the components on its machine to the central registration server to obtain the DAG data of the overall component upgrade list; The terminal manually selects and uploads the DAG data of the component list for a portion of the path to the central registration server. When a user participates in an upgrade request, they only select the DAG data of the corresponding partial path that needs to be upgraded and upload it to the central registration server.

[0031] The process of calculating the DAG data for the server upgrade path specifically includes: The central registration server obtains the DAG data of the current installed components of the device and analyzes it with the DAG data of all components stored in the central registration server using graph algorithms for path search and path planning to provide a feasible upgrade path DAG data. If the verification information is incomplete, the upgrade path returned by the server is sometimes not a complete path DAG data, but only a sub-upgrade path of a part of the system. The upgrade path DAG data describes the upgrade path through component nodes and edges connecting component relationships. The nodes in the path provide the download address of the version, and the directed edges provide the upgrade order. The server performs graph path calculation on the DAG and can provide DAG data of the latest priority or the most stable priority upgrade path.

[0032] The terminal receiving component upgrade DAG data specifically includes: The terminal receives the DAG data of the upgrade path and verifies the information in the path of the DAG data. If the verification information or dependency information stored by the node is verified using a signature verification algorithm, and the verification is incorrect, the terminal considers the DAG data to be invalid or that the DAG data has been tampered with, and terminates the upgrade process.

[0033] The process of the terminal downloading the relevant component upgrade package to prepare for the upgrade specifically includes: the terminal downloading the relevant upgrade package according to the address information in the component nodes in the DAG data, and then verifying it against the upgrade file signature information in the upgrade DAG data.

[0034] The upgrade of the terminal execution component specifically includes: If verification is successful, the terminal creates an upgrade script based on the DAG data to upgrade and install the relevant components. The system selects one of the following upgrade methods based on the settings in the DAG data. ① The upgrade process will be executed automatically, and the automatic upgrade will restart. ② Automatic download for upgrades after the next restart; ③ Prompt the user to select an upgrade option.

[0035] In practice, the operator builds a central server, manufacturers build their own component release servers, and upgrade service modules are installed in the terminal devices. The overall architecture is as follows: Figure 5 As shown.

[0036] The specific components are as follows: 1. Central registration server, such as Figure 6 As shown 1.1 Build web services to provide vendor registration services, component information management services, component relationship services, and DAG-based calculation management services; 1.2 Vendor Registration Service provides vendor registration, CA-signed vendor signature certificates, and access credentials for vendor web service calls, used for authentication of API calls between vendor upgrade package servers and central registration servers; 1.3 Establish a central registration database, and create component manufacturer data tables, component information data tables, and upgrade DAG data tables to store component DAG information and component attribute data (manufacturer data tables and component information data tables). 1.4 Build a data management module to process the data generated by the service operations, including saving the data to the database, or retrieving and updating the data from the database; 2. For example Figure 7 As shown, a component publishing server is built to provide component upgrade package upload services, component upgrade package signing services, and component download services.

[0037] 2.1 Component manufacturers upload component upgrade packages to the server through the component management service's web interface. The component management service parses the upgrade package's metadata through the package processing module, extracts component version description information, version, dependencies, and other information, and submits the package information to the central registration server through the registration management module. 2.2 The component manufacturer submits the upgrade package verification information. The package processing module parses the upgrade package update notification and calls the component relationship management service of the central registration server through the registration management module to transfer the relevant upgrade package compatibility certification information. 2.3 Component File Service: Provides component upgrade package download service.

[0038] 3. Terminal Upgrade Subsystem like Figure 8As shown, the DAG management module, installed on the client side, is responsible for calling other internal modules, connecting to the central registration server, maintaining the DAG dependency data of various components on the local machine, uploading upgrade update requests, obtaining DAG upgrade path data, and downloading upgrade packages. The specific steps are as follows: S3.1 The upgraded DAG management module calls the terminal-installed component query module to obtain the current component list, connects to the central registration server, and obtains the upgraded DAG data; S3.2 The upgraded DAG management module's signature verification module verifies the obtained DAG data. If the signature verification passes, the module performs graph analysis on the data to obtain the upgrade path and upgrade node information. S3.3, The upgraded DAG management module obtains the download address and related information of the component upgrade package from the upgrade node information; S3.4 Upgrade the DAG management module by calling the upgrade package download management function and downloading the upgrade package; S3.5 Upgrade the DAG management module to call the signature verification module to verify the integrity and trustworthiness of the downloaded package; S3.6 The upgrade DAG management module calls the upgrade installation module and follows the path represented by the DAG data, according to the component upgrade package.

[0039] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem, characterized in that, The process comprises two parts: an upgrade package release process and a terminal upgrade process. The upgrade package release process specifically includes S1, publishing the component upgrade package to the upgrade release server, S2, component dependency verification and updating, and S3, receiving verification information and updating DAG data. The terminal upgrade process includes the terminal obtaining the DAG data of the corresponding component in the current state, the terminal requesting the DAG data of upgradable components, the server calculating the DAG data of the upgrade path, the terminal receiving the component upgrade DAG data, the terminal downloading the relevant component upgrade package to prepare for the upgrade, and the terminal executing the component upgrade. The DAG is used to construct dependencies such as version. The basic information of the current subsystem components is used as the nodes of the graph, and the version dependency information, module dependency information, and verification license information are used as the dependency information between the nodes as directed edges, with the direction from the upper-level dependent to the lower-level dependent. Step S1, publishing the component upgrade package to the upgrade release server, specifically includes: Subsystem component manufacturers release new versions to their own upgrade release servers. The upgrade release servers parse the upgrade package version, the version information of other dependent components, construct upgrade information, and register it with the central registration server built by the ecosystem operator. The upgrade information includes component description information of the upgrade package, a list of related dependent components, a list of compatibility with other components that have been tested and verified by the component manufacturers, and the component manufacturer's signature. The DAG data for calculating the server upgrade path specifically includes: The central registration server obtains the device DAG data and the DAG data stored on the central registration server, performs path search and path planning using graph algorithms, and provides a feasible DAG data. If the verification information is incomplete, the upgrade path returned by the server may not be the information corresponding to the full DAG data, but only the information corresponding to the sub-upgrade path of a part of the system. The upgrade DAG data contains nodes and edges that form the upgrade path. The nodes in the path include the download address of the version, and the directed edges provide specific information about the upgrade order. The server performs graph path calculation on the upgrade path of the DAG data and can provide information on the DAG data corresponding to the latest priority or the most stable priority upgrade path.

2. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, Step S2, component dependency verification and update, specifically includes: When dependent and dependent component manufacturers receive a dependency upgrade notification, if they are not on the certification list, they can conduct compatibility testing. This involves integrating the currently released versions of these components and the currently released components of their manufacturer onto the test equipment, running test cases on the agreed-upon API interfaces, analyzing the execution results of the test cases to determine compatibility / incompatibility, signing the results, and publishing them to the central registration server.

3. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, Step S3, receiving verification information to update DAG data, specifically includes: the upgrade information registration service receiving the upgrade information registration data from step S1 and the component dependency verification update information from step S2, and constructing the overall DAG data of the current upgrade component based on the above information.

4. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, The process of obtaining the DAG data of the corresponding component of the terminal in the current state specifically includes: the terminal collecting the version information of each component according to the configuration information of its various systems, uploading the component information list to the central registration server, and obtaining the DAG data of the corresponding component of the terminal in the current state for upgrade preparation.

5. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, The terminal request for upgradeable component DAG data specifically includes: The terminal sends the complete DAG data of the current status of the components on its machine to the central registration server to obtain the DAG data of the overall component upgrade list; The terminal manually selects and uploads the DAG data of the component list for a portion of the path to the central registration server. When a user participates in an upgrade request, they only select the DAG data of the corresponding partial path that needs to be upgraded and upload it to the central registration server.

6. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, The terminal receiving component upgrade DAG data specifically includes: The terminal receives the upgrade path DAG and verifies the information in the path of the DAG. If the verification information or dependency information stored by the node is verified using a signature verification algorithm, and the verification is incorrect, it is considered that the DAG data is not legally published DAG data or that the DAG data has been tampered with, and the upgrade process is terminated.

7. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, The process of the terminal downloading the relevant component upgrade package in preparation for the upgrade includes: the terminal downloading the relevant upgrade package according to the address information of the DAG, and then verifying it against the upgrade file signature information in the upgrade DAG data.

8. The method for upgrading a mobile terminal system based on DAG-based multi-party collaborative ecosystem as described in claim 1, characterized in that, The upgrade of the terminal execution component specifically includes: If verification is successful, the terminal creates an upgrade script and related components based on the DAG. The system then selects one of the following upgrade methods based on the path information in the DAG data. (1) Automatically execute the upgrade steps and restart the automatic upgrade; (2) Automatic download for upgrades after the next restart; (3) Prompt the user to select the upgrade action.

Images