Method and device for determining dependency relationship, electronic equipment and storage medium

Abstract

The invention provides a method and a device for determining a dependency relationship, electronic equipment and a storage medium. The method comprises the following steps: acquiring related parameters of a target module in an open source project; determining a configuration file of the compiling target module from a folder of the open source project based on the related parameters; analyzing the configuration file of the target module to obtain an identity label of a dependent module of the target module; based on the identity label of the dependency module, scanning a folder of the open source project, and determining a path of the dependency module; and displaying the identity label of the dependent module and the path of the dependent module. According to the method, the dependency module on which the target module depends and the path of the dependency module can be automatically analyzed, determined and displayed, research and development personnel are helped to know and master the AOSP, consumed time is shortened, cost is reduced, and development efficiency and product quality are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of open source projects, and more particularly, to a method, device, electronic equipment and storage medium for determining dependency in the field of open source projects. BACKGROUND

[0002] With the rapid development of automobile intelligence and electrification, the controller basic hardware and functions inside the automobile are becoming more and more powerful. As the hardware and ecology directly contacted with the driver and passengers, the intelligent cockpit is more easily perceived by consumers, and the technical threshold is relatively low, which is the focus of differentiation layout of major OEMs at this stage. The intelligent cockpit focuses on human-computer interaction, and the core is to make the car understand people better. New additions include larger center screens, center entertainment systems, liquid crystal instrument panels, head-up display systems, etc., which can realize multi-modal interaction, map navigation services, rich car entertainment content and life service information, etc.

[0003] The current vehicle system in the intelligent cockpit is mainly based on vehicle-grade Linux, QNX and Android. Among the emerging manufacturers, the Linux / Android+QNX multi-system architecture is mainly used. Overall, the system used in the entire vehicle industry is basically developed and upgraded based on the Android system as a blueprint. For developing vehicle system Android-related middleware, App (application), etc., it is necessary to locally build an AOSP, i.e., an Android open source project development environment. Subsequently, whether it is a new project or modification of an existing project, code compilation needs to be performed in this environment.

[0004] AOSP, as a core component of the Android system, has an extremely large code base. This feature, while bringing rich functionality and high customization, also presents challenges to developers. Due to the large amount of code, developers face high operational complexity and long time consumption when customizing systems, developing functions, or troubleshooting errors. This not only increases development costs but also may increase the probability of human error, affecting development efficiency and product quality. SUMMARY

[0005] The present application provides a method, device, electronic equipment and storage medium for determining dependency, which can automatically analyze and determine the dependent modules and paths of the dependent modules of the target module and display them, helping developers understand and master AOSP, reducing time consumption, reducing costs, and improving development efficiency and product quality.

[0006] In a first aspect, a method for determining a dependency relationship is provided. The method comprises: obtaining a related parameter of a target module in an open source project; determining a configuration file for compiling the target module from a folder of the open source project based on the related parameter; analyzing the configuration file of the target module to obtain an identity of a dependent module of the target module; scanning the folder of the open source project based on the identity of the dependent module to determine a path of the dependent module; and displaying the identity of the dependent module and the path of the dependent module.

[0007] In the above technical solution, after the software tool obtains the related parameter of the target module, the configuration file for compiling the target module can be directly determined from the folder of the open source project based on the related parameter. Then, based on the identity of the dependent module obtained from the configuration file, the folder of the open source project is scanned to automatically determine the path of the dependent module of the target module and display the path. The developer can quickly and accurately find the dependent module based on the displayed name and path of the dependent module, implement the compilation of the target module, and no longer need to manually determine the dependent module from the huge and complex folder of the open source project based on experience, thereby reducing the operation complexity of the developer and helping the developer to understand and master the AOSP open source project. The software tool determines at a faster speed, reduces the time consumed by the developer for manual determination, reduces the cost, and the dependent module and path determined by the tool are more accurate, thereby reducing the error rate of the developer when manually operating, improving the development efficiency and product quality.

[0008] In combination with the first aspect, in some possible implementation manners, the related parameter comprises: an identity of the target module and a path of the target module; and determining the configuration file for compiling the target module from the folder of the open source project based on the related parameter comprises: searching for a target folder under the identity of the target module from the folder of the open source project according to the path of the target module; and determining the configuration file for compiling the target module from the target folder.

[0009] In the above technical solution, each module in the open source project has a unique identity and is located in a specific directory path. By combining the two parameters of the identity and the path, the target module can be quickly and accurately located in the open source project. This facilitates subsequent accurate determination of the configuration file of the target module and determination of the dependent module of the target module.

[0010] In a possible implementation of the first aspect and the foregoing implementation, in some possible implementation, the related parameters further include a nesting flag, the nesting flag being used to indicate an upper-level dependency module of the search dependency module; after the path of the dependency module is determined by scanning the folder of the open source project based on the identity of the dependency module, the method further includes: determining whether the dependency module has an upper-level dependency module based on the nesting flag; in the case that it is determined that the dependency module has an upper-level dependency module, determining the identity and the path of the upper-level dependency module; and displaying the identity and the path of the dependency module includes: displaying the identity and the path of the dependency module, and the identity and the path of the upper-level dependency module.

