Compiling method, system, terminal, medium and product for sharing AOSP code

Abstract

The application discloses a compilation method and system of shared AOSP code, a terminal, a computer readable storage medium and a program product, and belongs to the computer field. The compilation method is applied to a terminal, and the terminal is deployed with a container. The method comprises the following steps: mounting a first directory corresponding to read-only AOSP code from a cloud and a second directory corresponding to read-write SOC code from the terminal to the container, wherein the second directory is a subdirectory in the first directory; when performing compilation in the container, reading AOSP code corresponding to a subdirectory different from the second directory in the first directory from the cloud, reading SOC code corresponding to the second directory from the terminal, and performing compilation. Compared with the traditional method that each engineer completely copies AOSP code, the application can save about 95% of local storage occupation, significantly reduce storage cost, and also improve the cooperation efficiency of the team.

Description

Technical Field

[0001] This application belongs to the field of computer science, and specifically relates to a compilation method, system, terminal, computer-readable storage medium, and program product for sharing AOSP code. Background Technology

[0002] The Android Open Source Project (AOSP) has a codebase exceeding 100GB and continues to grow with each version iteration. The complete compilation process of the Android system relies on the complete AOSP code tree, therefore engineers need to obtain the entire AOSP code when developing for the Android system.

[0003] In current technology, each engineer developing an Android system copies the entire AOSP code locally (over 100GB), and then uses this copy to develop and store intermediate files and final output generated during compilation (typically adding an extra 200GB to 500GB), resulting in huge local disk usage. For R&D teams with dozens of engineers, each member needs to store the same code, causing serious resource waste. Therefore, how to effectively reduce the local storage usage of engineers while ensuring the normal compilation of the Android system is a technical problem that needs to be solved. Summary of the Invention

[0004] Therefore, the purpose of this application is to provide a compilation method, system, terminal, computer-readable storage medium, and program product for sharing AOSP code, so as to effectively reduce the local storage usage of engineers while ensuring the normal compilation of the Android system.

[0005] The embodiments of this application are implemented as follows: In a first aspect, embodiments of this application provide a method for compiling shared AOSP code, applied to a terminal, wherein the terminal is deployed with a container, the method comprising: mounting a first directory corresponding to read-only AOSP code from the cloud and a second directory corresponding to read-write SOC code from the terminal to the container, wherein the second directory is a subdirectory of the first directory; when performing compilation within the container, reading AOSP code corresponding to a subdirectory of the first directory that is different from the second directory from the cloud, and reading SOC code corresponding to the second directory from the terminal, and performing compilation.

[0006] In the above implementation scheme, within the Android development environment, the first directory corresponding to the complete AOSP code stored in the cloud is mounted in read-only mode into the container, and the second directory corresponding to the SOC code of the local terminal is mounted in read-write mode into the same directory tree within the container. This constructs a complete Android compilation environment, enabling compilation within the container to read the AOSP code corresponding to subdirectories under the first directory that are different from the second directory from the cloud, and to read the SOC code corresponding to the second directory from the terminal for compilation. Compared to the traditional method where each engineer copies the complete AOSP code, this solution can save approximately 95% of local storage usage, significantly reducing storage costs, and also improving team collaboration efficiency.

[0007] In one possible implementation of the first aspect embodiment, the method further includes: covering the corresponding subdirectory in the first directory with the second directory; reading AOSP code corresponding to a subdirectory in the first directory that is different from the second directory from the cloud, including: reading AOSP code corresponding to an uncovered subdirectory in the first directory from the cloud.

[0008] In the above implementation scheme, the second directory can also be used to overwrite the corresponding subdirectories in the first directory. Since the second directory overwrites the subdirectories with the same name in the first directory, the original path in the container that points to the read-only version in the cloud is replaced by the local writable version. When the compilation system accesses the subdirectory, it actually reads the local file instead of the read-only version in the cloud. It only needs to read the AOSP code corresponding to the subdirectories in the first directory that have not been overwritten from the cloud, which can improve the overall compilation efficiency.

[0009] In one possible implementation of the first aspect embodiment, the first directory is mounted to a first path within the container, and the second directory is mounted to a second path within the container, wherein the second path is a subpath of the first path.

