Platform software release method, starting method, system, device and medium

Abstract

This application discloses a method for releasing and launching platform software, a system, an apparatus, a medium, and a product, relating to the field of computer software technology. The method for releasing platform software includes: a server obtaining the source code of software related to a target platform, wherein the source code includes platform common code and project difference code for at least one project on the target platform; compiling the source code to obtain a platform common file for the platform common code and project difference files for the project difference code; constructing a platform software package corresponding to the project based on the platform common file and the project difference files, and outputting the platform software package, wherein the platform software package is a file in image file format. Since the common code and the difference code are compiled separately in this application, all projects on the platform can share the same set of compiled common code results, thereby significantly reducing the compilation workload and saving server computing resources.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a method for releasing platform software, a method for starting up the software, a system, a device, a medium, and a product. Background Technology

[0002] Currently, automakers generally adopt a development model that incubates multiple derivative projects based on the same chip platform. While these platform-based projects share many commonalities, they also have differentiated content to meet the varying needs of different vehicle models or markets. This necessitates that each project's complete codebase be independently compiled and packaged upon release. Especially when the number of platform-derived projects increases to dozens, the massive amount of repetitive compilation tasks during releases places enormous pressure on the server's computing, storage, and bandwidth, resulting in severe resource waste. Summary of the Invention

[0003] The main purpose of this application is to provide a method for releasing platform software, a method for starting up the software, a system, a device, a medium, and a product, in order to solve the technical problem that the compilation of code during the release process in traditional solutions will cause waste of resources.

[0004] To achieve the above objectives, this application proposes a method for releasing platform software, the method comprising: Obtain the source code of the software related to the target platform, wherein the source code includes the platform's common code and the project difference code of at least one project on the target platform; The original code is compiled to obtain the platform common file of the platform common code and the project difference file of the project difference code; Based on the platform's common files and the project's difference files, a platform software package corresponding to the project is constructed and output. The platform software package is a file in image file format.

[0005] Optionally, the step of compiling the original code to obtain the platform common file of the platform common code and the project difference file of the project difference code includes: From the original code, filter out the platform common code belonging to the common partition and the project difference code belonging to the difference partition; The platform common code is compiled into the platform common file, and the project difference code is compiled into the project difference file.

[0006] Optionally, the step of filtering platform common code belonging to the common partition and project difference code belonging to the difference partition from the original code includes: Based on the identifier parameter of the file directory path where each code segment in the original code is located, the platform common code belonging to the common partition and the project difference code belonging to the difference partition in the original code are identified.

[0007] Optionally, if the identification parameter matches the target partition parameter of the operating system corresponding to the target platform, the code snippet in the file directory path where the identification parameter is located is used as the platform common code, or as the project difference code.

[0008] Optionally, after the step of obtaining the source code of the platform-related software, the method includes: The original code is divided into code units; Extract multi-dimensional features from each code unit, wherein the multi-dimensional features include at least two different features of the code unit; Based on the multi-dimensional features of each code unit, clustering and classification are performed on each code unit to obtain each code cluster group; The platform common code and the project difference code are marked in the original code by the respective code clusters.

[0009] Optionally, the multi-dimensional features include at least two of the following: text features, abstract syntax tree structure features, code evolution path features, and functional features.

[0010] Optionally, the step of dividing the original code into code units includes: The original code is segmented based on its code structure and / or functional attributes to obtain initial code units; Identify the target unit in each of the initial code units; The differential variables of the target units in each initial code unit are fuzzed to obtain each code unit.

[0011] In addition, to achieve the above objectives, this application also proposes a method for launching platform software, wherein the platform software package corresponding to the project in the platform is obtained through the above-described method for releasing platform software. The platform software startup method includes: Receive the platform software package, write the platform common files in the platform software package to the common partition, and write the project difference files in the platform software package to the difference partition; The loader is started, loading the platform common files in the common partition and the project difference files in the difference partition to run the platform software corresponding to the platform package.

[0012] Optionally, the step of launching the loader and loading the platform common files in the common partition and the project difference files in the difference partition includes: The loading program is started, and the platform common files and project difference files are loaded through a phased on-demand loading strategy. The phased on-demand loading strategy includes at least a basic environment initialization phase and a system service startup phase. The required platform common files and project difference files are different in different phases.

[0013] Furthermore, to achieve the above objectives, this application also proposes an interactive system for platform software, characterized in that the interactive system for the platform software includes: The server is used to obtain the source code of the software related to the platform, wherein the source code includes platform common code and project difference code of at least one project on the platform; compile the source code to obtain platform common files of the platform common code and project difference files of the project difference code; based on the platform common files and the project difference files, construct a platform software package corresponding to the project, and output the platform software package to the terminal device; A terminal device is used to receive a platform software package output by a server, write the platform common files in the platform software package into a common partition, and write the project difference files in the platform software package into a difference partition; start a loader to load the platform common files in the common partition and the project difference files in the difference partition to run the platform software corresponding to the platform software package.