[0011] In the foregoing technical solution, the software tool searches the upper-level dependency module of the dependency module based on the nesting flag, which can determine the dependency modules of the target module one by one, and display the determined dependency modules and upper-level dependency modules, thereby helping the R&D personnel to track and understand the complete dependency relationship of the target module.

[0012] In a possible implementation of the first aspect and the foregoing implementation, in some possible implementation, determining whether the dependency module has an upper-level dependency module includes: searching for an auxiliary folder under the identity of the dependency module from the folder of the open source project according to the path of the dependency module; determining a configuration file of the dependency module from the auxiliary folder; and analyzing the configuration file of the dependency module to determine whether the dependency module has an upper-level dependency module.

[0013] In the foregoing technical solution, the software tool automatically searches and analyzes the configuration file of the dependency module based on the path of the dependency module to determine whether the dependency module has an upper-level dependency module, thereby reducing the complexity of manual operation and improving the accuracy and efficiency of dependency analysis.

[0014] In a possible implementation of the first aspect and the foregoing implementation, in some possible implementation, analyzing the configuration file of the dependency module to determine whether the dependency module has an upper-level dependency module includes: using a python script to analyze a keyword in the configuration file of the dependency module; when the keyword includes the identity of the upper-level dependency module, it is determined that the dependency module has an upper-level dependency module; and when the keyword does not include the identity of the upper-level dependency module, it is determined that the dependency module does not have an upper-level dependency module.

[0015] In the foregoing technical solution, the configuration file of the dependency module is automatically analyzed by using the Python script, and the information included in the configuration file is reasonably utilized to determine whether the dependency module has an upper-level dependency module, which can greatly reduce the time and effort required for manual checking and maintaining the dependency relationship and improve the development efficiency.

[0016] Combining the first aspect and the above implementation methods, in some possible implementation methods, the identity and path of the dependent module, as well as the identity and path of the upper-level dependent module, are displayed, including: taking the target module as the starting node, and constructing the dependent nodes of the starting node based on the identity and path of the dependent module; constructing the upper-level dependent nodes of the dependent node based on the identity and path of the upper-level dependent module; and connecting the starting node, dependent nodes, and upper-level dependent nodes based on the dependency relationship between modules to obtain a tree diagram and display the tree diagram.

[0017] In the above technical solution, a tree diagram that is constructed and displayed based on the dependency relationship between modules, including the identity identifiers and paths of dependent modules and the identity identifiers and paths of upper-level dependent modules, can help developers understand the module structure and dependency relationship of open source projects more intuitively, thereby achieving efficient and accurate compilation of target modules.

[0018] In summary, this application achieves automated resolution of dependencies between modules. It can not only determine the identities and paths of dependent modules based on the target module's configuration file, but also determine the configuration files of dependent modules based on their identities and paths, and further determine the upper-level dependent modules of each dependent module up to the top level, thus identifying all dependent modules of the target module. Furthermore, by constructing a tree diagram to display the determined dependencies between the target module and the dependent modules, it provides developers with an intuitive way to understand the project structure, greatly facilitating project management and maintenance, helping developers understand and master AOSP, reducing operational complexity, and allowing the software tool to determine dependencies faster, reducing the time spent manually determining dependencies, lowering costs. Moreover, the automatically determined dependent modules and paths are more accurate, reducing the error rate of manual operations and improving development efficiency and product quality.

[0019] Secondly, an apparatus for determining dependencies is provided, comprising: a receiving module for acquiring relevant parameters of a target module in an open-source project; a determining module for determining the configuration file for compiling the target module from the folder of the open-source project based on the relevant parameters; an analysis module for analyzing the configuration file of the target module to obtain the identity identifiers of the dependent modules of the target module; a scanning module for scanning the folder of the open-source project based on the identity identifiers of the dependent modules to determine the paths of the dependent modules; and a display module for displaying the identity identifiers and paths of the dependent modules.

[0020] In conjunction with the second aspect, in some possible implementations, the relevant parameters include: the identity of the target module and the path of the target module; determining the module is specifically used for: finding the target folder under the identity of the target module from the folder of the open source project according to the path of the target module; and determining the configuration file for compiling the target module from the target folder.

[0021] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the relevant parameters also include: a nested flag, which is used to indicate the upper-level dependent module of the search dependent module; the device also includes: a judgment module, which is used to determine whether the dependent module has an upper-level dependent module based on the nested flag; if it is determined that the dependent module has an upper-level dependent module, the identity and path of the upper-level dependent module are determined; the display module is specifically used to: display the identity and path of the dependent module, as well as the identity and path of the upper-level dependent module.

[0022] Combining the second aspect and the above implementation methods, in some possible implementation methods, the determination module is specifically used for: searching for the auxiliary folder under the identity of the dependent module in the folder of the open source project according to the path of the dependent module; determining the configuration file of the dependent module from the auxiliary folder; analyzing the configuration file of the dependent module to determine whether the dependent module has an upper-level dependent module.

[0023] Combining the second aspect and the above implementation methods, in some possible implementation methods, the judgment module is specifically used to: use a Python script to analyze keywords in the configuration file of the dependent module; when the keyword includes the identity identifier of the upper-level dependent module, determine that the dependent module has an upper-level dependent module; when the keyword does not include the identity identifier of the upper-level dependent module, determine that the dependent module does not have an upper-level dependent module.