[0010] In the above implementation scheme, by merging the cloud-based read-only AOSP directory and the local writable SOC directory into the same path (first path) within the container, the compilation system can obtain the complete source code tree by accessing only a single root directory without distinguishing the source of the code. This maintains full compatibility with the standard AOSP compilation process and helps improve compilation speed.

[0011] In one possible implementation of the first aspect embodiment, the second directory includes at least one of the device configuration directory, hardware abstraction layer directory, vendor proprietary code directory, and software architecture layer directory in the first directory.

[0012] In the above implementation scheme, since in actual Android system development, engineers' work is usually concentrated in directories such as device configuration directory, hardware abstraction layer directory, vendor proprietary code directory, and software architecture layer in the AOSP code tree, the amount of code in these directories usually only accounts for about 5% of the entire AOSP code. This application limits the second directory to at least one of the above directories, so that engineers only need to store and modify the SOC code corresponding to these core working directories locally, without having to store the entire AOSP source code tree, thereby greatly reducing local storage usage (about 95%).

[0013] In one possible implementation of the first aspect embodiment, the AOSP code is stored in the object storage service, network file system, or cloud drive in the cloud.

[0014] In the above implementation scheme, since object storage services, network file systems, or cloud storage are all mature cloud storage technologies, storing AOSP code in such cloud storage in read-only mode can achieve team-level read-only sharing, avoiding each engineer from repeatedly downloading and storing the same AOSP code, significantly reducing local storage usage and network bandwidth consumption. At the same time, storing in read-only mode prevents terminals from modifying the AOSP code stored in the cloud, thereby ensuring the integrity and consistency of the shared code, avoiding the disruption of the common baseline due to modifications by individual engineers, and ensuring the reliability of team collaboration.

[0015] In one possible implementation of the first aspect embodiment, the method further includes: mounting the compilation output directory from the terminal to the container, and writing the intermediate files and final image generated during compilation into the compilation output directory when performing compilation within the container.

[0016] In the above implementation scheme, by mounting the compilation output directory from the terminal to the container, the intermediate files and the final image generated by compilation are directly written to the local disk without occupying the internal storage of the container or cloud storage space. This allows the compilation results to be persistently stored locally, and the compilation results will not be lost even if the container is deleted or rebuilt.

[0017] In one possible implementation of the first aspect embodiment, the first mounting operation (mounting the compilation output directory from the terminal to the container) and the second mounting operation (mounting the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container) are implemented by the same mounting command.

[0018] In the above implementation scheme, the same mount command is used to mount the compilation output directory from the terminal to the container, the first directory corresponding to the read-only AOSP code from the cloud, and the second directory corresponding to the read-write SOC code from the terminal to the container. This helps ensure that all necessary directories (cloud AOSP, local SOC, and local output directory) are in place when the container starts, reducing the configuration error rate. At the same time, it helps to simplify the operation process, improve the consistency and reproducibility of the compilation environment configuration, and facilitate the integration of automated scripts.

[0019] In one possible implementation of the first aspect embodiment, the directory structure of the read-only AOSP code stored in the cloud is consistent with the directory structure of the official AOSP.

[0020] In the above implementation scheme, since the directory structure of the read-only AOSP code stored in the cloud is completely consistent with the directory structure of the official AOSP, the source code tree can be directly identified and traversed without any modifications during compilation, ensuring full compatibility with the native compilation process; at the same time, engineers do not need to learn a custom directory structure and can use the familiar AOSP directory organization method, which improves development efficiency.

[0021] Secondly, embodiments of this application also provide a compilation system for sharing AOSP code, including: a cloud and a terminal; the cloud is configured to store AOSP code in read-only mode; the terminal is configured to store SOC code in read-write mode; and a container deployed on the terminal is configured to: The system mounts a first directory containing read-only AOSP code from the cloud and a second directory containing read-write SOC code from the terminal, wherein the second directory is a subdirectory of the first directory. During compilation, the system reads AOSP code from the cloud corresponding to a subdirectory of the first directory that is different from the second directory, and reads the SOC code corresponding to the second directory from the terminal for compilation.

