Method for automatically packaging header file and. So file and automatically quoting header file by Android Gradle

Abstract

The invention discloses a method for automatically packaging a header file and a. So file and automatically quoting the header file in an Android Gradle, which comprises the following steps of: in a library project, uniformly placing the header files exposed to the outside in a so library in a directory; defining a task of copying a header file in a Gradle construction script of the library project, and configuring the task to be triggered before construction, so that the header file is copied to a resource directory; in the process of executing Gradle construction, packaging a library project into an AAR file and uploading the AAR file to a Maven warehouse, enabling the AAR file to automatically contain the header file and the. So file; in a reference end project, the AAR file is introduced through a task written in a Gradle script, decompression operation is executed after dependency analysis is completed, and a header file and a. So file in the AAR file are copied to a local target directory; and in a Gradle construction script, injecting the decompressed header file path and the. So file path into construction configuration parameters.

Description

TECHNICAL FIELD

[0001] The present application relates to the construction and dependency management technology under the Android platform, in particular to the collaborative use of the Gradle-based construction system and the CMake construction tool, and the dependency publishing and management of the Maven warehouse, and particularly relates to a method for automatically packaging header files and.so files and automatically referencing header files by Android Gradle. BACKGROUND

[0002] In the prior art, Android application engineering often needs to reference the dependency library published in the remote Maven warehouse, which may contain Kotlin / Java code and native shared library files (.so). When the C / C++ code of the application needs to use the functions provided by the.so library, the C / C++ header file exposed by the.so library must be obtained and used at the same time. When the library engineering is packaged into AAR and published to the Maven warehouse through Gradle, the default construction process will only package the.so binary file into the AAR package, but will not include the corresponding header file. That is, the generated AAR package usually only has the jni directory (containing the.so file), but lacks the header file directory. This leads to the fact that if the application engineering that references the AAR library needs to use the.so library function, the header file must be manually copied into the reference engineering, and the header file search path must be configured in the CMake script, so that the native interface in the library can be successfully compiled and called.

[0003] The traditional manual copying of header files has the following main problems: first, every time the AAR library version is updated, if the header file of the library is changed, the header file needs to be manually copied repeatedly, which increases the development and maintenance workload; second, it is difficult to manually maintain the version consistency of the header file and the.so file, and if the versions are not matched, it is easy to cause errors during compilation, which brings additional burden to development. Therefore, there is an urgent need for a solution that can automatically include header files during construction and automatically extract header files during reference, so as to simplify the maintenance work and ensure the version consistency of the header file and the.so library. SUMMARY

[0004] In view of the problems existing in the prior art, the present application provides a method for automatically packaging header files and.so files and automatically referencing header files by Android Gradle, so as to automatically include header files during construction and automatically extract header files during reference, thereby avoiding the trouble of manually copying header files and ensuring the version consistency of the header file and the.so library.

[0005] In order to achieve the above purpose, the present application provides a method for automatically packaging header files and.so files and automatically referencing header files by Android Gradle, comprising the following steps: Step S1: In the library project, place the header files exposed by the so library in a directory; Step S2: In the Gradle build script of the library project, define a task to copy the header files, and configure it to be triggered before the build, so that the header files are copied to the resource directory; Step S3: In the process of executing the Gradle build and packaging the library project as an AAR file and uploading it to the Maven repository, the AAR file automatically includes the header file and the.so file; Step S4: In the reference end project, introduce the AAR file through the task written in the Gradle script, and perform the decompression operation after the dependency resolution is completed, copy the header file and the.so file in the AAR file to the local target directory; Step S5: In the Gradle build script, inject the decompressed header file path and.so file path into the build configuration parameters; Step S6: In the local build configuration file, use the parameters to set the header file search directory and the import location of the.so file, so that the reference end project can directly call the header file and link the.so file during compilation.

[0006] Preferably, in step S1, the header files exposed by the so library are stored in the include / yourlib directory for centralized management.