[0024] Combining the second aspect and the above implementation methods, in some possible implementation methods, the display module is specifically used to: take the target module as the starting node, and construct the dependent nodes of the starting node based on the names and paths of the dependent modules; construct the upper-level dependent nodes of the dependent nodes based on the names and paths of the upper-level dependent modules; and connect the starting node, dependent nodes, and upper-level dependent nodes based on the dependency relationships between modules to obtain a tree diagram and display the tree diagram.

[0025] Combining the second aspect and the above implementation methods, in some possible implementation methods, the configuration file of the target module is a file with the suffix .bp or .mk.

[0026] Thirdly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0027] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0028] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0029] Figure 1 This is a schematic flowchart illustrating a method for determining dependencies provided in an embodiment of this application;

[0030] Figure 2 This is a schematic diagram of a graphical interface provided in an embodiment of this application.

[0031] Figure 3 This is a schematic diagram of a tree diagram provided in an embodiment of this application.

[0032] Figure 4 This is a schematic diagram of a device for determining dependencies provided in an embodiment of this application.

[0033] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0035] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0036] Currently, the rapid development of smart cockpit technology has driven innovation in the field of in-vehicle systems, with automotive-grade Linux, QNX, and Android becoming mainstream choices. Especially among emerging smart car brands, the combination of Linux / Android and QNX multi-system architectures is gradually becoming standard. This architecture ensures system stability and security while providing a rich interactive experience and a flexible development environment.

[0037] From an industry trend perspective, Android, with its robust ecosystem and ease of development, has become the preferred platform for automotive system development. Whether customizing middleware, developing applications, or optimizing system functions, developers mostly choose to perform secondary development based on AOSP (Android Open Source Project). AOSP not only provides rich APIs and frameworks but also allows for deep customization, meeting the needs of automotive systems for personalization and functional expansion.

[0038] However, the sheer size and complexity of AOSP also present challenges. Developers setting up their local AOSP development environment, whether starting a new project or modifying an existing one, must navigate the tedious process of code compilation. This not only tests the developers' skills but also places higher demands on project time management and resource allocation. Therefore, helping developers understand and master AOSP is not only crucial for intelligent cockpit software development but also an important step in improving development efficiency and ensuring project quality.

[0039] Based on this, this application proposes a method for determining dependencies, which can automatically analyze, determine, and display the dependent modules and paths of the target module, helping developers understand and master AOSP, reducing the time spent, lowering costs, and improving development efficiency and product quality.

[0040] Figure 1 This is a schematic flowchart illustrating a method for determining dependencies according to an embodiment of this application. The method is applied to an electronic device, which may specifically be a software tool for identifying module dependency relationships in AOSP.

[0041] For example, such as Figure 1 As shown, the method 100 includes:

[0042] Step 101: Obtain the relevant parameters of the target module in the open-source project;

[0043] Step 102: Based on relevant parameters, determine the configuration file for compiling the target module from the folder of the open source project;

[0044] Step 103: Analyze the configuration file of the target module to obtain the identity identifiers of the dependent modules of the target module;

[0045] Step 104: Based on the identity of the dependent modules, scan the folders of the open source project to determine the paths of the dependent modules;

[0046] Step 105: Display the identity of the dependent modules and their paths.

[0047] exist Figure 1 In the illustrated embodiment, after obtaining the relevant parameters of the target module, the software tool can directly determine the configuration file for compiling the target module from the open-source project's folder based on these parameters. Then, based on the identity identifiers of the dependent modules obtained from the configuration file, it scans the open-source project's folders, automatically determines and displays the paths of the target module's dependent modules. Developers can quickly and accurately find the dependent modules based on their displayed names and paths, enabling the compilation of the target module. This eliminates the need for developers to manually determine dependent modules from the vast and complex folders of the open-source project based on experience, reducing operational complexity and helping developers understand and master the AOSP open-source project. The software tool determines dependencies faster, reducing the time spent on manual determination by developers, lowering costs, and the more accurate the automatically determined dependent modules and paths, reducing the error rate of manual operations and improving development efficiency and product quality.

[0048] The following is about Figure 1 The steps in the illustrated embodiments are explained in detail below:

[0049] In step 101, the open source project is the AOSP open source project, and the target module is the module that the developers in the AOSP open source project want to compile.

[0050] As is understandable, a module typically refers to a set of related source code files, libraries, or components that have a specific function. Each module is designed to accomplish one or a set of related tasks and can be developed, tested, and maintained independently of other modules, but it can also interact with other modules through interfaces to jointly achieve complex functions.

[0051] The relevant parameters of the target module are used to describe the target module and instruct the software tools to locate it. These parameters may include: the target module's identifier, the target module's path, etc. Specifically, the target module's identifier may be its name.

[0052] Researchers can input relevant parameters of the target module into the software tool through command line interface, graphical interface or other interactive methods, and the software tool can obtain the relevant parameters of the target module.

[0053] For example, suppose a developer wants to compile the target module Camera in the AOSP open-source project. The developer can enter the target module's name, path, and other relevant parameters through the command line. The command entered by the developer could be, for example, " / path / to / AOSP / modules / camera".

[0054] For example, suppose a developer wants to compile the target module "Camera" from the AOSP open-source project. The developer inputs the target module's name, path, and other relevant parameters through a graphical interface. Specifically, the graphical interface can provide a form or dialog box where the developer can fill in the target module's name, path, and other relevant parameters.