[0022] In one possible implementation of the second aspect embodiment, the container is further configured to overwrite the corresponding subdirectories in the first directory with the second directory, and to read the AOSP code corresponding to the uncovered subdirectories under the first directory from the cloud.

[0023] In one possible implementation of the second aspect embodiment, the container is further configured to: mount a compilation output directory from the terminal, and write the compiled intermediate files and the final image to the compilation output directory.

[0024] Thirdly, embodiments of this application also provide a compilation device for shared AOSP code applied to a container. The compilation device includes: a mounting module and a compilation module; the mounting module is used to mount a first directory corresponding to read-only AOSP code from the cloud and a second directory corresponding to read-write SOC code from the terminal to the container, wherein the second directory is a subdirectory of the first directory; the compilation module is used to read AOSP code corresponding to a subdirectory of the first directory that is different from the second directory from the cloud and read SOC code corresponding to the second directory from the terminal when performing compilation in the container, and to compile it.

[0025] Fourthly, embodiments of this application also provide a terminal, including: a memory and a processor, the processor being connected to the memory; the memory being used to store a program; the processor being used to invoke the program stored in the memory to perform the method provided by any possible implementation of the first aspect embodiment and / or in combination with the first aspect embodiment.

[0026] Fifthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the method provided by any possible implementation of the first aspect embodiments and / or in combination with the first aspect embodiments.

[0027] Sixthly, embodiments of this application also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method provided by any possible implementation of the first aspect embodiment and / or in combination with the first aspect embodiment.

[0028] The technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the same or similar implementation methods in aspect one, and will not be repeated here.

[0029] Other features and advantages of this application will be set forth in the following description. The objectives and other advantages of this application can be realized and obtained through the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the embodiments will be briefly described below. Obviously, the drawings described below are only some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings. The above and other objects, features, and advantages of this application will become clearer through the accompanying drawings.

[0031] Figure 1 A schematic diagram of the structure of the compilation system provided in the embodiments of this application is shown.

[0032] Figure 2 A flowchart illustrating a compilation method for shared AOSP code provided in an embodiment of this application is shown.

[0033] Figure 3 A schematic diagram of a compilation apparatus provided in an embodiment of this application is shown.

[0034] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0035] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The following embodiments are provided as examples to more clearly illustrate the technical solutions of this application, and should not be used to limit the scope of protection of this application. Those skilled in the art will understand that, without conflict, the following embodiments and features can be combined with each other.

[0036] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, relational terms such as "first," "second," etc., in the description of this application are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0037] Furthermore, the term "and / or" in this application is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0038] In the description of the embodiments of this application, unless otherwise expressly specified and limited, the technical term "connection" can be a direct connection or an indirect connection through an intermediate medium.

[0039] The inventors of this application discovered that in actual Android system development, the main tasks of System-on-Chips (SOC) engineers are device adaptation, hardware driver integration, and the development of vendor-specific modules. This work is typically concentrated in specific directories within the AOSP code tree, including the device configuration directory (device), hardware abstraction layer directory (hardware), and vendor-specific code directory (vendor), occupying only about 5% of storage. In contrast, most other directories in the AOSP code tree, such as software architecture layer code (frameworks), system services (system), and build system (build), are rarely modified in engineers' daily development. However, the complete compilation process of the Android system depends on the complete AOSP code tree; therefore, engineers still need to obtain all AOSP code when developing the Android system.

[0040] If each engineer were to completely copy the AOSP code locally during Android system development, it would result in enormous local disk usage. Therefore, how to effectively reduce the storage consumption of engineers' local storage while ensuring the normal compilation of the Android system is the technical problem that this application aims to solve.

[0041] To reduce local storage usage for engineers, this application provides a compilation method, system, terminal, computer-readable storage medium, and program product for sharing AOSP code. In an Android development environment, this method mounts the first directory corresponding to the complete AOSP code stored in the cloud into a container in read-only mode, and mounts the second directory corresponding to the SOC code of the local terminal (such as directories for device configuration, hardware abstraction layer, vendor) into the same directory tree within the container in read-write mode, thereby constructing a complete Android compilation environment. By executing standard compilation commands such as `make` or `mm` within the container, normal compilation of the Android system can be completed with only the SOC code stored locally (storage usage approximately 5% of the traditional method). Compared to the traditional method where each engineer copies the complete AOSP code, this solution can save approximately 95% of local storage usage, significantly reducing storage costs and improving team collaboration efficiency. The following describes the method in conjunction with... Figure 1The compilation system for shared AOSP code provided in this application embodiment is described below. This compilation system includes a cloud and at least one terminal. The cloud is connected to each terminal via a communication network, and the terminal can interact with the cloud, for example, downloading the AOSP code required for compilation from the cloud. By storing the AOSP code in the cloud, multiple terminals can share the same AOSP code, thereby reducing local storage usage.