[0014] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the platform software release method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the platform software release method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the platform software release method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: In this embodiment, the server can obtain the original code of the target platform's related software, wherein the original code includes platform common code and project-specific code for at least one project on the target platform; the original code is compiled to obtain platform common files for the platform common code and project-specific files for the project-specific code; based on the platform common files and the project-specific files, a platform software package corresponding to the project is constructed and output, wherein the platform software package is a file in image file format. That is, this application improves the compilation logic of the code compilation part during software release by independently compiling the target platform's common code as the differentiated code for each individual project, forming platform common files and project-specific files, and then constructing a platform software package in image file format corresponding to the project using the platform common files and project-specific files, and outputting it. It is understood that since the common code and differentiated code are compiled separately, each project on the platform can share the same set of compiled common code results, thereby significantly reducing the compilation workload, saving server computing resources, and ensuring stable releases of multiple projects. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the software release method for the platform in this application. Figure 2 This is a schematic diagram illustrating the overall framework of the software release method for the platform in this application. Figure 3 This is a flowchart illustrating the second embodiment of the software release method for the platform in this application. Figure 4 This is a flowchart illustrating the first embodiment of the platform software startup method of this application; Figure 5A This is a schematic diagram of the software startup process in the startup method of the platform software of this application; Figure 5B This is a schematic diagram of the software startup process in the Android scenario of the platform software startup method in this application; Figure 6 This is a schematic diagram of the framework of the interactive system of the platform software in this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the method of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] With the development of smart cockpit technology, automakers generally adopt a development model that incubates multiple derivative projects based on the same chip platform. While these platform-based projects share many commonalities, they also have differentiated content to meet the varying needs of different vehicle models or markets. This necessitates that each project's complete codebase be independently compiled and packaged upon release. Especially when the number of platform-derived projects increases to dozens, the massive amount of repetitive compilation tasks places enormous pressure on the server's computing, storage, and bandwidth, resulting in serious resource waste.

[0025] The main solution of this application embodiment is: to obtain the original code of the software related to the target platform, wherein the original code includes platform common code and project difference code of at least one project on the target platform; to compile the original code to obtain platform common files of platform common code and project difference files of project difference code; to build a platform software package corresponding to the project based on the platform common files and project difference files, and to output the platform software package, wherein the platform software package is a file in image file format.

[0026] In other words, this application improves the compilation logic of the code compilation section during software release. It compiles the common code for the target platform independently as differentiated code for each individual project, creating platform common files and project difference files. These files are then used to construct a platform software package in image file format corresponding to each project, and the package is output. As the common and differentiated code are compiled separately, all projects on the platform can share the same set of compiled common code results, significantly reducing the compilation workload, saving server computing resources, and ensuring stable releases for multiple projects.

[0027] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a server, vehicle terminal, computer, mobile phone, etc., or an electronic device capable of realizing the above functions.

[0028] Reference Figure 1 This is a flowchart illustrating the first embodiment of the platform software release method of this application. In this embodiment, the platform software release method includes steps S10 to S30: Step S10: Obtain the source code of the software related to the target platform, wherein the source code includes the platform common code and the project difference code of at least one project on the target platform; It should be noted that, in this embodiment, the execution entity of the above-mentioned platform software release method can be a server, that is, the code compilation work of different projects derived from the target platform is completed on the server, and the corresponding software packages for each project are formed. Optionally, the target platform can be the chip platform installed on the vehicle's in-vehicle terminal device, and different projects refer to the chip platform being used in different vehicle models or vehicle versions. Although the chip platform used is the same, there will be certain differences in functionality between different vehicle models or versions. Optionally, in this embodiment, the above-mentioned platform software can be the system software of the vehicle's in-vehicle terminal device (such as a vehicle infotainment system).

[0029] For example, the server can obtain the source code of the software related to the target platform. This source code includes platform common code and project-specific code for at least one project on the target platform; typically, it includes project-specific code for multiple projects. Platform common code refers to code that can be used by all projects, such as logically consistent code across projects. Project-specific code is typically project-specific code. For instance, if a vehicle model corresponding to a project has a function A, and function A is unique to that vehicle model, then the specific code used to implement function A can be considered the project-specific code for that project. Optionally, the server can obtain the source code from a unified code repository or from submissions by each project team. Optionally, the platform common code and project-specific code can be pre-defined or can be separated by the server after obtaining the source code.

[0030] Step S20: Compile the original code to obtain the platform common files of the platform common code and the project difference files of the project difference code; For example, the platform common code and project difference code in the original code are compiled separately to form partitioned image files, namely, the platform common file for the platform common code and the project difference file for the project difference code. Different projects can share the platform common file, and each project also has at least one copy of the project difference file.

[0031] Optionally, in practical applications, the platform common code in the original code can be stored in a specific directory of the main branch. Each project can correspond to a directory of a long-term feature branch, and the code in that directory can be used as the project difference code. By parsing the file directory of the original code, it is determined which code is the platform common file and which code is the project difference file. Then, the compilation tool is called to compile the platform common code and the project difference code, respectively, to obtain the platform common file and the project difference file. Both the platform common file and the project difference file are binary image files, and both types of image files are used for installing software on the target platform, for example, for installing an operating system. The difference is that the platform common file is the product of compiling the platform common code, while the project difference file is the product of compiling the project difference code.

[0032] In one feasible implementation, the steps of compiling the original code to obtain the platform common file of platform common code and the project difference file of project difference code include steps S21 to S22: Step S21: Filter out the platform common code belonging to the common partition and the project difference code belonging to the difference partition from the original code; Step S22: Compile the platform common code into platform common files and compile the project difference code into project difference files.

[0033] For example, the server can filter out platform common code belonging to the common partition and project difference code belonging to the difference partition by file directory path or the code's own identifier.