[0055] Figure 2 This is a schematic diagram of a graphical interface provided in an embodiment of this application.

[0056] For example, such as Figure 2 As shown, the graphical interface 200 includes a module name input box 201 and a module path input box 202. The module name input box 201 includes a drop-down button 2011. Developers can click the drop-down button 2011 to display a drop-down menu 2012, which lists the names of all available modules in the AOSP open-source project for developers to choose from. Developers can then select a module name from the drop-down menu 2012 and enter the name of the target module. The module path input box 202 can be a text box, allowing developers to manually enter the module path.

[0057] In some embodiments, such as Figure 2 As shown, the graphical interface also includes a submit button 203. Developers can click the submit button 203 to send the relevant parameters of the target module entered into the graphical interface to the software tool. The software tool receives the relevant parameters of the target module in the open source project sent by the developers.

[0058] In step 102, the open-source project folder can be understood as the main folder containing all modules within the open-source project. The configuration file is the configuration file for compiling the target module.

[0059] After obtaining the relevant parameters of the target module, the software tool can determine the configuration file for compiling the target module from the aforementioned main folder based on these parameters.

[0060] In one possible implementation, the relevant parameters include: the identity of the target module and the path of the target module; based on the relevant parameters, the configuration file for compiling the target module is determined from the folder of the open source project, including: searching for the target folder under the identity of the target module in the folder of the open source project according to the path of the target module; and determining the configuration file for compiling the target module from the target folder.

[0061] Understandably, the modules in the main folder of the AOSP open-source project follow a certain directory structure and naming conventions. Each module in the main folder usually has a folder named after itself, which contains the module's source code files, configuration files, and other necessary resource files.

[0062] As in the above embodiment, the identity of the target module is the name of the target module. When the relevant parameters include the path and name of the target module, the software tool can search in the main folder according to the path of the target module to obtain the folder named after the target module, that is, the target folder mentioned above. Then, the configuration file for compiling the target module is determined from the target folder.

[0063] In the method described above, each module in the open-source project has a unique identifier and is located in a specific directory path. By combining these two parameters—identity identifier and path—the location of the target module within the open-source project can be quickly and accurately determined. This facilitates subsequent identification of the target module's configuration files and its dependent modules.

[0064] In one possible implementation, the target module's configuration file is a file with the .bp or .mk extension.

[0065] After obtaining the target folder of the target module, the software tool searches for files with the .bp and .mk extensions within the target folder. If only a .bp file is found, it is designated as the target module's configuration file. If only a .mk file is found, it is also designated as the target module's configuration file. If both .bp and .mk files are found, any one of them is selected as the target module's configuration file.

[0066] In step 103, the dependent modules are the modules that the target module needs to reference during the compilation process. The dependent modules provide the target module with the necessary functions, services or resources to support the integrity and functionality of the target module.

[0067] The configuration file includes information related to the identity of dependent modules. After obtaining the target module's configuration file, the software tool can analyze it using a Python script to obtain the identity of the dependent modules. Specifically, the identity of a dependent module can be its name.

[0068] Specifically, the software tool uses Python's built-in functions `open()` and `read()` to open and read the contents of the configuration file. When the configuration file is a `.bp` file, regular expressions or string manipulation methods are used to find and parse the `deps` field in the configuration file to extract the names of the dependent modules. When the configuration file is a `.mk` file, since static library dependencies are defined using the `LOCAL_STATIC_LIBRARIES` keyword and dynamic library dependencies are defined using the `LOCAL_SHARED_LIBRARIES` keyword in the `.mk` file, regular expressions or string manipulation methods can be used to extract the names of the dependent modules from the `LOCAL_STATIC_LIBRARIES` and `LOCAL_SHARED_LIBRARIES` fields.

[0069] In step 104, the path of the dependent module refers to the exact directory location of the dependent module within the folder of the open-source project. The path of the dependent module can include both relative and absolute paths. A relative path refers to the path from the current location of the target module to the location of the dependent module, while an absolute path refers to the complete path from the root directory of the main folder to the location of the dependent module. The absolute path does not depend on the current location of the target module.

[0070] This application embodiment uses the example of determining the path of the dependent module as a relative path for illustration.

[0071] After obtaining the names of the dependent modules, the software tool uses the current location of the target module as the starting point. Starting from the target module's current location, it recursively scans the target module's parent directory based on the names of the dependent modules. Within each parent directory, it horizontally scans all subdirectories within the same directory until it finds a folder containing the name of the dependent module, thus identifying the dependent module. Specifically, before recursively scanning the parent directories, it can first horizontally scan all subdirectories within the target module's current directory, as the dependent module might reside in the directories of other modules parallel to the target module.

[0072] For example, suppose the developers are compiling the target module `camera` in the AOSP open-source project, and they already know that the name of the dependent module `camera` is `video`. `camera` is currently in directory A. First, the developer scans all subdirectories under directory A horizontally. If no folder containing the name of the dependent module is found, the developer recursively scans the parent directory (let's say directory B) and horizontally scans all subdirectories under directory B. If no folder containing the name of the dependent module is found, the developer recursively scans the parent directory of directory B (let's say directory C) and horizontally scans all subdirectories under directory C, and so on, until a folder containing the name of the dependent module `video` is found, thus obtaining the dependent module `video`.