[0042] The terminal in this application may be, but is not limited to, mobile phones, tablets, laptops, desktop computers, servers, and other electronic devices capable of running containers and executing compiled code.

[0043] The cloud in this application may include, but is not limited to, servers or services that can store AOSP code in read-only mode and provide remote access, such as public cloud object storage servers, private cloud object storage servers, network file system servers, enterprise-level cloud storage servers, and distributed storage systems.

[0044] In the cloud, the AOSP code is configured to be stored in read-only mode. The directory structure of the AOSP code is consistent with that of the official AOSP (such as the AOSP source code developed and maintained by Google, which has a standard directory structure). For example, the official AOSP code can be packaged into a read-only image, uploaded to the cloud, and provided with read-only access through a mount point (such as / workspace / ${product} / android). Storing the AOSP code in read-only mode prevents terminal devices from modifying the AOSP code stored in the cloud, thereby ensuring the integrity and consistency of the shared code, preventing modifications by individual engineers from breaking the common baseline, and ensuring the reliability of team collaboration.

[0045] In some possible implementations, AOSP code can be stored in cloud-based object storage services, network file systems, or cloud drives. For example, a read-only AOSP image can be created on a public cloud drive with a directory structure consistent with the official AOSP.

[0046] The terminal is configured to store SOC code in a read-write manner to support engineers in modifying the SOC code. The second directory corresponding to the SOC code stored locally by the engineer is a subdirectory of the first directory corresponding to the AOSP code, and may include directories such as device / , hardware / , vendor / , etc., with relatively low storage usage. In some possible implementations, the second directory includes at least one of the following from the first directory: device configuration directory, hardware abstraction layer directory, vendor-specific code directory, and software architecture layer directory (such as framework / av, which is a subdirectory of the framework directory). Since different engineers are responsible for developing different projects, their corresponding second directories may also be different.

[0047] A Docker container is deployed (or running) on ​​the terminal. A container is a runtime instance of operating system-level virtualization technology, which provides an independent runtime environment for applications by isolating processes and resources such as file systems, networks, and process spaces. In this application, the container is used to provide an independent Android compilation environment and supports mounting a read-only AOSP directory from the cloud and a read-write SOC code directory from the local machine.

[0048] The container in this application is configured to mount a first directory corresponding to read-only AOSP code from the cloud and a second directory corresponding to read-write SOC code from the terminal, wherein the second directory is a subdirectory of the first directory; during compilation, the AOSP code corresponding to the subdirectory of the first directory that is different from the second directory is read from the cloud, and the SOC code corresponding to the second directory is read from the terminal and compiled.

[0049] An Android build image can be pre-built or obtained on the terminal, and then a container can be created based on that image. Once the container starts, it provides the build environment. After the container starts, the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal can be mounted on the container.

[0050] During mounting, the first directory is mounted to the first path within the container, and the second directory is mounted to the second path within the container, where the second path is a subpath of the first path.

[0051] In one implementation, an example of a mount command (such as mount command 1) is as follows: "docker run -it --rm \ -v / workspace / ${product} / android: / android:ro \ -v $(pwd) / device / vsi: / android / device / vsi \ -v $(pwd) / hardware / all: / android / hardware / all \ -v $(pwd) / vendor / vsi: / android / vendor / vsi \ <android-build-image>" / bin / bash", in the example command above, `docker run` is used to start a Docker container, while <android-build-image>This specifies the image used by the Docker container. Each parameter in the form of `-va:b` indicates that the host directory `a` is mounted to the container's directory `b`. For example, `"v $(pwd) / device / vsi: / android / device / vsi"` means mounting the `device / vsi` directory under the current working directory (`pwd`) to the ` / android / hardware / vsi` directory in the container. The final `:ro` suffix indicates that the mount is read-only; if `:ro` is not added, the default is read-write mounting.