[0034] Optionally, predefined variables and rules can be used to explicitly specify which code file directory paths in the original code belong to the public partition and which belong to the differentiated partition.

[0035] In one feasible implementation, filtering platform common code belonging to the common partition and project difference code belonging to the difference partition from the original code includes step S211: Step S211: Based on the identifier parameter of the file directory path where each code segment in the original code is located, identify the platform common code belonging to the common partition and the project difference code belonging to the difference partition in the original code.

[0036] It should be noted that the aforementioned identifier parameters can be keywords, macros, variables, or specific tags in the file path that reflect its ownership. Specifically, the original name directory in the file path can be specified as the identifier parameter, or new text or descriptions can be added as identifier parameters. For example, directory names such as system / , vendor / , device / [vendor] / [project] can be selectively used as identifier parameters. Path macros representing specific partitions in the system can also be constructed, for example, adding the description TARGET_OUT_SYSTEM to the file path, or explicitly declaring its attributes directly in the path, such as vendor: true. The specific form of the identifier parameters is not limited here. Optionally, there can be two identifier parameters, used to identify platform common code and project difference code respectively. Optionally, there can also be only one identifier parameter, used to identify either platform common code or project difference code, while unmarked code is classified as the other type of code. For example, when traversing all code snippets, those not marked with identifier parameters can be defaulted to platform common code, while those marked with identifier parameters are determined to be project difference code.

[0037] In one feasible implementation, if the identifier parameter matches the target partition parameter of the target platform's corresponding operating system, the code snippet in the file directory path where the identifier parameter is located is used as platform common code, or as project difference code.

[0038] It should be noted that in practical applications, the target platform can run either Android or Linux. Different operating systems differ in their frameworks and file path directories, and consequently, the methods or forms of the identifier parameters used to distinguish different code will also differ for different operating systems. Therefore, before identifying platform common code and project difference code from the source code, the target partition parameters can be determined based on the type of operating system installed or running on the target platform. Optionally, the target partition parameters can be determined through a pre-established mapping relationship between operating systems and partition parameters. Then, the target partition parameters are matched with the identifier parameters of the file directory paths where each code segment in the source code is located. Optionally, the target partition parameters can include two types, such as a first type of partition parameter and a second type of partition parameter, corresponding to platform common code and project difference code, respectively. Optionally, the target partition parameters can also correspond only to platform common code or project difference code.

[0039] For example, if the identifier parameter of the file directory path where each code snippet in the original code is located matches the target partition parameter mentioned above, then the code snippet under the file directory path where the identifier parameter is located can be used as platform common code or project difference code.

[0040] For example, in the Android operating system, the server can parse the PRODUCT_COPY_FILES list to determine the prefix of the file directory path where each piece of code resides. If the file directory path prefix begins with macros indicating common partitions, such as TARGET_COPY_OUT_SYSTEM or TARGET_OUT_SYSTEM (corresponding to / system), the code under that file directory path is identified as platform common code. Conversely, if no identifier parameter matching the target partition parameter is found in the file directory path, it can be considered project-specific code. Alternatively, the identifier parameter can exist in the form of attribute parameters such as vendor: true, device_specific: true, soc_specific: true (i.e., true is the identifier parameter). If the target partition parameter is also true, the identifier parameter can be considered to match the target partition parameter, and correspondingly, the code under the corresponding file directory path can be determined to belong to a specific project's differentiated code. Conversely, if there is no true identifier parameter, the code under that path belongs to platform common code.

[0041] For example, for the Linux operating system, the server can also distinguish between platform common code and project difference code by matching target partition parameters. Identification is based on the meta-level path where the code resides (i.e., the file directory path mentioned above). If the code snippet is located in a common layer path such as `meta` or `meta-poky` (i.e., the target partition parameters are `meta` and `meta-poky`), it can be considered that the identifier parameter matches the target partition parameter, and accordingly, the code snippet is classified as platform common code. Conversely, if it is not located in a `meta` or `meta-poky` path, it is classified as project difference code. Alternatively, if the code snippet is located in a project-specific layer path such as `meta-customer-project-a` (i.e., the target partition parameter is `meta-customer-project-a`), it can be considered that the identifier parameter matches the target partition parameter, and accordingly, the code snippet is classified as project difference code. Conversely, if the code snippet is not located in a `meta-customer-project-a` path, it can be classified as platform common code.

[0042] It is understandable that the form of the above-mentioned flag parameters can be set with reference to the above examples for different operating systems, and will not be elaborated here.

[0043] For example, based on the identification results of the above process, the actual compilation operation is performed to generate a reusable public partition image and a project-specific differential partition image.

[0044] Optionally, the identification results can be a list of platform common code and a list of project difference code. During the compilation process, based on the list of platform common code, the corresponding code is retrieved and independently and completely compiled. For example, a common partition image (such as the core part of system.img), i.e., platform common files, can be generated using a standard platform toolchain and configuration. Similarly, the server can obtain the project difference code through the list of project difference code and independently and completely compile it to generate a difference partition image, i.e., the aforementioned project difference code.