[0073] After locating the dependent modules, organize and record the directories between the target module and the dependent modules to obtain the relative path from the target module to the dependent module.

[0074] For example, assuming the folder named "video" is located in subdirectory 3 under directory C, the relative path from the target module to the dependent module is determined as: directory A / directory B / directory C / directory 3.

[0075] In some embodiments, when a folder matching the name of a dependent module is found, it is necessary to further confirm that the folder is indeed a dependent module. Specifically, the file content or directory structure can be checked to ensure that the found files conform to the definition of a dependent module. For example, if the dependent module is a library, then the folder should contain associated .a or .so files; if the dependent module is a source code module, then the folder should contain the corresponding source code files and possible configuration files.

[0076] In one possible implementation, the relevant parameters also include: a nested flag, which is used to indicate the parent-level dependent modules of the search dependent modules; after scanning the folders of the open-source project based on the identity of the dependent modules and determining the paths of the dependent modules, the method also includes the following S11 to S12:

[0077] S11, based on the nesting flag, determines whether the dependent module has an upper-level dependent module.

[0078] The nesting flag is used to instruct the software tool to continuously search for the parent modules of the dependent modules. When there is no nesting flag, the software tool will not search for the parent modules of the dependent modules.

[0079] like Figure 2 As shown, developers send relevant parameters of the target module to the software tool through interface 200. Specifically, before clicking the submit button 203, developers can also... Figure 2The nested flag input box 204 shown indicates that a nested flag is input, which enables the nested flag to be sent to the software tool.

[0080] It is understandable that the target module depends on other modules, and the dependent module may also depend on other modules. The other modules that the dependent module depends on are called upper-level dependent modules. When the relevant parameters sent by the developer to the software tool include a nesting flag, the software tool begins to determine the upper-level dependent modules of the dependent module.

[0081] In some embodiments, the upper-level dependent modules of a dependent module may include direct upper-level dependent modules and indirect upper-level dependent modules. It is understood that upper-level dependent modules may also have modules they depend on; other modules that a dependent module depends on can be referred to as direct upper-level dependent modules, and modules that an upper-level dependent module depends on can be referred to as upper-level dependent modules.

[0082] In some embodiments, after determining the upper-level dependent module, the upper-level dependent module can also be used as a dependent module, and the above-described S11 step of determining whether the dependent module has an upper-level dependent module can be executed. This process continues until the dependent module does not have an upper-level dependent module.

[0083] The specific steps for software tools to determine whether a dependent module has an upper-level dependent module are as follows:

[0084] One possible implementation involves determining whether a dependent module has an upper-level dependent module, including: searching for an auxiliary folder under the identity of the dependent module in the open-source project's folder according to the path of the dependent module; determining the configuration file for compiling the dependent module from the auxiliary folder; and analyzing the configuration file of the dependent module to determine whether the dependent module has an upper-level dependent module.

[0085] Understandably, dependent modules also have configuration files. When a dependent module has an upper-level dependent module, the configuration file of the dependent module includes information related to the identity of the upper-level dependent module. Software tools can determine whether a dependent module has an upper-level dependent module by analyzing the configuration file of the dependent module.

[0086] As described in the above embodiment, each module in the main folder has its own named folder containing source code files, configuration files, and other necessary resource files. The identifier of the dependent module is the name of the target module. After determining the path and name of the dependent module, the software tool can search the main folder according to the path of the dependent module to obtain the folder named after the dependent module, thus obtaining the auxiliary folder. Then, it searches for files with the .bp or .mk extension in the auxiliary folder to obtain the configuration files of the dependent module.

[0087] After obtaining the configuration files of the dependent modules, the software tool analyzes the configuration files of the dependent modules to determine whether the dependent module has any parent dependent modules.

[0088] In the above method, the software tool automatically searches and analyzes the configuration files of the dependent modules based on their paths to determine whether there are upper-level dependent modules, reducing the complexity of manual operations and improving the accuracy and efficiency of dependency resolution.

[0089] One possible implementation involves analyzing the configuration file of the dependent module to determine whether the dependent module has an upper-level dependent module. This includes: using a Python script to analyze keywords in the configuration file of the dependent module; if the keyword includes the identifier of the upper-level dependent module, it is determined that the dependent module has an upper-level dependent module; if the keyword does not include the identifier of the upper-level dependent module, it is determined that the dependent module does not have an upper-level dependent module.

[0090] Specifically, the identity identifier of the upper-layer dependent module can be the name of the upper-layer dependent module.

[0091] Specifically, the software tool uses Python's built-in functions `open()` and `read()` to open and read the contents of the configuration files of dependent modules. In these configuration files, information about higher-level dependent modules may be represented by specific keywords. These keywords might include `deps`, `dependencies`, `include`, etc., depending on the configuration file format (e.g., `.bp`, `.mk`, etc.).

[0092] After the software tool opens and reads the contents of the configuration file of the dependent module, it uses regular expressions to search and match keywords in the configuration file. When a matching keyword line is found, it analyzes the line and extracts the name of the parent dependent module. If a matching keyword line is found in the configuration file and the name of the parent dependent module is extracted from the keyword, it is determined that the dependent module has a parent dependent module. If no matching keyword is found in the configuration file or the name of the parent dependent module is not extracted from the keyword, it is determined that the dependent module does not have a parent dependent module.