[0052] If an engineer needs to modify a subdirectory in the AOSP code tree (e.g., framework / av), they can copy the subdirectory from the cloud to their local machine and mount it into the container using a new mount command. For example, they can add the following mount command (mount command 2): "docker run -it --rm \ -v $(pwd) / framework / av: / android / framework / av <android-build-image> / bin / bash.

[0053] It is understandable that "mounting the compiled output directory from the terminal to the container" and "mounting the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container" can be achieved using the same mount command (i.e., multiple mount parameters in one container startup command), or they can be achieved using different mount commands. This process can also be described as follows: the first mount operation and the second mount operation are achieved using the same mount command, where the first mount operation mounts the compiled output directory from the terminal to the container, and the second mount operation mounts the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container. If achieved using the same mount command, then mount command 2 and mount command 1 in the above example need to be merged into one command.

[0054] As can be seen from the example above, during mounting, the first directory is mounted to the first path of the container (e.g., / android), while the second directory is mounted to a sub-path under the first path (e.g., / android / device / vsi).

[0055] Since the second directory corresponding to the SOC code is a standard subdirectory in the AOSP code tree, after mounting it as a subpath of the first directory, during compilation within the container, the AOSP code corresponding to the subdirectories under the first directory that are different from the second directory is read from the cloud, and the SOC code corresponding to the second directory is read from the terminal for compilation. In other words, the AOSP code corresponding to the subdirectories under the first directory other than the second directory is read from the cloud, and the SOC code corresponding to the second directory is read from the local terminal.

[0056] In some possible implementations, a second directory can be used to override the corresponding subdirectory in the first directory. For example, suppose the first directory is a read-only AOSP code tree in the cloud, containing a subdirectory named `device / vsi`. The engineer's local SOC code has `device / vsi` as its second directory. During mounting, the local `device / vsi` directory is mounted to the ` / android / device / vsi` path within the container. Since ` / android / device / vsi` in the container originally pointed to the subdirectory `device / vsi` with the same name in the first directory, after mounting, the content of that path is completely replaced by the local `device / vsi`. When the build system accesses ` / android / device / vsi / BoardConfig.mk`, it actually reads the local file, not the read-only version in the cloud, thus achieving the overriding of the corresponding subdirectory in the first directory (cloud) by the second directory (local).

[0057] In some possible implementations, the second directory can be used to override the corresponding subdirectories in the first directory. Accordingly, at compile time, the container accesses the ` / android` directory: for paths overridden by the second directory, it reads the local SO code; for other paths not overridden, it reads the cloud-based read-only AOSP code, i.e., it reads the AOSP code corresponding to the uncovered subdirectories in the first directory from the cloud. In this case, the container is also configured to overwrite the corresponding subdirectories in the first directory with the second directory, and to read the AOSP code corresponding to the uncovered subdirectories in the first directory from the cloud.

[0058] After mounting, a unified source code directory tree is formed within the container. During compilation, when traversing the ` / android` directory, the container reads locally writable code for subpaths covered by the local SOC code directory, and reads cloud-based read-only AOSP code for other uncovered subpaths. This allows the container to utilize both read-only AOSP and writable SOC code to build a complete Android system. The Android project building scheme based on cloud-based read-only AOSP sharing and container mounting provided in this application can build a complete compilable Android project by overwriting corresponding subdirectories in the cloud-based AOSP directory with the local SOC code directory, without needing to copy the complete AOSP locally. It also supports local overwriting and modification of specific AOSP subdirectories.

[0059] In some possible implementations, the container is also configured to mount the build output directory from the terminal and write the intermediate files and final image generated during compilation to the build output directory. The added mount command is as follows: -v $(pwd) / intermediate / android / out: / android / out \.

[0060] This application stores AOSP code in read-only mode in the cloud and utilizes container mounting mechanisms to seamlessly integrate the SOC engineer's development directory with the AOSP code. This maintains a complete, compileable Android project environment while significantly reducing disk usage and synchronization costs. This solution is suitable for large-scale Android projects, improving team collaboration efficiency and resource utilization, and has broad industrial application value.