[0045] It should be noted that, to achieve the above functionality, this embodiment adjusts the conventional compilation logic so that the compilation process can compile both platform common code and project-specific difference code separately, forming a common partition image (i.e., platform common files) and a difference partition image (differential partition image). An example of the code that implements the compilation of project-specific difference code (placeholders 1 and 2 in the code can refer to a specific project) is shown below: ifneq($(strip $(BOARD_ANDROID_PARTITION_SIZE)),) / / Check if the image size for this differential partition is defined; INSTALLED_ANDROID_placeholder1placeholder2_TARGET := $(PRODUCT_OUT) / placeholder1_placeholder2.img / / Set the file path and name for generating the differential partition image; define build-android placeholder1image placeholder2-target / / Define a build function to encapsulate the specific commands for generating the image; @mkdir -p $(TARGET_OUT_ANDROID_placeholder1placeholder2) / / Create a temporary directory to store the differentiated files to be packaged; @touch $(TARGET_OUT_ANDROID_placeholder1placeholder2) / placeholder1_placeholder2.txt / / Generates a marker file in a temporary directory, which may be used for debugging or to ensure that the directory is not empty; $(hide)PATH=$(HOST_OUT_EXECUTABLES):$${PATH} $(MKEXTUSERIMG) -s $(TARGET_OUT_ANDROID_placeholder1placeholder2) $@ ext4placeholder1_placeholder2 $(BOARD_ANDROIDplaceholder1placeholder2_PARTITION_SIZE) / / Execute image creation command; $(hide)chmod a+r $@ / / Modify the permissions of the generated image file; $(hide)$(call assert-max-image-size,$@ $(BOARD_ANDROID_PARTITION_SIZE)) / / Call the function to check if the image file size exceeds the specified partition size; endef; $(build-android placeholder1image placeholder2-target) / / Calls the build function defined above in the target rule, which actually executes the image generation command; droidcore: $(INSTALLED_ANDROID_placeholder1placeholder2_TARGET) / / Add this image target to the dependencies of droidcore so that the differential partition image will be automatically generated when a full compilation is performed.

[0046] The core logic of the above code is as follows: when the partition size for the project's differentiated code is defined, all files that need to be placed in that partition are collected, then the image packaging tool is called to generate an image, and the size is verified. Finally, the image is registered with the build system, making it an independently buildable target. This enables independent compilation and packaging of differentiated code, thereby supporting the customization needs of each project in a platform-based project. It should also be noted that the above code is only for example; the code in actual applications may differ from the above code example, so it will not be elaborated here.

[0047] Step S30: Based on the platform common files and project difference files, build the platform package corresponding to the project and output the platform package, which is a file in image file format.

[0048] For example, the server then builds a platform software package corresponding to the relevant project based on the platform's common files and project difference files. This platform software package is then output as an installation package or update package, for example, sent to the vehicle's in-vehicle terminal device.

[0049] Optionally, for embedded systems (such as systems in vehicle smart cockpits), the final software package is often a complete partition image file, such as a complete binary executable file corresponding to the original code. Optionally, platform common files (such as system_common.img, common_rootfs.ubi, base_libraries.tar.gz) and project difference files (such as project_a_diff.img, project_a_overlay.squashfs, vendor_apps.zip) can be merged into a logical super.img or firmware.bin firmware package using tools such as lpmake, mkfs.ubifs, tar, or ota_packager, thus forming the platform software package. Optionally, the platform software package can also include a flashing script (updater-script), which can instruct the common image portion to be flashed into the common partition and the difference image portion to be flashed into a newly added difference partition. Additionally, refer to... Figure 2 This is a schematic diagram of the overall framework process in the embodiments of this application, such as... Figure 2 As shown, in the server, the platform common code and the project-specific code are compiled to obtain platform common files and project-specific files, respectively. These files can then be used to build a platform software package. Finally, the server can send the generated platform software package to the terminal devices under the corresponding project.

[0050] In this embodiment, the server can obtain the original code of the platform-related software, which includes platform common code and project-specific code for at least one project on the platform. The original code is compiled to obtain platform common files (for the platform common code) and project-specific files (for the project-specific code). Based on the platform common files and project-specific files, a platform software package corresponding to the project is constructed and output. In other words, this application improves the compilation logic of the code compilation section during software release. The common code of the target platform is compiled independently as the differentiated code for each individual project, forming platform common files and project-specific files. Then, a platform software package in image file format corresponding to the project is constructed using the platform common files and project-specific files and output. It is understood that since the common code and differentiated code are compiled separately, all projects on the platform can share the same set of compiled common code results, thereby significantly reducing the compilation workload, saving server computing resources, and ensuring stable releases for multiple projects.

[0051] Reference Figure 3This is a flowchart illustrating the second embodiment of the software release method for the platform of this application. Contents in this embodiment that are the same as or similar to those in the above embodiments can be referred to the above description and will not be repeated hereafter. After the step of obtaining the original code of the platform-related software, the method includes steps S11 to S14: Step S11: Divide the original code into code units; Step S12: Extract multi-dimensional features of each code unit, wherein the multi-dimensional features include at least two different features of the code unit; Step S13: Based on the multi-dimensional features of each code unit, perform clustering and classification processing on each code unit to obtain each code cluster group; Step S14: Mark the platform common code and project difference code in the original code through each code cluster.

[0052] It should be noted that in this implementation, after receiving the original code, the server can automatically identify and mark the platform common code and project difference code in the original code.