[0007] Preferably, the copy task in step S2 is a custom task copyHeadersToAssets, which is used to copy the files in the header file storage directory to the src / main / assets / headers / yourlib directory of the module.

[0008] Preferably, the custom task copyHeadersToAssets is configured to be automatically executed before the build through preBuilddependsOn, so that the task is executed first every time the Maven repository is built and uploaded, ensuring that the header files copied to the assets directory are packaged into the AAR file and uploaded to the Maven repository along with the AAR file.

[0009] Preferably, in step S3, the AAR file is uploaded to the remote Maven repository through the uploadArchives task or the publish task of Gradle after the build is completed.

[0010] Preferably, in step S4, the AAR file is introduced through the implementation configuration item in the Gradle dependency configuration block, and the local path thereof is automatically obtained after the AAR file is downloaded, and a decompression function is called to decompress the header file and the.so file in the AAR file to the specified target directory.

[0011] Preferably, after the decompression function is executed, the extracted header file path and.so file path are stored as extension properties of the Gradle script, respectively.

[0012] Preferably, in step S5, the Gradle build script injects the header file path and.so file path corresponding to the extension properties into the CMake build configuration through a build parameter passing mechanism.

[0013] Preferably, in step S6, the local build configuration file is a CMakeLists.txt file, the header file directory is configured through an include_directories command, and the import position of the.so file is set through an add_library and a set_target_properties command.

[0014] Preferably, when the library version in the Maven warehouse is updated, the reference end project only needs to modify the version number in the implementation dependency, and the corresponding version of the header file and.so file can be automatically obtained and updated, so as to ensure the version consistency of the header file and.so file.

[0015] The technical scheme of the present application has the following beneficial effects: The present application automatically copies and packs the header file required by the.so library into the AAR file during the build, and automatically decompresses the AAR and configures the header file path during the reference, thereby realizing the integrated management of the header file and the.so library. By using the present method, when updating the library version, only the version number of the dependency needs to be modified, and the latest header file and.so library can be automatically pulled and used, without manual copying, thereby avoiding the tedious operation of maintaining the corresponding version and significantly reducing the workload of the developer.

[0016] The present application automatically matches the versions of the header file and the.so library, and can effectively avoid the compilation error caused by inconsistent versions, thereby improving the reliability and maintenance efficiency of the build. Meanwhile, the present application uses a Gradle custom build task to automatically pack and upload the header file and.so file during the library publishing stage, and automatically decompresses the header file and.so file and configures them to the local build environment during the reference stage, so that the reference project can be directly used without additional manual intervention.

[0017] This invention automatically packages header files and .so files together when uploading an AAR file to Maven: before the AAR build task is executed during the Maven library upload, a custom task is inserted into the Gradle build process to copy the exposed header files to the assets directory, so that they will be packaged together into the AAR file during the AAR build.

[0018] When Gradle references a Maven library, the header files are manually parsed and obtained through a custom task: the Maven library is referenced through a custom implementation task, and the header files in the assets directory of the aar file are automatically copied to the specified directory of the referencing project after each library download. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the process of the present invention. Detailed Implementation

[0020] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0021] Reference Figure 1 This invention provides a method for automatically packaging header files and .so files using Android Gradle, as well as automatically referencing header files. The library project uses a custom task during Gradle build to copy the header files to the assets / headers directory and package them as an AAR file, which is then uploaded to the Maven repository. When the application project references the library, a Gradle script automatically unpacks the header files and .so files from the AAR file to the local machine and injects CMake build parameters for use by the local C / C++ code. The specific meaning of each step in the diagram will be explained in detail in the following embodiments.