[0061] The following is combined with Figure 2 The present application describes a method for compiling shared AOSP code, which is applied to a terminal with a container deployed.

[0062] S1: Mount the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container. In some possible implementations, S1 may further include: mounting the compilation output directory from the terminal to the container. Optionally, "mounting the compilation output directory from the terminal to the container" and "mounting the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container" can be achieved by the same mount command. For example, multiple mount parameters can be included in a single container startup command to achieve the above-mentioned mounting.

[0063] By deploying a container on the terminal, a first directory corresponding to the read-only AOSP code from the cloud and a second directory corresponding to the read-write SOC code from the terminal can be mounted into the container, where the second directory is a subdirectory of the first directory. For example, the second directory may include at least one of the following directories from the first directory: device configuration directory, hardware abstraction layer directory, vendor proprietary code directory, and software architecture layer directory.

[0064] The AOSP code is stored in a cloud-based object storage service, network file system, or cloud drive. When stored, the directory structure of the AOSP code is consistent with the directory structure of the official AOSP.

[0065] In one implementation, a first directory is mounted to a first path within the container, and a second directory is mounted to a second path within the container, wherein the second path is a subpath of the first path.

[0066] In one possible approach, the method also includes overwriting the corresponding subdirectories in the first directory with the second directory.

[0067] S2: When compiling within the container, it reads the AOSP code corresponding to the subdirectories of the first directory that are different from the second directory from the cloud, and reads the SOC code corresponding to the second directory from the terminal, and compiles them.

[0068] After mounting, a unified source code directory tree is formed inside the container. When compiling inside the container, the AOSP code corresponding to the subdirectories of the first directory that are different from the second directory is read from the cloud, and the SOC code corresponding to the second directory is read from the terminal and compiled.

[0069] In one possible approach, if the second directory overwrites the corresponding subdirectory in the first directory, then when reading the AOSP code corresponding to the subdirectory in the first directory that is different from the second directory from the cloud, the process includes reading the AOSP code corresponding to the subdirectory in the first directory that was not overwritten from the cloud.

[0070] In some possible implementations, the above method further includes S3: when compiling within the container, writing the intermediate files and the final image generated during compilation to the compilation output directory.

[0071] The compilation method for shared AOSP code provided in this application embodiment has the same implementation principle and technical effect as the aforementioned compilation system embodiment. For the sake of brevity, any parts not mentioned in the method embodiment can be referred to the corresponding content in the aforementioned compilation system embodiment.

[0072] This application also provides a compilation device 100 for sharing AOSP code, applied to containers, such as... Figure 3 As shown, the compilation device 100 includes a mounting module 110 and a compilation module 120. In some scenarios, the compilation device may be part of a container.

[0073] Mounting module 110 is used to mount a first directory corresponding to read-only AOSP code from the cloud and a second directory corresponding to read-write SOC code from the terminal to the container, wherein the second directory is a subdirectory of the first directory.

[0074] The compilation module 120 is used to read AOSP code corresponding to a subdirectory under the first directory that is different from the second directory from the cloud and read SOC code corresponding to the second directory from the terminal for compilation when performing compilation within the container.

[0075] Optionally, the mounting module 110 is also used to overwrite the corresponding subdirectory in the first directory with the second directory. Correspondingly, the compilation module 120 is used to read the AOSP code corresponding to the subdirectory that has not been overwritten in the first directory from the cloud.

[0076] Optionally, the mounting module 110 is further configured to mount the compilation output directory from the terminal to the container. Correspondingly, the compilation module 120 is further configured to write the intermediate files and the final image generated during compilation into the compilation output directory when performing compilation within the container.

[0077] The compilation device 100 provided in this application embodiment has the same implementation principle and technical effect as the aforementioned compilation system embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned compilation system embodiment.