[0053] For example, the server can first divide the original code into individual code units. Optionally, the original code can be divided based on its code structure. For instance, the source code can be parsed using compiler front-end tools (such as Clang's LibTooling or Java's ASM) to generate an abstract syntax tree. Then, specific node types in the syntax tree are used as dividing boundaries. For example, for C / C++ / Java, a code unit is typically defined as a function or class; for configuration files (XML, JSON, PROP), it can be defined as a complete configuration file or a logically independent fragment within it (such as a single...). <permission>A node is considered a unit. For resource files, a single resource entry or the entire resource file can be considered a unit of code.

[0054] For example, multi-dimensional features are extracted from each code unit (the multi-dimensional features include at least two distinct features related to the code unit), and a comprehensive feature vector is constructed for each unit for quantitative comparison and classification. Optionally, the multi-dimensional features include at least two of the following: text features, abstract syntax tree structure features, code evolution path features, and functional features. Typically, to ensure accuracy, multi-dimensional features may include text features, abstract syntax tree structure features, code evolution path features, and functional features.

[0055] Optionally, for text features, the text similarity on the surface of code units can be quantified, which is the basis for detecting direct copying or highly similar code. For example, code text can be normalized, including: removing comments ( / / , / The preprocessed code text is mapped to vectors, i.e., text features, using characters such as / and #, as well as standardized whitespace characters (space, tab, newline).

[0056] The main purpose of abstract syntax tree (API) structure features is to capture the similarity of code syntax structures. For example, a parser for the corresponding programming language can be used to convert code units into APIs, where each node represents a syntax structure.

[0057] To identify code evolution path characteristics, evolutionary metadata for code units is extracted from the codebase. This metadata can include: Author sequence: an ordered list of all authors who have historically modified the code unit; Time pattern: a sequence of commit timestamps reflecting whether modifications are concentrated bursts or long-term stable changes; Change motivation: keywords or themes from associated commit messages; Co-change network: a set of other files frequently modified in the same commit, indicating strong functional correlations. This metadata is then combined into a structured vector.

[0058] For functional characteristics, a "call profile" can be formed by analyzing all external functions, library APIs, or system service interfaces called by the code unit. The input sources (such as function parameters, read files, global variables) and output sources (such as return values, written files, modified global states) of the code unit are identified. A simplified data flow graph signature is generated for the code unit. The above analysis results (call profile, data flow signature) can be encoded into a vector.

[0059] It is understandable that the extracted text features, abstract syntax tree structure features, code evolution path features, and functional features can form high-dimensional vector features of the corresponding code units, that is, multi-dimensional features.

[0060] For example, based on the multi-dimensional features of each code unit, clustering and classification processing is performed on each code unit, and code units with similar features are automatically grouped into code clusters.

[0061] Optionally, hierarchical clustering analysis can be performed on the feature vectors (i.e., multi-dimensional features) of all code units to generate a dendrogram. Then, the platform architect or domain expert, based on business knowledge, selects an appropriate similarity threshold on the dendrogram for segmentation to form initial clusters. Subsequently, post-processing rules can be defined, such as: "If a cluster contains units from more than 80% of the projects, then mark it as a 'candidate common cluster'."

[0062] For example, platform common code and project difference code are marked in the original code based on each code cluster. Optionally, after clustering to obtain each code cluster, it can be determined whether the code units in the corresponding code cluster belong to common code or difference code based on the project to which each code unit belongs. For example, if a cluster contains code units from more than a certain percentage of projects, the code units in that cluster can be regarded as common code and marked. Conversely, if the number of projects to which the code units in a cluster belong is less than that certain percentage, the code units in that cluster can be regarded as project difference code for some projects or a single project, thus forming a multi-level project difference code, further reducing the compilation workload.

[0063] Optionally, in a feasible implementation, known common code can be manually marked in the original code first. After generating each code cluster, code clusters belonging to the platform's common code are selected based on the cluster characteristics of the code clusters containing the known common code, and then marked. Conversely, the remaining code clusters can be marked as project-specific difference codes based on the project to which the code unit belongs.

[0064] It is understandable that in this embodiment, the server can automatically mark the platform's common code and the project's difference code to reduce manual work, or perform a secondary screening based on manual marking to ensure the accuracy of the two types of code recognition.

[0065] In one feasible implementation, the step of dividing the original code into code units includes steps S111 to S113: Step S111: The original code is segmented based on code structure and / or functional attributes to obtain each initial code unit; Step S112: Identify the target unit in each initial code unit; Step S113: The differential variables of the target units in each initial code unit are fuzzed to obtain each code unit.

[0066] It should be noted that, in this embodiment, the original code can be segmented by at least one dimension of code structure and functional attributes to obtain each initial code unit.

[0067] Optionally, for the code structure dimension, compiler front-end tools can be used to parse the source code and generate an abstract syntax tree. Then, code units are formed using specific node types in the syntax tree as dividing boundaries. For functional features, modular information in the original code can be used for segmentation. For example, in Android Soong (.bp file) or Make (.mk file), each module defined by rules such as cc_library, java_library, android_app, etc., can be regarded as a functionally cohesive "code unit".

[0068] For example, target units are identified in each initial code unit, where the differential variables in the target unit can be dynamically obtained during the software startup phase. That is, a target unit refers to a code unit whose differential variables depend on external runtime configuration.

[0069] Optionally, static scanning can be performed on individual code units to find specific function or method call patterns. For example, in C / C++, look for patterns like `open()` and `fread()` used to read files under ` / vendor / etc / `; in Java / Android, look for `SystemProperties.get()`, `Resources.getString()`, etc. Code units containing such calls and whose parameters (such as file paths, property key-value pairs) include project variables are identified as target units.

[0070] Optionally, more complex static program analysis can be performed. Forward data flow analysis and taint propagation are performed starting from known configuration sources (such as read operations from the ` / data / project_config / ` directory). Any code unit whose control flow or data flow is affected by these "configuration source" values ​​can be identified as a target unit.

[0071] In addition, to ensure overall stability, if a target unit's differential variable is depended upon by other code units or affects other code units, that target unit will also be removed.

[0072] For example, the differential variables of the target unit in each initial code unit are fuzzed to obtain each code unit.

[0073] It should be noted that although the target units mentioned above have differential variables, these variables can be retrieved from external files (such as project difference files) during the startup phase. Therefore, to prevent these differential variables from affecting the identification of common and difference code, the differential variables of the target units can be obfuscated. Obfuscation refers to replacing them with a unified, abstract identifier node or text, thereby eliminating negligible differences between code units.

[0074] Understandably, by using the above-mentioned obfuscation process, the common code portion can be maximized as much as possible, thereby improving code reusability.

[0075] Reference Figure 4 This is a flowchart illustrating the first embodiment of the platform software startup method in this application. Contents identical or similar to those in the above embodiments can be referred to the above description and will not be repeated hereafter. The platform software package corresponding to the project in the platform is obtained through the platform software release method as described in any one of claims 1-4; the platform software startup method includes steps S100 to S200: Step S100: Receive the platform software package, write the platform common files in the platform software package to the common partition, and write the project difference files in the platform software package to the difference partition. Step S200: Start the loader, load the platform common files in the common partition and the project difference files in the difference partition, and run the platform software corresponding to the platform package.

[0076] It should be noted that, in this embodiment, the platform software startup method can be used for in-vehicle terminal devices (such as vehicle infotainment systems) on vehicles, and the terminal devices communicate with the server that compiles the code.

[0077] For example, a terminal device can receive a platform software package sent by a server, which is obtained through the platform software release method described in the above embodiments. After receiving the platform software package, the terminal device can flash the platform common files in the platform software package to the system-specific common partition on the terminal device. It can also flash the project difference files in the platform software package to the system-specific difference partition on the terminal device. For example, the terminal device can download a complete update package for its device model (i.e., this project) via a wireless network. This package contains a metadata file that explicitly lists the included images: such as system.img (platform common files) and diff_model_x_cn.img (project difference files). These two files are then flashed to the common partition and the difference partition, respectively.

[0078] For example, the loader is launched to load the platform common files in the common partition and the project difference files in the difference partition in order to run the platform software corresponding to the platform package.

[0079] It should be noted that improvements will be made to the loader at system startup, so that when the software system starts, the loader will not only load the platform common files under the default partition (i.e., the public partition, such as the system and vendor partitions in the Android system scenario), but also the project difference files in the partition.

[0080] In one feasible implementation, the step of starting the loader and loading the platform common files in the common partition and the project difference files in the difference partition includes step S210: Step S210: Start the loader and load the platform common files and project difference files through a phased on-demand loading strategy. The phased on-demand loading strategy includes at least the basic environment initialization phase and the system service startup phase. The required platform common files and project difference files are different in different phases.

[0081] For example, after the loader is started, it will load the various parts of the platform common files and the various parts of the project difference files in stages and on demand, and finally complete the loading of the entire platform common files and project difference files, thereby starting and running the platform software corresponding to the package. For example, refer to Figure 5A This is a schematic diagram of the overall software startup process in this embodiment. Figure 5A As shown, after the loader starts, the first stage is the basic environment initialization stage. During this stage, part A of the platform common files is loaded from the common partition, and part A of the project difference files is loaded from the difference partition. Then, the next stage, the system service startup stage, is started. During this stage, part B of the platform common files is loaded from the common partition, and part B of the project difference files is loaded from the difference partition. In other words, the required parts of the platform common files and project difference files are different in different stages.

[0082] It should be noted that, in practical applications, the method proposed in this embodiment can be applied to different operating system scenarios. To clearly illustrate the implementation process of this case, the Android operating system scenario will be used as an example for explanation: Optionally, the above-mentioned basic environment initialization stage can correspond to the first stage, Selinux Setup, and second stage in the Android boot process. The goal is to establish the most basic operating environment of the device, complete the security policy initialization, and provide necessary differentiated configuration support.

[0083] During the basic environment initialization phase, critical partitions can be mounted, mounting read-only partitions containing platform common files (such as the system partition or the common framework portion of the vendor partition) to specified paths. Differentiated partitions can be mounted: Differentiated partitions containing project difference files (such as newly added diff partitions or extended ODM partitions) can be mounted to specific paths (such as / diff). Device nodes and basic file systems can be established: Device nodes can be initialized, and virtual file systems (such as / proc, / sys) can be prepared. Security policies can be loaded and merged: During SELinux initialization, common security policies can be loaded, and differentiated security policies can be overlaid to build a complete system security environment. Basic differentiated configurations can be applied: Differentiated configurations that must take effect before core system services start can be loaded and applied, such as critical system attribute overriding and kernel module parameters.

[0084] Furthermore, the platform common files loaded during the basic environment initialization phase may include: partition images: image files such as / dev / block / by-name / system (system kernel) and / dev / block / by-name / vendor_common (common hardware abstraction layer framework) are mounted; core executable files: key binary files from / system / bin / , such as init, linker, and toolbox, used to execute basic startup scripts and commands; basic configuration files: mount table configuration files such as / system / etc / fstab, which define the partitions that need to be mounted early on; and common security policies: common SELinux policy files such as plat_sepolicy.cil and plat_file_contexts in the / system / etc / selinux / directory.

[0085] The project diff files loaded during the basic environment initialization phase include: Diffracted partition image: The ` / dev / block / by-name / diff` partition is mounted to the ` / diff` directory; Diffracted security policies: Project-specific SELinux policy files in the ` / diff / etc / selinux / ` directory. During the system's `selinux_setup` phase, after loading common policies, it actively scans and loads policies in this directory to overlay and extend policies, ensuring that services and files within the diffracted partition have the correct security context; Basic attribute overriding file: The ` / diff / etc / prop.early` file. Later in the first-stage init process or after `selinux_setup` is complete, the init process reads this file and uses its attribute values ​​to overwrite or supplement system attributes. These attributes can affect the behavior of subsequent startup phases.

[0086] It should be noted that to implement the loading logic during system startup described above, in the Android operating system scenario, the Fstab and init configurations can be modified. Modifying the Fstab configuration primarily ensures that the project's difference files can be mounted during the boot phase. The specific timing of mounting can be configured differently depending on the boot phase in which the difference logic depends. Modifying the init configuration can be divided into three important sub-stages: first stage, selinuxsetup, and second stage. The mount objects in different stages are adjusted according to the difference module logic. Different dependencies are also loaded in these three sub-stages. For example, the second stage loads the prop files of the difference partition, etc. The specific process will not be elaborated here.

[0087] The core of the system service startup phase lies in the startup and initialization of the system server process. Improvements to the loading logic in this phase primarily ensure that the system service, during initialization, can proactively identify, load, and integrate customized components and configurations from differentiated partitions, thereby transforming a general platform system into a complete system that meets the specific needs of a project.

[0088] Optionally, the platform common files loaded during the system service startup phase may include: system service framework code, which includes common implementations of system service classes; common native libraries, such as service dependencies under / system / lib / or / system / lib64 / ; common configuration files, such as standard configuration files read by each system service from / system / etc / or / vendor / etc / ; and common system service instances: standard service objects instantiated based on common code.

[0089] Optionally, the project differentiation file loaded during the system service startup phase may include: The Differentiated System Service Extension Package (JAR) needs to be loaded early in the systemserver startup process by modifying its class loading path. It can contain: new system services (custom, project-specific system service classes); differentiated resource overlay packages, such as Overlay APK (Android Application Package) files in the ` / diff / overlay / ` directory (differentiated partition). When scanning system packages, these overlay packages can be identified, and their resource IDs can be mapped to the target framework package or application package, enabling seamless replacement of UI, string, and other resources without modifying common code; differentiated pre-installed applications, such as APK files in the ` / diff / app / ` and ` / diff / priv-app / ` directories; and differentiated service configuration files, such as service-specific configuration files in the ` / diff / etc / ` directory, etc., which will not be elaborated upon here.

[0090] Reference Figure 5B This is a schematic diagram of the overall software startup process in the Android system scenario of this application embodiment. After the startup loader is executed, it first enters the first stage basic environment initialization stage. In this stage, the read-only partition where the platform's common files are located (such as the system partition) and the differential partition where the project's differential files are located (such as the diff partition) are mounted, and the corresponding common code part and differential code part are executed to establish the basic running environment; then it enters the SELinux setup security policy setting stage. After loading the common security policy (such as the policy under / system / etc / selinux / ), the differential security policy (such as the policy under / diff / etc / selinux / ) is loaded on top of it to complete the common permission setting and differential permission setting, ensuring the correct security context of services and files in the differential partition; then it enters the second stage. During the system service startup phase, common code execution and partition mounting are performed again. At the same time, differential code is executed and relevant configurations are mounted (such as loading the ` / diff / etc / prop.early` property overriding file) to provide differential support for subsequent service startup. Finally, the systemserver phase is entered, which starts common upper-layer services (such as ActivityManagerService) and pre-installed applications. It also starts differential upper-layer services (such as customized services loaded from ` / diff / framework / `) and differential pre-installed applications (such as APKs under ` / diff / app / `), thereby achieving complete integration and on-demand loading of platform common files and project differential files during the system startup process.

[0091] It should be noted that, in this embodiment, a method for launching platform software obtained by adapting the platform software release method is provided, so that the modified platform software can be correctly installed on the terminal device.

[0092] Reference Figure 6 This is a schematic diagram of the framework of the interaction system of the platform software in this application. The interaction system of the platform software includes: Server 10 is used to obtain the source code of the software related to the target platform. The source code includes the platform common code and the project difference code of at least one project on the target platform. The source code is compiled to obtain the platform common file of the platform common code and the project difference file of the project difference code. Based on the platform common file and the project difference file, the platform software package corresponding to the project is constructed and the platform software package is output to the terminal device. The platform software package is a file in image file format. Terminal device 20 is used to receive the platform software package output by the server, write the platform common files in the platform software package to the common partition, and write the project difference files in the platform software package to the difference partition; start the loader, load the platform common files in the common partition and the project difference files in the difference partition, so as to run the platform software corresponding to the platform software package.

[0093] The interactive system for platform software provided in this application can solve the technical problem of resource waste caused by code compilation during release. Compared with the prior art, the beneficial effects of the interactive system for platform software provided in this application are the same as the beneficial effects of the platform software release method and platform software startup method provided in the above embodiments, and will not be repeated here.

[0094] The following is for reference. Figure 7 It shows a schematic diagram of a structure suitable for implementing an electronic device according to the embodiments of this application. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0095] like Figure 7 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although electronic devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0096] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0097] The electronic device provided in this application, employing the platform software release method described in the above embodiments, can solve the technical problem of resource waste caused by code compilation during release. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the platform software release method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0098] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0100] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the platform software release method in the above embodiments.