[0093] The above method uses Python scripts to automatically analyze the configuration files of dependent modules, making good use of the information contained in the configuration files to determine whether a dependent module has an upper-level dependent module. This can significantly reduce the time and effort required for manual inspection and maintenance of dependencies, and improve development efficiency.

[0094] S12, if it is determined that the dependent module has an upper-level dependent module, determine the identity and path of the upper-level dependent module.

[0095] If it is determined that a dependent module has a parent module that also has a parent module, the name of the parent module obtained from the configuration file is retrieved. Then, based on the name of the parent module, the folders of the open-source project are scanned to determine the path of the dependent module. The determined path can be a relative path between the dependent module and its parent module.

[0096] Specifically, as in the above embodiment, when determining the path of a dependent module, the current location of the dependent module can be used as the starting point. Starting from the current location of the dependent module, a recursive scan is performed towards the parent directory of the dependent module based on its name. Within each directory level, all subdirectories within the same directory are scanned horizontally until a folder containing the name of the parent dependent module is found, thus identifying the parent dependent module. Specifically, before recursively scanning towards the parent directory of the dependent module, a horizontal scan of all subdirectories under the current directory of the dependent module can be performed first, as the parent dependent module may reside in the directory of other modules parallel to the dependent module. After finding the parent dependent module, the directories between the dependent module and its parent dependent module are compiled and recorded to obtain the relative path from the dependent module to the parent dependent module.