[0022] The steps to automatically include header files when uploading a Maven repository are as follows: In the Android library project (LibraryModule), assuming the library name is "yourlib", all its exposed header files are placed in the include / yourlib / directory of the project directory. Then, define the following custom task in the module's buildgradle: TaskcopyHeadersToAssets(type:Copy){from'include / yourlib'into'src / main / assets / headers / yourlib'}preBuild.dependsOncopyHeadersToAssets With the above configuration, each time a build task (such as `assembleRelease` or `publish`) is executed, Gradle first executes the `copyHeadersToAssets` task, copying the header files under the `include / yourlib / ` directory to `src / main / assets / headers / yourlib / `. Since the Gradle build process packages the contents of the `src / main / assets` directory into the generated AAR package, the generated AAR will contain the `assets / headers / yourlib / ` directory and its header files. Subsequently, this AAR is uploaded to the remote Maven repository using the usual methods (e.g., executing `gradlew publish` or using the `uploadArchives` task).

[0023] Steps to automatically retrieve header files from a Maven library: Objective: When other projects reference this AAR, automatically extract its header files and `so` files for use by local CMake / NdkBuild.

[0024] Import and unzip the AAR using a task or hook written in a Gradle script: defextractHeadersAndSoFromAAR(FileaarFile,FiledestDir){ if (!aarFile.exists()) { ThrownewGradleException("AARfilenotfound:$aarFile") } copy{ FromzipTree(aarFile) include'assets / headers / **' include 'jni / **' IntodestDir } } dependencies{ implementation('com.example:yourlib:1.0.0'){ afterEvaluate{ defaarPath= Configurations.implementation.resolvedConfiguration.resolvedArtifacts.find{ It.moduleVersion.id.name=='yourlib' }?.file if(aarPath){ defextractDir=file("$buildDir / extracted / yourlib") extractHeadersAndSoFromAAR(aarPath,extractDir) ext . yourlibHeaderPath="$extractDir / assets / headers / yourlib" ext . yourlibSoPath="$extractDir / jni" } } } } The above logic explains that when the implementation executes the download of the Maven library, a custom task is configured after the download is complete. `extractHeadersAndSoFromAAR` is the custom task to be executed after the download is finished. This task accepts two parameters: the local file path of the AAR file and the directory where the extracted .so files and header files will be stored. The task first extracts the AAR file from the specified path and copies the files in the specified folder to the specified extraction directory. Here, `assets / headers / ` is the directory where the header files are stored, and `jni / ` is the directory where the .so files are stored. After extracting the header files and .so files, the directories where the extracted .so files and header files are stored are set to the `ext` property of the Gradle script for later use.

[0025] The Gradle dependency resolver retrieves the path to the downloaded AAR file (`aarFile`), then uses the `copy` and `zipTree` functions to decompress the AAR file, copying the `assets / headers / yourlib` and `jni` directories to the project's `build / extracted / yourlib` directory. Finally, the path to the decompressed header file directory is assigned to the Gradle extended property `yourlibHeaderPath`, and the path to the decompressed `.so` file directory is assigned to `yourlibSoPath` for later use. The Gradle script then injects the paths to the decompressed header file and `.so` files into CMake. externalNativeBuild{cmake{arguments"-DYOURLIB_HEADER_PATH=$yourlibHeaderPath","-DYOURLIB_SO_PATH=$yourlibSoPath"}} In this way, when executing the Gradle build, yourlibHeaderPath and yourlibSoPath will be passed as CMake parameters to the underlying CMake build script.

[0026] Finally, add the following configuration to the CMakeLists.txt file of your application project to use the extracted header files and .so libraries: include_directories(${YOURLIB_HEADER_PATH})add_library(yourlibSHAREDIMPORTED)set_target_properties(yourlib PROPERTIES IMPORTED_LOCATION${YOURLIB_SO_PATH} / armeabi-v7a / libyourlib.so) The `include_directories` directive adds the unzipped header file directory `${YOURLIB_HEADER_PATH}` to the C / C++ compiler search path. `add_library` defines an import library named `yourlib`, and `set_target_properties` sets the path to the shared library `.so` file for the corresponding architecture to the location of the import library. This example uses the armeabi-v7a architecture; if the library provides multiple ABI versions of `.so` files, other architectures can be specified accordingly in CMake.

[0027] With the above configuration, the CMake build of the referencing project can automatically find and use the header files and .so files of the yourlib library. If the version of the yourlib library is updated later, developers only need to modify the version number in the implementation dependency (e.g., update to 101), and Gradle will automatically download the new AAR and overwrite the existing files, eliminating the need to manually update the header files and thus simplifying maintenance.