[0101] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0102] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0103] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to: Obtain the source code of the software related to the target platform, wherein the source code includes the platform's common code and the project difference code of at least one project on the target platform; The original code is compiled to obtain the platform common files of the platform common code and the project difference files of the project difference code; Based on the platform's common files and project difference files, a platform software package corresponding to the project is built and output. The platform software package is a file in image file format.

[0104] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0106] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0107] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the release method of the aforementioned platform software. This solves the technical problem of resource waste caused by code compilation during release. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the platform software release method provided in the above embodiments, and will not be repeated here.

[0108] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the platform software release method described above.

[0109] The computer program product provided in this application can solve the technical problem of wasted resources during code compilation during release. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the platform software release method provided in the above embodiments, and will not be repeated here.

[0110] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.< / permission>

Claims

1. A method for releasing platform software, characterized in that, The platform software release method includes: Obtain the source code of the software related to the target platform, wherein the source code includes the platform's common code and the project difference code of at least one project on the target platform; The original code is compiled to obtain the platform common file of the platform common code and the project difference file of the project difference code; Based on the platform's common files and the project's difference files, a platform software package corresponding to the project is constructed and output. The platform software package is a file in image file format.

2. The method for releasing platform software as described in claim 1, characterized in that, The steps of compiling the original code to obtain the platform common file of the platform common code and the project difference file of the project difference code include: From the original code, filter out the platform common code belonging to the common partition and the project difference code belonging to the difference partition; The platform common code is compiled into the platform common file, and the project difference code is compiled into the project difference file.