[0097] For example, the parent module of the dependent module "video" is named "photo". Since the dependent module "video" is currently in directory 3, the system first scans all subdirectories under directory 3 horizontally. If no folder containing the name of the parent module is found, the system recursively scans the parent directory (directory C) and all subdirectories under directory C horizontally. If no folder containing the name of the parent module is found, the system recursively scans the parent directory of directory C (let's say directory D) and all subdirectories under directory D horizontally, and so on, until a folder containing the name of the parent module "photo" is found, thus identifying the parent module "photo". Assuming the folder named "photo" is in subdirectory 2 under directory D, the relative path from the dependent module to the parent module is determined to be: directory C / directory D / directory 2.

[0098] In some embodiments, the target module may have multiple dependent modules. Among these dependent modules, some are independent of other modules (i.e., they have no upper-level dependent modules), while others are dependent on other modules (i.e., they have upper-level dependent modules). When there are multiple dependent modules with upper-level dependent modules, the paths of these upper-level dependent modules need to be determined sequentially.

[0099] As described in the above embodiments, the upper-level dependent modules in which the dependent module exists are called direct upper-level dependent modules. After determining the identity and path of the direct upper-level dependent modules, their configuration files can be determined based on these files. Furthermore, based on these configuration files, it can be determined whether the dependent module has indirect upper-level dependent modules. The specific process for determining this based on the configuration file is as described in the above embodiments and will not be repeated here.

[0100] In some embodiments, after determining the name and path of the upper-level dependent module, the upper-level dependent module can be used as a dependent module. The process of repeatedly determining whether the dependent module has an upper-level dependent module can be executed. If it is determined that the dependent module has an upper-level dependent module, the identity and path of the upper-level dependent module can be determined, and the upper-level dependent module can be used as a dependent module. This process continues until the dependent module does not have an upper-level dependent module, thereby determining the identity and path of all dependent modules of the target module.

[0101] It's understandable that the dependent modules identified based on the target module's configuration file are the target module's direct dependencies. The upper-level dependent modules of these modules are the target module's indirect dependencies. Since both direct and indirect dependent modules are dependent on the target module, upper-level dependent modules can also be considered as dependent on the target module. Furthermore, upper-level dependent modules may also have dependent modules of their own; these dependent modules can also be considered as indirect dependencies of the target module, and therefore, they are also considered as dependent on the target module.

[0102] In step 105, after determining the names and paths of the target module's dependent modules, the names and paths of the dependent modules can be matched one by one and displayed, so that the developers can intuitively understand the dependent modules required to compile the target module and the location of the dependent modules based on the displayed information.

[0103] One possible implementation involves displaying the identity and path of the dependent module, including: displaying the identity and path of the dependent module, as well as the identity and path of the upper-level dependent module.

[0104] When the relevant parameters include nested flags, the software tool will also determine the identity and path of the upper-level dependent module. Therefore, when displaying the information, it is necessary to show the identity and path of the dependent module as well as the identity and path of the upper-level dependent module.

[0105] In the above method, the nested flag indicates that the software tool searches for the upper-level dependent modules of the dependent modules. This can identify the modules that the target module depends on one by one and display both the identified dependent modules and the upper-level dependent modules. This can help developers track and understand the complete dependency relationship of the target module.

[0106] One possible implementation involves displaying the identity and path of the dependent modules, as well as the identity and path of the upper-level dependent modules, including: taking the target module as the starting node, and constructing the dependent nodes of the starting node based on the identity and path of the dependent modules; constructing the upper-level dependent nodes of the dependent nodes based on the identity and path of the upper-level dependent modules; and connecting the starting node, dependent nodes, and upper-level dependent nodes based on the dependency relationships between modules to obtain a tree diagram, and then displaying the tree diagram.

[0107] The target module's dependent modules may include multiple directly dependent modules (i.e., dependent modules) and multiple indirectly dependent modules (i.e., upper-level dependent modules). Therefore, we can first collect the names and paths of all modules that the target module depends on, then take the target module as the starting node, determine the names and paths of the same directly dependent modules as a dependent node of the starting node, and determine the names and paths of the same indirectly dependent modules as an upper-level dependent node of the dependent node. Then, according to the dependency relationships between the modules, connect the starting node, dependent nodes, and upper-level dependent nodes in sequence to construct a tree diagram. The constructed tree diagram includes multiple nodes.

[0108] Figure 3 This is a schematic diagram of a tree diagram provided in an embodiment of this application.

[0109] For example, such as Figure 3 As shown, the target module is named Module 1, and its path is Path 1. The direct dependencies of the target module, determined by its configuration file, include Module 2 and Module 3, with Module 2's path being Path 2 and Module 3's path being Path 3. The indirect dependencies of the target module, determined by Module 2's configuration file, include Module 4 and Module 5, with Module 4's path being Path 4 and Module 5's path being Path 5. The indirect dependencies of the target module, determined by Module 3's configuration file, include Module 6, with Module 6's path being Path 6. Module 1 and Path 1 are designated as the starting nodes of tree diagram 300. Figure 3 In the context of node 1; module 2 and path 2 are identified as dependent nodes of node 1, i.e. Figure 3 Node 2 in the middle; Module 3 and Path 3 are identified as dependent nodes of Node 1, that is Figure 3 Node 3 in the middle; Module 4 and Path 4 are identified as the upper-level dependent nodes of Node 2, that is Figure 3 Node 4 in the middle; Module 5 and path 5 are identified as the upper-level dependent nodes of node 2, that is Figure 3 Node 5 in the middle; Module 6 and path 6 are identified as the upper-level dependent nodes of node 3, that is Figure 3Node 6 in the diagram. The dependencies between modules are as follows: Module 1 depends on Modules 2 and 3, Module 2 depends on Modules 4 and 5, and Module 3 depends on Module 6. Based on the dependency of Module 1 on Modules 2 and 3, Node 1 is connected to Nodes 2 and 3; based on the dependency of Module 2 on Modules 4 and 5, Node 2 is connected to Nodes 4 and 5; based on the dependency of Module 3 on Module 6, Node 2 is connected to Node 6, resulting in tree diagram 300.

[0110] The above method constructs and displays a tree diagram based on the dependencies between modules, which includes the identity identifiers and paths of dependent modules as well as the identity identifiers and paths of upper-level dependent modules. This can help developers understand the module structure and dependencies of open-source projects more intuitively, thereby achieving efficient and accurate compilation of target modules.

[0111] In summary, this application achieves automated resolution of dependencies between modules. It can not only determine the identities and paths of dependent modules based on the target module's configuration file, but also determine the configuration files of dependent modules based on their identities and paths, and further determine the upper-level dependent modules of each dependent module up to the top level, thus identifying all dependent modules of the target module. Furthermore, by constructing a tree diagram to display the determined dependencies between the target module and the dependent modules, it provides developers with an intuitive way to understand the project structure, greatly facilitating project management and maintenance, helping developers understand and master AOSP, reducing operational complexity, and allowing the software tool to determine dependencies faster, reducing the time spent manually determining dependencies, lowering costs. Moreover, the automatically determined dependent modules and paths are more accurate, reducing the error rate of manual operations and improving development efficiency and product quality.

[0112] Figure 4 This is a schematic diagram of a device for determining dependencies provided in an embodiment of this application.

[0113] For example, such as Figure 4 As shown, the device 400 includes:

[0114] Receive module 401 is used to obtain relevant parameters of the target module in the open source project;

[0115] Module 402 is used to determine the configuration file of the target module to be compiled from the folder of the open source project based on relevant parameters;

[0116] Analysis module 403 is used to analyze the configuration file of the target module to obtain the identity identifiers of the target module's dependent modules.

[0117] The scanning module 404 is used to scan the folders of open source projects based on the identity of the dependent modules to determine the paths of the dependent modules;

[0118] Display module 405 is used to display the identity of dependent modules and the path of dependent modules.

[0119] In one possible implementation, the relevant parameters include: the identity of the target module and the path of the target module; the determination module 402 is specifically used to: locate the target folder under the identity of the target module in the folder of the open source project according to the path of the target module; and determine the configuration file for compiling the target module from the target folder.

[0120] In one possible implementation, the relevant parameters further include: a nested flag, which is used to indicate the upper-level dependent module of the search dependent module; the device further includes: a judgment module, which is used to determine whether the dependent module has an upper-level dependent module based on the nested flag; if it is determined that the dependent module has an upper-level dependent module, the identity and path of the upper-level dependent module are determined; the display module 405 is specifically used to: display the identity and path of the dependent module, as well as the identity and path of the upper-level dependent module.

[0121] In one possible implementation, the determination module is specifically used to: locate the auxiliary folder under the identity of the dependent module in the folder of the open source project according to the path of the dependent module; determine the configuration file for compiling the dependent module from the auxiliary folder; analyze the configuration file of the dependent module to determine whether the dependent module has an upper-level dependent module.

[0122] In one possible implementation, the determination module is specifically used to: analyze keywords in the configuration files of dependent modules using a Python script; when the keyword includes the identifier of the upper-level dependent module, determine that the dependent module has an upper-level dependent module; when the keyword does not include the identifier of the upper-level dependent module, determine that the dependent module does not have an upper-level dependent module.

[0123] In one possible implementation, the display module is specifically used to: take the target module as the starting node, and construct the dependent nodes of the starting node based on the names and paths of the dependent modules; construct the upper-level dependent nodes of the dependent nodes based on the names and paths of the upper-level dependent modules; and connect the starting node, dependent nodes, and upper-level dependent nodes based on the dependencies between modules to obtain a tree diagram and display the tree diagram.

[0124] In one possible implementation, the target module's configuration file is a file with the .bp or .mk extension.

[0125] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0126] For example, such as Figure 5 As shown, the electronic device 500 includes a memory 501 and a processor 502, wherein the memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform a method for determining dependencies.