[0078] like Figure 4 As shown, Figure 4 This diagram illustrates a structural block diagram of a terminal 200 provided in an embodiment of this application. The terminal 200 includes: a transceiver 210, a memory 220, a communication bus 230, and a processor 240. The transceiver 210, memory 220, and processor 240 are electrically connected directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected through one or more communication buses 230 or signal lines. The transceiver 210 is used to send and receive data. The memory 220 is used to store computer programs. The computer program includes at least one software functional module that can be stored in the memory 220 in the form of software or firmware or embedded in the operating system (OS) of the terminal 200. The processor 240 is used to execute the software functional modules or computer programs stored in the memory 220. For example, the processor 240 is used to execute the compilation method of the shared AOSP code described above.

[0079] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0080] Processor 240 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), Network Processor (NP), Graphics Processing Unit (GPU), Accelerated Processing Unit (ACCU), Multimedia Application Processor (MAP), microprocessor, etc.; it can also be a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. Alternatively, processor 240 can also be any conventional processor.

[0081] The aforementioned terminal 200 includes, but is not limited to, electronic devices such as mobile phones, tablets, laptops, desktop computers, and servers that can run containers and execute compiled code.

[0082] This application embodiment also provides a non-volatile computer-readable storage medium (hereinafter referred to as the storage medium) storing a computer program, which is executed by a computer such as the terminal 200 described above to perform the compilation method of the shared AOSP code described above.

[0083] This application also provides a computer program product, which includes a computer program. When the computer program is executed by a computer, it performs the compilation method for shared AOSP code as described above.

[0084] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

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

[0086] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0087] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, laptop, server, or electronic device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0088] 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 compilation method for shared AOSP code, characterized in that, Applied to a terminal, wherein the terminal is equipped with a container, the method includes: Mount the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container, wherein the second directory is a subdirectory of the first directory; During compilation within the container, AOSP code corresponding to subdirectories under the first directory that are different from the second directory is read from the cloud, and SOC code corresponding to the second directory is read from the terminal and compiled.

2. The compilation method according to claim 1, characterized in that, The method further includes: Overwrite the corresponding subdirectories in the first directory with the second directory; Reading AOSP code corresponding to subdirectories under the first directory that are different from the second directory from the cloud includes: Read the AOSP code corresponding to the uncovered subdirectories under the first directory from the cloud.

3. The compilation method according to claim 1 or 2, characterized in that, The first directory is mounted to a first path within the container, and the second directory is mounted to a second path within the container, wherein the second path is a subpath of the first path.

4. The compilation method according to any one of claims 1-3, characterized in that, The second directory includes at least one of the following from the first directory: device configuration directory, hardware abstraction layer directory, vendor proprietary code directory, and software architecture layer directory.

5. The compilation method according to any one of claims 1-4, characterized in that, The AOSP code is stored in the cloud's object storage service, network file system, or cloud drive.

6. The compilation method according to any one of claims 1-5, characterized in that, The method further includes: The compilation output directory from the terminal is mounted to the container. When compilation is performed in the container, the intermediate files and the final image generated by compilation are written to the compilation output directory.

7. The compilation method according to claim 6, characterized in that, The first mount operation and the second mount operation are implemented using the same mount command. The first mount operation mounts the compilation output directory from the terminal to the container. The second mount operation mounts the first directory corresponding to the read-only AOSP code from the cloud and the second directory corresponding to the read-write SOC code from the terminal to the container.

8. The compilation method according to claim 1, characterized in that, The directory structure of the read-only AOSP code stored in the cloud is consistent with the directory structure of the official AOSP.

9. A compilation system for sharing AOSP code, characterized in that, include: In the cloud, the AOSP code is configured to be stored in read-only mode; The terminal is configured to store SOC code in a read-write manner; The container deployed on the terminal is configured as follows: Mount a first directory corresponding to the read-only AOSP code from the cloud and a second directory corresponding to the read-write SOC code from the terminal, wherein the second directory is a subdirectory of the first directory; During compilation, the AOSP code corresponding to the subdirectories under the first directory that are different from the second directory is read from the cloud, and the SOC code corresponding to the second directory is read from the terminal and compiled.

10. A terminal, characterized in that, include: A memory and a processor, wherein the processor is connected to the memory; The memory is used to store programs; The processor is configured to invoke a program stored in the memory to execute the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, performs the method as described in any one of claims 1-8.

12. A computer program product comprising a computer program that, when executed by a processor, implements the method of any one of claims 1-8.

Images