3. The method for releasing platform software as described in claim 2, characterized in that, The step of filtering platform common code belonging to the common partition and project difference code belonging to the difference partition from the original code includes: Based on the identifier parameter of the file directory path where each code segment in the original code is located, the platform common code belonging to the common partition and the project difference code belonging to the difference partition in the original code are identified.

4. The method for releasing platform software as described in claim 3, characterized in that, If the identification parameter matches the target partition parameter of the operating system corresponding to the target platform, the code snippet in the file directory path where the identification parameter is located is used as the platform common code, or as the project difference code.

5. The method for releasing platform software as described in claim 1, characterized in that, After the step of obtaining the source code of the platform-related software, the method includes: The original code is divided into code units; Extract multi-dimensional features from each code unit, wherein the multi-dimensional features include at least two different features of the code unit; Based on the multi-dimensional features of each code unit, clustering and classification are performed on each code unit to obtain each code cluster group; The platform common code and the project difference code are marked in the original code by the respective code clusters.

6. The method for releasing platform software as described in claim 5, characterized in that, The step of dividing the original code into code units includes: The original code is segmented based on its code structure and / or functional attributes to obtain initial code units; Identify the target unit in each of the initial code units; The differential variables of the target units in each initial code unit are fuzzed to obtain each code unit.