[0127] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a method for determining dependencies provided in embodiments of this application.

[0128] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0129] When each functional module is divided according to its corresponding function, the device may further include a receiving module, a determining module, an analyzing module, a scanning module, and a display module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced to the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0130] It should be understood that the apparatus provided in this embodiment is used to perform the above-described method for determining dependencies, and therefore can achieve the same effect as the above-described implementation method.

[0131] When using integrated units, the device may include a processing module and a storage module. When applied to an electronic device, the processing module can be used to control and manage the operation of the electronic device. The storage module can be used to support the execution of relevant program code by the electronic device.

[0132] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0133] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, a module, or a module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a method for determining dependencies provided in the above embodiments.

[0134] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the method for determining dependencies provided in the above embodiment.

[0135] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a method for determining dependencies provided in the above embodiment.

[0136] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0137] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0138] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or modules may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0139] The above description is merely a specific embodiment 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.

Claims

1. A method of determining dependencies, characterized by, The method comprises: acquiring related parameters of a target module in an open source project; determining a configuration file for compiling the target module from a folder of the open source project based on the related parameters; analyzing the configuration file of the target module to obtain an identity of a dependent module of the target module; scanning the folder of the open source project based on the identity of the dependent module to determine a path of the dependent module; displaying the identity and path of the dependent module.

2. The method of claim 1, wherein, The related parameters comprise an identity of the target module and a path of the target module; and the determining of the configuration file for compiling the target module from the folder of the open source project based on the related parameters comprises: finding a target folder under the identity of the target module from the folder of the open source project according to the path of the target module; determining the configuration file for compiling the target module from the target folder.

3. The method according to claim 1 or 2, characterized in that, The related parameters further comprise a nesting flag, which is used to indicate searching for an upper-level dependent module of the dependent module; After the scanning of the folder of the open source project based on the identity of the dependent module to determine the path of the dependent module, the method further comprises: judging whether the dependent module has an upper-level dependent module based on the nesting flag; determining an identity and a path of the upper-level dependent module in a case where it is determined that the dependent module has the upper-level dependent module; The displaying of the identity and path of the dependent module comprises: displaying the identity and path of the dependent module, and the identity and path of the upper-level dependent module.

4. The method of claim 3, wherein, The judging of whether the dependent module has an upper-level dependent module comprises: finding an auxiliary folder under the identity of the dependent module from the folder of the open source project according to the path of the dependent module; determining a configuration file for compiling the dependent module from the auxiliary folder; analyzing the configuration file of the dependent module to judge whether the dependent module has an upper-level dependent module.

5. The method of claim 4, wherein, The analyzing of the configuration file of the dependent module to judge whether the dependent module has an upper-level dependent module comprises: analyzing a keyword in the configuration file of the dependent module by using a python script; determining that the dependent module has an upper-level dependent module when the keyword comprises the identity of the upper-level dependent module; determining that the dependent module does not have an upper-level dependent module when the keyword does not comprise the identity of the upper-level dependent module.

6. The method of claim 3, wherein, The displaying of the identity and path of the dependent module, and the identity and path of the upper-level dependent module comprises: taking the target module as a starting node, and constructing a dependent node of the starting node based on the identity and path of the dependent module; constructing an upper-level dependent node of the dependent node based on the identity and path of the upper-level dependent module; connecting the starting node, the dependent node and the upper-level dependent node based on a dependent relationship between modules to obtain a tree diagram, and displaying the tree diagram.

7. The method according to claim 1 or 2, characterized in that, The configuration file of the target module is a file with a suffix of.bp or.mk.

8. An apparatus for determining dependencies, the apparatus comprising: The device comprises: The receiving module is configured to acquire a related parameter of a target module in an open source project; The determining module is configured to determine, based on the related parameter, a configuration file for compiling the target module from a folder of the open source project; The analyzing module is configured to analyze the configuration file of the target module to obtain an identity of a dependent module of the target module The scanning module is configured to scan the folder of the open source project based on the identity of the dependent module to determine a path of the dependent module; The display module is configured to display the identity of the dependent module and the path of the dependent module.

9. An electronic device, comprising: The electronic device comprises: A memory configured to store executable program code; A processor configured to call and run the executable program code from the memory, so that the electronic device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, when the computer program is executed, the method according to any one of claims 1 to 7 is realized.

Images