[0028] It should be noted that the steps and parameter configurations in the above embodiments can be adjusted according to actual needs. For example, AAR upload can be accomplished using different Gradle plugins or scripts; when obtaining the AAR file path, similar processing can be performed on local AAR files (using implementationfiles('path / to / yourlibaar')). Furthermore, the variable names used in the embodiments, such as yourlibHeaderPath and yourlibSoPath, are merely examples; in actual use, they can be named according to project naming conventions. As long as the spirit of the technical solution of this invention is not departed, the scope of protection of this invention is defined by the appended claims and their equivalents.

[0029] The above description is merely a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention's specification and drawings under the inventive concept of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A method for automatically packaging header files and .so files and automatically including header files using Android Gradle, characterized in that, Includes the following steps: Step S1: In the library project, place all the header files exposed by the .so library in one directory; Step S2: Define a task to copy header files in the Gradle build script of the library project and configure it to be triggered before the build, so that the header files are copied to the resource directory; Step S3: During the Gradle build process, when the library project is packaged into an AAR file and uploaded to the Maven repository, the AAR file is made to automatically include the header file and the .so file; Step S4: In the referencing project, import the AAR file through the task written in the Gradle script, and perform the decompression operation after the dependency resolution is completed, copying the header file and .so file in the AAR file to the local target directory; Step S5: In the Gradle build script, inject the paths to the unzipped header files and .so files into the build configuration parameters; Step S6: In the local build configuration file, use the parameters to set the header file search directory and the import location of the .so file, so that the referencing project can directly call the header file and link the .so file during compilation.

2. The method for automatically packaging header files and .so files and automatically including header files in Android Gradle according to claim 1, characterized in that, In step S1, the header files exposed by the so library are stored in the include / yourlib directory for centralized management.

3. The method according to claim 1, characterized in that, The copy task in step S2 is a custom task copyHeadersToAssets, which is used to copy the files in the header file storage directory to the module's src / main / assets / headers / yourlib directory.

4. The method for automatically packaging header files and .so files and automatically including header files using Android Gradle according to claim 1, characterized in that, The custom task copyHeadersToAssets is configured to be executed automatically before the build by preBuilddependsOn. This ensures that the task is executed first every time the build uploads to the Maven repository, thus guaranteeing that the header files copied to the assets directory are packaged into the AAR file and uploaded to the Maven repository along with the AAR file.

5. The method according to claim 1, characterized in that, In step S3, the AAR file is uploaded to a remote Maven repository via Gradle's uploadArchives task or publish task after the build is completed.

6. The method for automatically packaging header files and .so files and automatically including header files in Android Gradle according to claim 1, characterized in that, In step S4, the AAR file is imported by the implementation configuration item in the Gradle dependency configuration block, and its local path is automatically obtained after the AAR file is downloaded. The decompression function is then called to decompress the header file and .so file in the AAR file to the specified target directory.

7. The method according to claim 6, characterized in that, After the decompression function is executed, the extracted header file path and .so file path are stored as extended attributes of the Gradle script.

8. The method according to claim 1, characterized in that, In step S5, the Gradle build script injects the header file path and .so file path corresponding to the extended attributes into the CMake build configuration through the build parameter passing mechanism.

9. The method for automatically packaging header files and .so files and automatically including header files in Android Gradle according to claim 1, characterized in that, In step S6, the local build configuration file is a CMakeLists.txt file. The header file directory is configured using the include_directories command, and the import location of the .so file is set using the add_library and set_target_properties commands.

10. The method for automatically packaging header files and .so files and automatically including header files using Android Gradle according to any one of claims 1 to 9, characterized in that, When the library version in the Maven repository is updated, the referencing project only needs to modify the version number in the implementation dependency. It can automatically obtain and update the corresponding version of the header file and .so file, ensuring that the header file and .so file versions are consistent.

Images