7. A method for starting platform software, characterized in that, The platform software package corresponding to the project in the target platform is obtained through the platform software release method described in any one of claims 1-6; The platform software startup method includes: Receive the platform software package, write the platform common files in the platform software package to the common partition, and write the project difference files in the platform software package to the difference partition; The loader is started, loading the platform common files in the common partition and the project difference files in the difference partition to run the platform software corresponding to the platform package.

8. The platform software startup method as described in claim 7, characterized in that, The steps of launching the loader and loading the platform common files in the common partition and the project difference files in the difference partition include: The loading program is started, and the platform common files and project difference files are loaded through a phased on-demand loading strategy. The phased on-demand loading strategy includes at least a basic environment initialization phase and a system service startup phase. The required platform common files and project difference files are different in different phases.

9. An interactive system for platform software, characterized in that, The interactive system of the platform software includes: The server is used to obtain the source code of the software related to the target platform, wherein the source code includes platform common code and project difference code of at least one project on the target platform; the source code is compiled to obtain platform common files of the platform common code and project difference files of the project difference code; based on the platform common files and the project difference files, a platform software package corresponding to the project is constructed, and the platform software package is output to the terminal device, wherein the platform software package is a file in image file format; A terminal device is used to receive a platform software package output by a server, write the platform common files in the platform software package into a common partition, and write the project difference files in the platform software package into a difference partition; start a loader to load the platform common files in the common partition and the project difference files in the difference partition to run the platform software corresponding to the platform software package.

10. An electronic device, characterized in that, The electronic device includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed, it implements the steps of the platform software release method as described in any one of claims 1-6, or the steps of the platform software startup method as described in any one of claims 7-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the steps of the platform software release method as described in any one of claims 1-6, or the steps of the platform software startup method as described in any one of claims 7-8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the platform software release method as described in any one of claims 1-6, or the steps of the platform software startup method as described in any one of claims 7-8.

Images