CN118132119A - Code updating method and device, electronic equipment and storage medium - Google Patents
Code updating method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN118132119A CN118132119A CN202410546464.6A CN202410546464A CN118132119A CN 118132119 A CN118132119 A CN 118132119A CN 202410546464 A CN202410546464 A CN 202410546464A CN 118132119 A CN118132119 A CN 118132119A
- Authority
- CN
- China
- Prior art keywords
- warehouse
- git
- code
- version
- configuration file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 238000011161 development Methods 0.000 claims abstract description 52
- 238000012545 processing Methods 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 6
- 230000015654 memory Effects 0.000 description 6
- 238000010276 construction Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000001172 regenerating effect Effects 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a code updating method and device, electronic equipment and a storage medium, wherein the method comprises the following steps: for each git repository defined in the manifest configuration file of the second version code repository, determining whether a path of the git repository exists in the manifest configuration file of the first version code repository; if the path of the git warehouse does not exist in the list configuration file of the first version code warehouse, adding the git warehouse in the second version code warehouse into the development version of the equipment manufacturer; or if the path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the equipment manufacturer development version, so that a simple and easy-to-maintain code updating scheme can be provided, and updating of system source codes provided by manufacturers is applied to the equipment manufacturer development version.
Description
Technical Field
The present invention relates to the field of computers, and in particular, to a method and apparatus for updating codes, an electronic device, and a storage medium.
Background
AOSP is used as an open source code project of the Android system, and along with continuous iteration of code versions, the development workload of each mobile phone/equipment manufacturer in upgrading AOSP code versions is large and tedious. In order to solve this problem, AOSP has performed reconstruction of multiple code warehouses after Android 8.0, and the key idea is to separate the native AOSP from the vendor to implement the two parts.
In practice, when a manufacturer develops Android equipment, the code of the Android equipment basically follows the design concept of AOSP, and the Android equipment conceptually comprises the following parts:
(1) The native AOSP system part, which is in principle the code pulled in the official AOSP project, is not modified by the vendor and is updated synchronously with the AOSP code update. In practice, however, the manufacturer will make minor changes to this part as an interface to the manufacturer's interaction with the system part.
(2) The AOSP parts of the vendor's system, including the implementation of the HAL layer, and related runtime libraries, pre-set programs and applications, etc.
(3) The kernel part comprises an open-source Linux kernel source code, and is divided into a common part and a manufacturer part according to GKI (universal kernel image) universal kernel design concept, wherein the common part is the universal kernel source code and only comprises kernel construction configuration required by Linux kernel source code and Android; the manufacturer part adds the kernel construction configuration of a plurality of manufacturers, and even the kernel codes of the manufacturers.
(4) The vendor's bottom implementation, which is not part of the Android system, is therefore not in AOSP. This section contains other programs or data related to the device, such as trusted execution environments of various vendors are typically implemented in this section.
When an Android system is integrated by a device manufacturer, system source codes or precompiled images need to be acquired from manufacturers, and the Android system is applied to Android devices after custom development of the device manufacturer. The system source codes of the manufacturer can be provided for a large number of equipment manufacturers, the related hardware composition is very complex, and independent project development is usually carried out for different hardware, so that the provided system source codes can integrate a large number of independent projects into a whole set of system source codes, the directory structure of the codes is complex, and therefore, for the system source codes acquired from the manufacturer, the maintenance of a set of code warehouse in the equipment manufacturers is very complicated; meanwhile, manufacturers can continuously update and iterate the manufacturer system source codes provided by the manufacturers, so that when equipment manufacturers need to synchronize new versions of manufacturer system source codes, the problems of multiple update projects and difficult maintenance can occur.
Therefore, how to provide a simple and easy-to-maintain code updating scheme to implement the application of updating the system source code provided by the manufacturer to the development version of the equipment manufacturer is a technical problem to be solved.
Disclosure of Invention
Aiming at the technical problems existing in the prior art, the embodiment of the application provides a code updating method and device, electronic equipment and a storage medium.
In a first aspect, an embodiment of the present application provides a code updating method, including:
For each git repository defined in the manifest configuration file of the second version code repository, determining whether a path of the git repository exists in the manifest configuration file of the first version code repository;
If the path of the git warehouse does not exist in the list configuration file of the first version code warehouse, adding the git warehouse in the second version code warehouse into the development version of the equipment manufacturer; or alternatively
If the path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the development version of the equipment manufacturer, wherein the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the first version code warehouse and the second version code warehouse are respectively generated based on the vendor system source codes of the first version and the vendor system source codes of the second version, the second version is higher than the first version, and the development version of the equipment manufacturer is obtained based on the first version code warehouse.
In a second aspect, an embodiment of the present application further provides a code updating apparatus, including:
A judging unit, configured to judge, for each git repository defined in the manifest configuration file of the second version code repository, whether a path of the git repository exists in the manifest configuration file of the first version code repository;
The processing unit is used for adding the git warehouse in the second version code warehouse to the development version of the equipment manufacturer if the path of the git warehouse does not exist in the list configuration file of the first version code warehouse; or alternatively
If the path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the development version of the equipment manufacturer, wherein the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the first version code warehouse and the second version code warehouse are respectively generated based on the vendor system source codes of the first version and the vendor system source codes of the second version, the second version is higher than the first version, and the development version of the equipment manufacturer is obtained based on the first version code warehouse.
In a third aspect, embodiments of the present application also provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the code update method according to the first aspect.
In a fourth aspect, an embodiment of the present application further provides an electronic device, including: a processor, a storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating over a bus when the electronic device is running, the processor executing the machine-readable instructions to perform the steps of the code update method as described in the first aspect.
That is, on the basis that the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the updating scheme of the code is used for updating the source code of the manufacturer system to the version of the equipment manufacturer obtained based on the first version code warehouse, and the whole scheme is simple and easy to maintain.
Drawings
FIG. 1 is a flowchart of an embodiment of a code update method according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a directory structure in a system source code directory other than the repo directory and the git directory;
FIG. 3 is a schematic diagram illustrating an embodiment of a code updating apparatus according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application, and it should be understood that the drawings in the present application are for the purpose of illustration and description only and are not intended to limit the scope of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. A flowchart, as used in this disclosure, illustrates operations implemented according to some embodiments of the present application. It should be understood that the operations of the flow diagrams may be implemented out of order and that steps without logical context may be performed in reverse order or concurrently. Moreover, one or more other operations may be added to or removed from the flow diagrams by those skilled in the art under the direction of the present disclosure.
In addition, the described embodiments are only some, but not all, embodiments of the application. The components of the embodiments of the present application generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the application, as presented in the figures, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by a person skilled in the art without making any inventive effort, are intended to be within the scope of the present application.
It should be noted that the term "comprising" will be used in embodiments of the application to indicate the presence of the features stated hereafter, but not to exclude the addition of other features.
Referring to fig. 1, a flow chart of a code updating method according to an embodiment of the present application is shown, where the code updating method includes:
S10, judging whether a path of each git warehouse exists in the list configuration file of the first version code warehouse or not for each git warehouse defined in the list configuration file of the second version code warehouse;
s11, if the path of the git warehouse does not exist in the list configuration file of the first version code warehouse, adding the git warehouse in the second version code warehouse into the development version of the equipment manufacturer; or alternatively
S12, if a path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the equipment manufacturer development version, wherein the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the first version code warehouse and the second version code warehouse are respectively generated based on a manufacturer system source code of the first version and a manufacturer system source code of the second version, the second version is higher than the first version, and the equipment manufacturer development version is obtained based on the first version code warehouse.
In this embodiment, it should be noted that, the first version code repository and the second version code repository are generated based on the vendor system source code of the first version and the vendor system source code of the second version, and the first version code repository and the second version code repository are both repo repositories, and each inventory configuration file has a list configuration file, and each list configuration file defines all the git repositories managed/contained in the corresponding version code repository, that is, paths of at least one git repository are contained in the list configuration file. Typically, during development and production of a device, after a device manufacturer creates a version code repository locally, some customized development will be performed, and the development content will modify the code and data in the version code repository, i.e. the device manufacturer development version is a customized development version of the device manufacturer based on the first version code repository. For each git repository defined in the manifest configuration file of the second version code repository, if the path of the git repository does not exist in the manifest configuration file of the first version code repository, the manifest configuration file corresponding to the equipment manufacturer development version may be updated in addition to adding the git repository in the second version code repository to the equipment manufacturer development version. In addition, in step S12, before calculating the difference, it is required to ensure that the git repository in the second version code repository and the git repository in the first version code repository are both in a clean state, and if either one of them is not in a clean state, it may be manually processed to be clean. In calculating the difference, the difference of the binary files contained in the two needs to be counted. In addition, if the git repository in the second version code repository is the same as the git repository in the first version code repository (i.e., there is no difference), then the patch file may not be applied to the git repository in the device manufacturer development version. In step S12, the patch file may be stored in a directory for storing patches.
According to the code updating method provided by the embodiment of the application, on the basis that the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, updating of manufacturer system source codes is applied to equipment manufacturer versions obtained based on the first version code warehouse through the code updating scheme, and the whole scheme is simple and easy to maintain.
On the basis of the foregoing method embodiment, the method may further include:
Recording the git warehouse of the successfully applied patch file into a first catalogue, or storing the rej file corresponding to the git warehouse which generates conflict in the process of applying the patch file into a second catalogue;
Wherein before the patch file is generated according to the difference and applied to the git warehouse in the development version of the equipment manufacturer, the method further comprises the following steps:
Judging whether the first catalog is recorded with the git warehouse or not;
the generating a patch file according to the difference, and applying the patch file to the git repository in the development version of the device manufacturer may include:
When the git warehouse is not recorded in the first catalog, a patch file is generated according to the difference, and the patch file is applied to the git warehouse in the development version of the equipment manufacturer.
In this embodiment, it should be noted that a first directory and a second directory may be created in advance, where a git repository for a patch file to be successfully applied and a git repository that does not need to be updated (i.e., the git repository in the second version code repository is the same as the git repository in the first version code repository) may be recorded in the first directory, specifically, a path of the git repository may be recorded in the first directory, for example, a path of the git repository is recorded in a certain file, and the file is put into the first directory; the second directory may store the.rej file generated at the time of the conflict (if the conflict occurs during application of the git repository, the conflict portion will be written into the corresponding.rej file). For each git warehouse defined in the list configuration file of the second version code warehouse, whether the git warehouse is recorded in the first catalog or not can be judged first, if the git warehouse is recorded in the first catalog, the git warehouse is skipped, and the next git warehouse defined in the list configuration file of the second version code warehouse is processed; if the git repository is not recorded in the first directory, the git repository may be processed according to the processing logic in fig. 1, and the first directory or the second directory may be updated according to the processing result of the git repository (i.e. the git repository of the patch file is successfully applied or there is no difference so that the git repository which does not need to be updated is saved in the first directory and used for identifying that the git repository has been successfully updated into the manufacturer version of the equipment, or the. Rej file generated by the conflict in the process of applying the patch file is saved in the second directory), so that when an error occurs in the whole set of system code updating process and is corrected, the git repository of the patch file which has been successfully applied does not need to be repeatedly executed when the system code updating process is performed again.
On the basis of the foregoing method embodiment, the method may further include:
and recording the error git warehouse in the patch file application process into a log.
On the basis of the foregoing method embodiment, the method may further include:
for each git warehouse which is defined in the inventory configuration file of the first version code warehouse and undefined in the inventory configuration file of the second version code warehouse, judging whether a code submission record of the git warehouse exists in the development version of the equipment manufacturer;
If the code submitting record of the git warehouse does not exist, deleting the git warehouse in the development version of the equipment manufacturer, and updating a list configuration file corresponding to the development version of the equipment manufacturer; or alternatively
If the code submission record of the git warehouse exists, the git warehouse is recorded into a log.
In this embodiment, after the version code of the development of the whole equipment manufacturer is updated, the processing of the error and conflict git warehouse based on the log and the second catalog is required, which usually involves customizing the developed code of the equipment manufacturer and requires manual processing by corresponding developer. After the process is completed, the process shown in fig. 1 needs to be performed again until all updates are successfully applied to the device manufacturer development version.
Thus, the patch from the first version code warehouse to the second version code warehouse is generated and applied to the development version of the equipment manufacturer, so that the development code of the equipment manufacturer is updated, and the updating and updating of the unified system code warehouse are completed.
It should be noted that, since the system source code provided by the vendor often includes a plurality of portions, each portion is composed of one of the following five types of codes:
(1) A git warehouse;
(2) A plurality of git warehouses managed by repo warehouses;
(3) A plurality of git warehouses managed by the plurality repo warehouses;
(4) Files managed by a git warehouse and a repo warehouse are not available;
(5) Mixing together in any of the above ways.
The whole set of system source codes provided by manufacturers consists of a large number of git warehouses managed by a plurality of repo warehouses, a large number of git warehouses managed by non-repo warehouses and some unmanaged files. Thus, for system source code obtained from a vendor, maintaining a set of code repositories inside the device manufacturer is very cumbersome and makes it difficult to make compatibility and iterative development of historical code repositories.
In order to solve the above problem, on the basis of the foregoing method embodiment, before the determining whether the path of the git repository exists in the manifest configuration file of the first version code repository, the method may further include:
generating a first version code repository and a second version code repository;
wherein the generating of any one of the first version code repository and the second version code repository may include:
Combining system source codes acquired from manufacturers according to a directory structure of the traditional Android system source codes to obtain a system source code directory, wherein a directory for storing manufacturer bottom implementation codes in the system source codes is newly added in the system source code directory;
In this embodiment, it should be noted that the system source code obtained from the manufacturer may be system source code or a precompiled system image. In order to integrate all codes into one repo warehouse for management, after the equipment manufacturer obtains the system source codes from the manufacturer, the system source codes need to be combined according to the directory structure of the traditional Android system source codes to generate a unified system source code directory. It should be noted that, the portion of the system source code that does not belong to the Android system needs to be placed in a new directory, where the new directory is a new directory in the directory structure of the Android system source code, for example, a directory that is identical to the system directory, kernel directory, vendor directory, etc. in the Android system source code may be newly added as the new directory.
Generating a list configuration file based on a system source code catalog, wherein the list configuration file comprises paths of a plurality of git warehouses;
In this embodiment, it should be noted that, each repo repository corresponds to a list configuration file (i.e. a manifest file), where all the git repositories managed by the repo repository are defined in the list configuration file, in order to enable the whole set of system source codes to follow the goal managed by one repo repository, after generating the unified system source code directory, all the paths of the git repositories need to be listed based on the system source code directory, and a list configuration file containing all the paths of the git repositories needs to be generated. The principle that the manifest configuration file needs to follow is that there is no git nesting and that all git repositories can cover the whole set of system source codes.
A code repository is generated based on the manifest configuration file, wherein the code repository is one repo repository, and repo repository manages the plurality of git repositories.
In this embodiment, it should be noted that, after the manifest configuration file is generated, in order to align all the git repositories defined in the manifest configuration file, each git repository needs to be reinitialized, and finally a repo repository for managing multiple git repositories is generated.
In this embodiment, the system source codes provided by the manufacturer can be integrated to generate a unified code warehouse, the code warehouse is a repo warehouse, the repo warehouse manages a plurality of git warehouses, and the directory structure is relatively standard, so that after the equipment manufacturer performs customized development based on the code warehouse, and constructs the own system source code warehouse, forward compatibility and iterative development can be conveniently performed on the version of the code warehouse.
On the basis of the foregoing method embodiment, the merging the system source codes obtained from the manufacturer according to the directory structure of the conventional Android system source codes to obtain a system source code directory may include:
placing the kernel catalogue of the manufacturer in the system source code into the AOSP original kernel catalogue;
placing vendor catalog of vendor in system source code into AOSP original vendor catalog;
And placing other codes of the manufacturer in the system source code into the newly added catalog in the AOSP original code catalog, wherein the codes of the manufacturer in the system source code comprise codes in the kernel catalog of the manufacturer, codes in the vendor catalog and other codes.
In this embodiment, the system source code obtained from the manufacturer includes AOSP native system source codes and the manufacturer source codes in composition, and when the source codes are combined, the manufacturer source codes need to be combined into the AOSP native system source code directory. Specifically, the corresponding portions of the vendor's source code may be incorporated into the corresponding catalog in the AOSP native system source code catalog. For example, if vendor's source code contains a vendor part and a kernel part, the vendor part may be placed in a vendor directory of AOSP native system source codes, and the kernel part may be placed in a kernel directory of AOSP native system source codes; and the other code parts except the vendor part and the kernel part in the source code of the manufacturer are not corresponding to the catalog in the system source code catalog of AOSP, and the other code parts can be put into the newly added catalog in the system source code catalog of AOSP.
On the basis of the foregoing method embodiment, the generating a manifest configuration file based on the system source code directory may include:
Merging the list configuration files of all repo warehouses in the system source code catalog to obtain a new list configuration file, wherein the new list configuration file comprises the relative paths of a plurality of git warehouses;
In this embodiment, it should be noted that, when merging the manifest configuration files of the repo repository, it may be checked whether the repo repository uses a single manifest file or a file formed by merging multiple manifest files, if a single manifest file is used, the manifest file is directly taken, otherwise, if a file formed by merging multiple manifest files is used, the manifest configuration file (such as a snap_combined_manifest file) of the repo repository, which is formed by merging repo, is taken. After each repo warehouse obtains the manifest configuration file after the management.xml file or repo combination in the above manner, file traversal can be performed, the paths of the git warehouses in each file are combined, and the management.xml file is regenerated based on the paths of the git warehouses after combination and is used as the management file of the new whole system source code. The manifest configuration file combined by repo and the manifest xml file may contain the relative path of the git repository, which refers to the relative path of the git repository to the root directory of the corresponding repo repository. When combining the manual xml file and the manifest configuration file after being combined by repo, the relative path of the git warehouse managed by the repo warehouse needs to be optionally corrected (may be corrected or not corrected) according to the combined catalog of the repo warehouse, for example, a git warehouse is marked as gitA in a AOSP native system source code catalog, the relative path of gitA in the manifest configuration file is marked as gitA, a repo warehouse (marked as repoM, repoM manages 1 git warehouse, marked as gitM1 in the source code of the manufacturer, and the relative path of gitM in the manifest configuration file is marked as gitM 1) is combined into gitA, and when performing manifest configuration file combination, the relative address of gitM1 needs to be corrected as gitA/repoM/gitM; for example, if a git repository is recorded as gitB in the system source code directory of AOSP native, the relative path of gitB in the manifest configuration file is gitB, and a repo repository is recorded as repoN in the source code of vendor (repoN manages 1 git repository, gitN1 in the git repository, gitN1 in the relative path of gitN1 in the manifest configuration file) is merged and then is in the same directory level as gitB, then when the manifest configuration file is merged, the relative address of gitN1 is gitN1 without modification.
Note that, the manifest configuration file of the repo repository of the system source code obtained from the manufacturer may further include an address of each git repository (i.e., a storage address of the git repository at the manufacturer server), and when the manifest configuration file is combined, the address needs to be corrected to a storage address of a local machine of the device manufacturer (for example, may be corrected to a relative path of the corrected git repository).
And then, regenerating a manifest configuration file of the new whole system source code based on the relative path/storage address of the combined git warehouse.
Traversing the relative path of each git warehouse in the new list configuration file, checking whether the relative path exists in the system source code catalog, if so, reserving the relative path, otherwise, deleting the relative path in the new list configuration file;
in this embodiment, it should be noted that, for a new inventory configuration file of the entire system source code, it is necessary to traverse the git warehouse in the inventory configuration file and check whether the relative path of each git warehouse exists, and if not, it is necessary to delete the git warehouse in the inventory configuration file of the new entire system source code.
Traversing each git warehouse in the system source code catalog, checking whether the information of the git warehouse exists in the new list configuration file, if so, reserving the information of the git warehouse in the new list configuration file, otherwise, adding the relative path of the git warehouse in the new list configuration file;
In this embodiment, it should be noted that, it is necessary to traverse the root directory of the new system source code, search out all the git warehouses, and find out whether the git warehouses exist in the manifest configuration file of the new system source code, if not, it is necessary to add the git warehouses to the manifest configuration file of the new system source code.
Codes without repo warehouse and git warehouse management in the system source code catalog are generated into at least one git warehouse according to the rule of the git warehouse division of repo warehouse, and the relative path of the at least one git warehouse is added into a new list configuration file.
In this embodiment, it should be noted that, for codes provided by the vendors without the git repository or repo repository, the optimal (minimum number of sets) git repository needs to be generated according to the rule of the git repository division of the repo repository, and added to the manifest configuration file of the new system source code.
On the basis of the foregoing method embodiment, the generating at least one git repository according to the rule of git repository division of repo repository from the codes managed by the repo repository and the git repository in the system source code directory may include:
Acquiring relative paths of all other directories and files (referred to as relative paths of relative repo warehouse root directories) except for a repo directory and a git directory in a system source code directory, and storing the relative paths of all other directories and files into a first set all_files_set;
Acquiring the relative paths of all the git warehouses in the new list configuration file, and storing the relative paths of all the git warehouses, the relative paths of all the other directories and files except the repo directory and the git directory contained under the relative paths, and all the parent paths of the relative paths into a second set of management_files_set (note that the duplicate needs to be removed, and ensure that the items in the management_files_set set are unique);
Calculating the complement of the second set of management_files_set in the first set of all_files_set to obtain a third set unmanaged _files_set;
Traversing each relative path in the third set unmanaged _files_set, starting from the relative path, traversing the relative path and each level of parent path of the relative path in turn until a relative path belonging to the second set of management_files_set is found, and adding the next level of relative path of the traversed relative path belonging to the second set of management_files_set into the fourth set unmanaged _git_ projects;
Items in the fourth set unmanaged _git_ projects are added to the new manifest configuration file.
The process in the present embodiment is described below with specific examples.
Assuming that the portions of the system source code directory other than the repo directory and the git directory are shown in FIG. 2, the repo root directory of the repo repository shown in FIG. 2 contains P folders, the P folders contain 1 git repository (denoted as P1) and 1 file (denoted as P2), the P1 contains 2 files, the P1 contains 2 git repositories respectively denoted as P11 and P12, the P2 contains 2 git repositories respectively denoted as P21 and P22, the P21 contains one folder (denoted as P211), the P22 is vendor source code, and the regenerated manifest configuration file contains { P/P1, P/P2/P21}. all_files_set={P,P/P1,P/P1/P11,P/P1/P12,P/P2,P/P2/P21,P/P2/P21/P211,P/P2/P22},managed_files_set={P,P/P1,P/P1/P11,P/P1/P12,P/P2,P/P2/P21,P/P2/P21/P211},unmanaged_git_projects=all_files_set-managed_files_set={P/P2/P22}, since the upper directory of P/P2/P22 is that P/P2 belongs to the managed_files_set and P/P2/P22 does not belong to the managed_files_set, P/P2/P22 needs to be added into unmanaged _git_ projects.
On the basis of the foregoing method embodiment, the method may further include:
The relative paths of the git repositories nested into the other git repositories are cleared in the new manifest configuration file.
In this embodiment, it should be noted that, in the system source code provided by the vendor, the problem of the git repository nesting may exist due to the non-specification or the code combining multiple parts. For such problems, it is necessary to keep one maximum git repository in the manifest configuration file for the new system source code and delete the remaining nested git repositories.
On the basis of the foregoing method embodiment, the generating a code repository based on the manifest configuration file may include:
Deleting all the repo catalogues and the git catalogues in the system source code catalogues;
Traversing the relative path of each git warehouse in the new list configuration file, regenerating the git catalog of the git warehouse based on the relative path, adding the code of the git warehouse into the git warehouse, and submitting.
In this embodiment, it should be noted that, in order to align all the git repositories defined in the manifest configuration file of the new system source code, each git repository needs to be reinitialized, which specifically includes the following steps:
(1) Removing the non-uniform code management structure after downloading the code splice from the manufacturer, namely deleting all the repo and the git catalogues in the source code of the new system;
(2) Traversing all the git warehouses defined in the list configuration file of the new system source code, entering the relative path of each git warehouse, reinitializing the git project, creating branches, adding and submitting all the code files (all the code files need to be forcedly added and submitted).
So far, a unified system source code repository has been created, and it is necessary to verify whether the repository is available. Specifically, repo tools can be used for pulling codes of the warehouse locally, whether the pulled codes are consistent with the codes in the system source code warehouse or not is verified, if so, the system source code warehouse is successfully created, and otherwise, the problem in the creation process is indicated.
Referring to fig. 3, a schematic structural diagram of a code updating apparatus according to an embodiment of the present application is shown, where the apparatus includes:
A judging unit 30, configured to judge, for each git repository defined in the manifest configuration file of the second version code repository, whether a path of the git repository exists in the manifest configuration file of the first version code repository;
a processing unit 31, configured to add the git repository in the second version code repository to the equipment manufacturer development version if the path of the git repository does not exist in the manifest configuration file of the first version code repository; or alternatively
If the path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the development version of the equipment manufacturer, wherein the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the first version code warehouse and the second version code warehouse are respectively generated based on the vendor system source codes of the first version and the vendor system source codes of the second version, the second version is higher than the first version, and the development version of the equipment manufacturer is obtained based on the first version code warehouse.
According to the code updating device provided by the embodiment of the application, on the basis that the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the updating scheme is used for updating the source codes of the manufacturer system to the equipment manufacturer version obtained based on the first version code warehouse, and the whole scheme is simple and easy to maintain.
The implementation process of the code updating device provided by the embodiment of the application is consistent with the code updating method provided by the embodiment of the application, and the achieved effect is the same as the code updating method provided by the embodiment of the application, and the details are not repeated here.
As shown in fig. 4, an electronic device provided in an embodiment of the present application includes: a processor 40, a memory 41 and a bus 42, said memory 41 storing machine readable instructions executable by said processor 40, said processor 40 and said memory 41 communicating via the bus 42 when the electronic device is running, said processor 40 executing said machine readable instructions to perform the steps of the code update method as described above.
Specifically, the above-described memory 41 and the processor 40 can be general-purpose memories and processors, and are not particularly limited herein, and the above-described code updating method can be performed when the processor 40 runs a computer program stored in the memory 41.
Corresponding to the above code updating method, the embodiment of the application also provides a computer readable storage medium, on which a computer program is stored, which when being executed by a processor, performs the steps of the above code updating method.
The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily appreciate variations or alternatives within the scope of the present application. Therefore, the protection scope of the application is subject to the protection scope of the claims.
Claims (10)
1. A code updating method, comprising:
For each git repository defined in the manifest configuration file of the second version code repository, determining whether a path of the git repository exists in the manifest configuration file of the first version code repository;
If the path of the git warehouse does not exist in the list configuration file of the first version code warehouse, adding the git warehouse in the second version code warehouse into the development version of the equipment manufacturer; or alternatively
If the path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the development version of the equipment manufacturer, wherein the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the first version code warehouse and the second version code warehouse are respectively generated based on the vendor system source codes of the first version and the vendor system source codes of the second version, the second version is higher than the first version, and the development version of the equipment manufacturer is obtained based on the first version code warehouse.
2. The method as recited in claim 1, further comprising:
Recording the git warehouse of the successfully applied patch file into a first catalogue, or storing the rej file corresponding to the git warehouse which generates conflict in the process of applying the patch file into a second catalogue;
Wherein before the patch file is generated according to the difference and applied to the git warehouse in the development version of the equipment manufacturer, the method further comprises:
Judging whether the first catalog is recorded with the git warehouse or not;
the generating a patch file according to the difference, and applying the patch file to the git warehouse in the development version of the equipment manufacturer comprises the following steps:
When the git warehouse is not recorded in the first catalog, a patch file is generated according to the difference, and the patch file is applied to the git warehouse in the development version of the equipment manufacturer.
3. The method as recited in claim 2, further comprising:
and recording the error git warehouse in the patch file application process into a log.
4. A method as claimed in any one of claims 1 to 3, further comprising:
for each git warehouse which is defined in the inventory configuration file of the first version code warehouse and undefined in the inventory configuration file of the second version code warehouse, judging whether a code submission record of the git warehouse exists in the development version of the equipment manufacturer;
If the code submitting record of the git warehouse does not exist, deleting the git warehouse in the development version of the equipment manufacturer, and updating a list configuration file corresponding to the development version of the equipment manufacturer; or alternatively
If the code submission record of the git warehouse exists, the git warehouse is recorded into a log.
5. The method of claim 1, further comprising, prior to said determining whether a path for the git repository exists in the manifest configuration file for the first version code repository:
generating a first version code repository and a second version code repository;
the generation process of any one code warehouse of the first version code warehouse and the second version code warehouse comprises the following steps:
Combining system source codes acquired from manufacturers according to a directory structure of the traditional Android system source codes to obtain a system source code directory, wherein a directory for storing manufacturer bottom implementation codes in the system source codes is newly added in the system source code directory;
Generating a list configuration file based on a system source code catalog, wherein the list configuration file comprises paths of a plurality of git warehouses;
a code repository is generated based on the manifest configuration file, wherein the code repository is one repo repository, and repo repository manages the plurality of git repositories.
6. The method of claim 5, wherein the merging the system source codes obtained from the manufacturer according to the directory structure of the conventional Android system source codes to obtain the system source code directory comprises:
placing the kernel catalogue of the manufacturer in the system source code into the AOSP original kernel catalogue;
placing vendor catalog of vendor in system source code into AOSP original vendor catalog;
And placing other codes of the manufacturer in the system source code into the newly added catalog in the AOSP original code catalog, wherein the codes of the manufacturer in the system source code comprise codes in the kernel catalog of the manufacturer, codes in the vendor catalog and other codes.
7. The method of claim 5 or 6, wherein generating a manifest configuration file based on the system source code directory comprises:
Merging the list configuration files of all repo warehouses in the system source code catalog to obtain a new list configuration file, wherein the new list configuration file comprises the relative paths of a plurality of git warehouses;
Traversing the relative path of each git warehouse in the new list configuration file, checking whether the relative path exists in the system source code catalog, if so, reserving the relative path, otherwise, deleting the relative path in the new list configuration file;
Traversing each git warehouse in the system source code catalog, checking whether the information of the git warehouse exists in the new list configuration file, if so, reserving the information of the git warehouse in the new list configuration file, otherwise, adding the relative path of the git warehouse in the new list configuration file;
codes without repo warehouse and git warehouse management in the system source code catalog are generated into at least one git warehouse according to the rule of the git warehouse division of repo warehouse, and the relative path of the at least one git warehouse is added into a new list configuration file.
8. A code updating apparatus, comprising:
A judging unit, configured to judge, for each git repository defined in the manifest configuration file of the second version code repository, whether a path of the git repository exists in the manifest configuration file of the first version code repository;
The processing unit is used for adding the git warehouse in the second version code warehouse to the development version of the equipment manufacturer if the path of the git warehouse does not exist in the list configuration file of the first version code warehouse; or alternatively
If the path of the git warehouse exists in the list configuration file of the first version code warehouse, calculating the difference between the git warehouse in the second version code warehouse and the git warehouse in the first version code warehouse, generating a patch file according to the difference, and applying the patch file to the git warehouse in the development version of the equipment manufacturer, wherein the first version code warehouse and the second version code warehouse are repo warehouses for managing a plurality of git warehouses, the first version code warehouse and the second version code warehouse are respectively generated based on the vendor system source codes of the first version and the vendor system source codes of the second version, the second version is higher than the first version, and the development version of the equipment manufacturer is obtained based on the first version code warehouse.
9. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a computer program which, when executed by a processor, performs the steps of the code update method according to any of claims 1 to 7.
10. An electronic device, comprising: a processor, a storage medium and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating over the bus when the electronic device is running, the processor executing the machine-readable instructions to perform the steps of the code update method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410546464.6A CN118132119A (en) | 2024-05-06 | 2024-05-06 | Code updating method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410546464.6A CN118132119A (en) | 2024-05-06 | 2024-05-06 | Code updating method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118132119A true CN118132119A (en) | 2024-06-04 |
Family
ID=91248000
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410546464.6A Pending CN118132119A (en) | 2024-05-06 | 2024-05-06 | Code updating method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118132119A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113010193A (en) * | 2019-12-19 | 2021-06-22 | 中兴通讯股份有限公司 | Baseline upgrading method and system and computer readable storage medium |
| CN113821249A (en) * | 2021-09-18 | 2021-12-21 | 挂号网（杭州）科技有限公司 | Project development configuration method and device, electronic equipment and readable storage medium |
| US20220206788A1 (en) * | 2020-12-30 | 2022-06-30 | Realtek Semiconductor Corporation | Version control method for program project and associated electric device |
| CN114911471A (en) * | 2022-04-02 | 2022-08-16 | 苏州万店掌网络科技有限公司 | Software engineering construction method, system and storage medium |
| CN115328524A (en) * | 2021-05-11 | 2022-11-11 | 中兴通讯股份有限公司 | Patch merging method and device, computer equipment and storage medium |
| CN117311782A (en) * | 2023-09-07 | 2023-12-29 | 茂佳科技(广东)有限公司 | Dynamic system branch pulling method and device, server and storage medium |
-
2024
- 2024-05-06 CN CN202410546464.6A patent/CN118132119A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113010193A (en) * | 2019-12-19 | 2021-06-22 | 中兴通讯股份有限公司 | Baseline upgrading method and system and computer readable storage medium |
| US20220206788A1 (en) * | 2020-12-30 | 2022-06-30 | Realtek Semiconductor Corporation | Version control method for program project and associated electric device |
| CN115328524A (en) * | 2021-05-11 | 2022-11-11 | 中兴通讯股份有限公司 | Patch merging method and device, computer equipment and storage medium |
| CN113821249A (en) * | 2021-09-18 | 2021-12-21 | 挂号网（杭州）科技有限公司 | Project development configuration method and device, electronic equipment and readable storage medium |
| CN114911471A (en) * | 2022-04-02 | 2022-08-16 | 苏州万店掌网络科技有限公司 | Software engineering construction method, system and storage medium |
| CN117311782A (en) * | 2023-09-07 | 2023-12-29 | 茂佳科技(广东)有限公司 | Dynamic system branch pulling method and device, server and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| WWWLYJ123321: "repo manifest文件", pages 1 - 4, Retrieved from the Internet <URL:https://blog.csdn.net/wwwlyj123321/article/details/122361538> * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106227579B (en) | Docker container construction method and Docker management console | |
| Davison et al. | Sumatra: a toolkit for reproducible research | |
| US8055632B2 (en) | Design of self-adapting meta descriptors based upon real use scenarios and experiences | |
| US10380085B2 (en) | Method, apparatus and computer program for migrating records in a database from a source database schema to a target database schema | |
| CN110442371B (en) | Method, device and medium for releasing codes and computer equipment | |
| US9542173B2 (en) | Dependency handling for software extensions | |
| CN108920691B (en) | Front-end static resource management method and device, computer equipment and storage medium | |
| CN111782339A (en) | Container creation method and device, electronic equipment and storage medium | |
| WO2019041891A1 (en) | Method and device for generating upgrade package | |
| CN108694049B (en) | Method and equipment for updating software | |
| CN111932207A (en) | Project data processing method and device, computer equipment and storage medium | |
| CN114879976A (en) | Version environment deployment method and device and electronic equipment | |
| CN112612833B (en) | Rule package updating method, device, equipment and storage medium | |
| CN112000367B (en) | Binary library file version compatibility identification method and device | |
| US9244706B2 (en) | Command line shell command generation based on schema | |
| US11194561B1 (en) | System and method for generating and recommending desired state of virtualization software | |
| US9389851B1 (en) | System and method for providing consistency between software library repositories | |
| CN118132119A (en) | Code updating method and device, electronic equipment and storage medium | |
| CN111949303A (en) | Upgrade package processing method and device, electronic equipment and storage medium | |
| CN111596935A (en) | Script packing method and device, electronic equipment and storage medium | |
| CN118132139A (en) | Code integration method and device | |
| CN111324373A (en) | Method and device for uploading multiple project files to code warehouse and computing equipment | |
| CN115794214A (en) | Application module metadata management method, device, storage medium and device | |
| Turnbull | The Docker Book | |
| CN114564228A (en) | Application program updating method and device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |