Method for automatically backing up so symbol file when Android packages aar

Abstract

The invention discloses a method for automatically backing up a so symbol file when Android packages aar, which comprises the following steps of: after an Android library project executes a construction task of packaging to generate an aar file, automatically triggering a backup task for backing up the so symbol file generated by the construction; the backup task sequentially creates backup directories according to a predefined hierarchical directory structure, and the directory structure sequentially comprises a root directory, a module name directory, a Maven coordinate directory, a version number directory, a construction number directory and a symbol table subdirectory; the dynamic library file with the suffix being '. So' and the corresponding symbol table file with the suffix being '. Sym' generated in the construction are obtained from a project construction product catalog, and the symbol files are copied to the symbol table subcatalog in the backup catalog to form a symbol file backup corresponding to the construction; and verifying the existence state of the backup directory and a symbol file copying result in the directory creation and file copying process.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Android application development and construction, and particularly relates to a method for automatically backing up so symbol files during Android aar packaging. BACKGROUND

[0002] In the prior art, there are documents that attempt to use Gradle scripts to automatically configure the packaging process of mobile applications. For example, Chinese patent document CN118519673A discloses a method for realizing mobile terminal multi-channel packaging based on a Gradle script. The core idea of this method is to define product flavors through a Gradle script, set placeholders to replace different channel identifiers, load corresponding dependency packages and resource files according to the channel, and finally generate APK files corresponding to the distribution channel, so as to realize the automatic packaging and differentiated configuration of multi-channel APK. The core logic of this technical solution revolves around channel differentiation configuration (such as application identifiers, dependency packages, resource files, etc.), mainly solving the problems of multi-channel package generation efficiency and configuration management, but it does not involve the backup function of so symbol files, and cannot meet the demand for precise positioning of so file crashes. There is a clear difference between the technical scenarios and goals of this solution and the symbol table backup.

[0003] In Android engineering practice, when a library project is packaged to generate an aar file, so symbol files usually only exist in the intermediate product directory generated by the build (such as the obj directory output by the C / C++ build tool), and are not automatically archived or versioned after the build is completed. With subsequent version iterations, performing a clean build, or the continuous integration environment regularly cleaning the build directory, these symbol table files are often deleted or overwritten. When a user reports a crash related to so in a published version, due to the lack of a symbol table file that completely corresponds to this version, it is not possible to use tools such as addr2line to resolve the memory address in the crash stack to a specific source code line number, resulting in a long problem troubleshooting period and high difficulty in positioning, which is not conducive to the maintenance of product stability. As can be seen, the prior art still lacks a technical solution that automatically and versionally backs up so symbol files generated during the packaging process without affecting the normal packaging process of aar, so as to ensure that the symbol table of each aar version is traceable and convenient for subsequent crash positioning, which needs to be further improved. SUMMARY

[0004] In view of the problems existing in the prior art, the present application provides a method for automatically backing up so symbol files during Android aar packaging.

[0005] In order to achieve the above-mentioned purpose, the present application provides a method for automatically backing up so symbol files during Android aar packaging, comprising the following steps: Step S1, after the build task of packaging the Android library project to generate aar file is completed, a backup task is triggered automatically to backup the so symbol files generated in this build; Step S2, the backup task creates backup directories in turn according to a predefined hierarchical directory structure, which includes root directory, module name directory, Maven coordinate directory (composed of group name and artifact name), version number directory, build number directory and symbol table subdirectory in turn; Step S3, the so dynamic library file with suffix “.so” and its corresponding symbol table file with suffix “.sym” generated in this build are obtained from the project build product directory, and the symbol table file is copied to the symbol table subdirectory in the backup directory to form the symbol file backup corresponding to this build; Step S4, during the directory creation and file copying process, the existence state of the backup directory and the symbol file copying result are checked, and abnormal handling operation is performed when abnormal condition is detected to ensure the integrity and availability of the symbol file backup.

[0006] Preferably, the build task is executed by Gradle build tool, the backup task is defined in the build script file build.gradle of the Android library project, and the custom backup task is bound to the assembleRelease task for generating aar file by using doLast hook, so that the backup task is automatically executed after the assembleRelease task is completed.

[0007] Preferably, in step S2, the hierarchical directory structure specifically includes: the first layer directory as the root backup directory; the module name directory named by the Android library module name, as the second layer directory under the root backup directory; the Maven coordinate directory named by the Maven coordinate (identification string formed by splicing group name and artifact name) of the library module, as the third layer directory under the module name directory; the version number directory named by the version number of the library module, as the fourth layer directory under the Maven coordinate directory; the build number directory named by the build number, as the fifth layer directory under the version number directory; the symbol table subdirectory set under the build number directory for storing the so file and the.sym symbol table file.

[0008] Preferably, in the step S3, the source directory of the symbol file is an obj subdirectory output by CMake compilation in the project build product directory, and the symbol table subdirectory is an obj symbol table subdirectory in the build number directory corresponding to the current build number in the hierarchical backup directory created in the step S2, and the symbol file in the source directory is copied into the symbol table subdirectory.

[0009] Preferably, in the step S4, the existence of the target backup directory is checked, including: when it is detected that the target backup directory path exists and is a file, the file is deleted, and the target backup directory and the symbol table subdirectory thereof are re-created according to the predefined hierarchical directory structure; when it is detected that the target backup directory path exists and is a directory, the existing content in the directory is emptied, and the directory is re-created as an empty directory to avoid interference of the old backup file with the current backup; when it is detected that the target backup directory path does not exist, the complete backup directory and the symbol table subdirectory thereof are directly created according to the predefined hierarchical directory structure.

[0010] Preferably, in the step S3, when the symbol files to be copied are selected from the symbol file source directory, only the dynamic library files with the extension.so and the symbol table files with the extension.sym are selected as the copying objects by judging the file extensions, and the files selected by the above filtering are copied into the symbol table subdirectory.

[0011] Preferably, the exception handling operation in the step S4 includes: when the creation of the backup directory or any upper directory thereof fails, a runtime exception is thrown, and the absolute path information of the failed directory is output to prompt the backup directory creation failure; when the symbol file copying is performed, if it is detected that the source file does not exist, the access permission is insufficient, or the copying operation returns failure, a runtime exception is thrown, and the source directory path and the target directory path of the failure are recorded to prompt the symbol file copying failure.

[0012] Preferably, the build number is an identifier for distinguishing different build records, and the build number is generated by a timestamp, a build serial number, or a combination of the two when the current build is triggered, and is used as the naming basis of the build number directory in the hierarchical directory structure to realize the differentiated storage and tracing of the symbol file backups corresponding to different builds.

[0013] Preferably, when a so file of a certain version crashes during running, the following steps are included: according to the aar version number recorded in the crash log and the build number corresponding thereto, the symbol table subdirectory in the build number directory corresponding to the version number and the build number in the hierarchical backup directory is located. extracting.so files and.sym symbol table files corresponding to the crash so files from the symbol table subdirectory; calling the addr2line tool provided in the Android NDK, taking the extracted symbol table files and the memory addresses in the crash stack as inputs, to parse the source code file path and line number corresponding to the crash, so as to complete the positioning of the crash problem.

[0014] Preferably, when the symbol files are copied in step S3, a cross-platform file copying mechanism provided by the build system is used to perform the copying operation from the symbol file source directory to the symbol table subdirectory, so that the automatic backup of the symbol files can be completed in the same way under different operating system environments such as Windows, Linux and macOS.

[0015] In the present application, aar is the abbreviation of Android Archive, which is the library file format of the Android platform, containing the code, resources, so files and the like required by the Android application.

[0016] so file: the abbreviation of Shared Object, which is the dynamic link library file of the Android platform, containing the functions implemented by native code.

[0017] Symbol table file: a file that stores the mapping relationship between symbols such as functions and variables in the so file and the corresponding memory address, usually with the.sym suffix, used for crash problem positioning.

[0018] Gradle: a build tool for Android projects, supporting customization of build processes and tasks through scripts. addr2line: a program in the NDK toolset, used to convert the memory address of the so file to the corresponding source code line number, to assist in crash positioning.

[0019] The technical solution of the present application has the following beneficial effects: Firstly, based on the existing build process of packaging the Android library project to generate the aar file, the present application introduces an automatic backup task in the Gradle build life cycle, which automatically triggers the backup of the so symbol files generated in this build after the build task for generating the aar file is completed, without the need for the developer to manually perform copying or archiving operations. In this way, the symbol file backup work can be fixed as part of the build process without changing the original aar packaging process, significantly reducing the risk of missing symbol table files due to human negligence and ensuring that the corresponding symbol file backup will be generated synchronously every time the aar is successfully built.

[0020] Secondly, the application organizes the backup directory through a pre-defined hierarchical directory structure, and the backup path comprises a root directory, a module name directory, a Maven coordinate directory, a version number directory, a build number directory and a symbol table subdirectory in sequence, so as to fix the library module identification information, the release coordinate information, the version information and the build information in the directory path at the same time, and store the.so file and the.sym symbol table file generated in the current build in the symbol table subdirectory. With the hierarchical version storage mode, the corresponding symbol file backup of a specific build can be quickly and accurately located according to the module name, the Maven coordinate, the version number and the build number in the case of multiple modules, multiple Maven coordinates, multiple versions and multiple builds of the same version, the mixed use of symbol files between different builds is avoided, and the orderliness and traceability of symbol file management are significantly improved.

[0021] Thirdly, in the process of creating a backup directory and copying a symbol file, the existence state of the target backup directory and the file copying result are checked, and a runtime exception is thrown and the failure directory or the source / destination path information is recorded when an exception is detected. For the three cases that the target path already exists and is a file, the target path already exists and is a directory, and the path does not exist, the application adopts the processing strategies of deleting and rebuilding, emptying and rebuilding and newly creating respectively, so as to ensure that the target directory is in a clean state as expected before each backup; when the symbol file copying fails, the source file does not exist or the access permission is insufficient, the problem can be directly exposed through an exception. The mechanism avoids the hidden fault that the build seems to be successful but the symbol is not actually backed up, improves the reliability and monitorability of the symbol backup process, and provides a reliable data basis for subsequent crash positioning.

[0022] In addition, the application uses the cross-platform file copying mechanism provided by the build system to copy only the dynamic library file with the.so extension and the symbol table file with the.sym extension from the build product directory output by C / C++ compilation to the target symbol table subdirectory, so as to ensure the pertinence of the backup content and avoid the introduction of irrelevant intermediate files. The copying mechanism can work in the same way in different operating system environments such as Windows, Linux and macOS, which facilitates unified deployment in local development environments and continuous integration environments, and realizes good cross-platform compatibility of the symbol backup scheme.

[0023] Finally, the present application realizes one-to-one mapping between the runtime crash log and the symbol file backup by explicitly introducing the build number in the symbol backup directory and combining the aar version number and the build number recorded in the crash log. When a certain version of so file crashes during running, the corresponding symbol table subdirectory under the build number directory can be quickly located according to the version number and the build number in the crash log, the matching.so file and.sym symbol table file are extracted therefrom, and the memory address in the crash stack is parsed into the specific source code file path and line number by using the addr2line tool, so as to accurately locate the crash position. Compared with the existing scheme which lacks a unified symbol backup mechanism and is difficult to obtain a matching symbol table, the present application builds a complete closed loop of "build product-symbol backup-crash log-source code line number", significantly shortens the crash problem troubleshooting period, reduces the maintenance cost, and improves the product stability and development and operation efficiency.

[0024] Compared with the method for realizing mobile terminal multi-channel packaging based on the Gradle script disclosed in the Chinese patent document CN118519673A, the present application has essential differences in the technical scene and solution target. The present application does not focus on the generation of multi-channel APK, but aims at the scene of packaging the Android library project to generate aar file, automatically triggers a backup task after the build task for generating aar file is completed without affecting the original packaging process, creates a backup directory according to the predefined hierarchical directory structure of "root directory-module name-Maven coordinates-version number-build number-symbol table subdirectory", selects the dynamic library file with the extension.so and the symbol table file with the extension.sym from the build product directory of C / C++ compilation output, copies them into the symbol table subdirectory corresponding to the current build number, and checks and handles exceptions of the backup directory state and file copy result. In this way, the present application realizes automatic and versioned backup of so symbol files on the one hand, ensuring that each aar version has traceable symbol table records; on the other hand, when a certain version crashes during application running, the corresponding symbol table subdirectory can be quickly located according to the version number and the build number in the crash log, the matching.so file and.sym symbol table file are extracted, and the crash address is accurately mapped to the source code file and line number by using the addr2line tool, so as to significantly shorten the crash troubleshooting time and improve the accuracy and maintenance efficiency of local code crash positioning. These technical effects are not possessed by the compared patent. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 The present application is a method flowchart. DETAILED DESCRIPTION

[0026] The present application is further described below in conjunction with the drawings and specific embodiments.

[0027] Reference Figure 1 This invention provides a method for automatically backing up .so symbol files when packaging an Android AAR file, applied to the construction process of an Android library project. Specifically, the Gradle build tool is used in the Android library project to compile and package the library module to generate an AAR file. After the build task for generating the AAR file is completed, a backup task is automatically triggered. The backup task is a custom task defined in the build script file `build.gradle` of the library module. By configuration, this custom task is executed after the `assembleRelease` task is completed, thus automatically performing the symbol file backup operation after each successful packaging of the corresponding version of the AAR file without changing the original packaging process. Through this backup task, the .so symbol files generated during the current build process can be uniformly backed up, avoiding the problem of manual copying by developers or loss of symbol files due to the cleanup of the build artifact directory, thereby ensuring that the native library symbol information corresponding to each AAR version can be preserved for a long time. In the specific implementation, the following example code can be written in the `build.gradle` script to implement the construction of the backup directory path, the determination of the source directory and the target directory, and task binding: def artifactsBackupDirPath = "artifacts_backup / module_name / com.tencentcs.artifactid / 1.0.0" def BUILD_NUMBER = "20230801_1234" / / Build number (can be configured as a timestamp or serial number) / / Symbol table source directory (CMake compilation artifact directory) File srcSymbolDir=file("${project.buildDir} / intermediates / cmake / release / obj") / / Symbol table target backup directory (versioned hierarchy directory) File destSymbolDir=file("${artifactsBackupDirPath} / ${BUILD_NUMBER} / obj") / / Bind to the AAR packaging task, perform backup after packaging is complete. afterEvaluate { project.tasks.findByName('assembleRelease')?.doLast { / / Stage 1: Directory pre-processing and validation if (destSymbolDir.exists()) { if (!destSymbolDir.isDirectory()) { destSymbolDir.delete() if (!destSymbolDir.mkdirs()) { throw new RuntimeException("Target backup directory creation failed: ${destSymbolDir.absolutePath}") } } else { FileUtils.deleteFile(destSymbolDir) if (!destSymbolDir.mkdirs()) { throw new RuntimeException("Target backup directory cleanup and recreation failed: ${destSymbolDir.absolutePath}") } } } else { if (!destSymbolDir.mkdirs()) { throw new RuntimeException("Target backup directory creation failed: ${destSymbolDir.absolutePath}") } } / / Stage 2: Perform symbol table file copy def copyResult = project.copy { from srcSymbolDir into destSymbolDir include '** / *.so' include '** / *.sym' } / / Stage 3: Copy result validation if (!copyResult) { throw new RuntimeException("Symbol table file copy failed, source directory: ${srcSymbolDir.absolutePath}, target directory: ${destSymbolDir.absolutePath}") } } } When the above backup task is executed, a backup directory is first created in a predefined hierarchical directory structure, which includes a root directory, a module name directory (module_name), a Maven coordinate directory (composed of a group name and an artifact name), a version number directory, a build number directory, and a symbol table subdirectory in sequence. Specifically, the root directory can be a backup root path used to centrally store symbol backups; under the root directory, a module name directory is created with the name of the current Android library module as the directory name, which is used to distinguish the backup information of different library modules; under the module name directory, a Maven coordinate directory is created with the Maven coordinate of the library module, which is used to distinguish the builds of the same module under different release coordinates, such as com.tencentcs.artifactid; under the Maven coordinate directory, a version number directory is created with the version number of the library module, which is used to distinguish builds of different versions; under the version number directory, a build number directory is created with the build number corresponding to this build, which is used to distinguish different build records, and can be generated by combining the timestamp, build serial number, or combination of the two when the current build is triggered, and used as the naming basis for the build number directory to achieve differentiated storage and tracing of symbol file backups corresponding to different builds; finally, a symbol table subdirectory is created under the build number directory, which is used to store the so file and its.sym symbol table file corresponding to the build, and in this embodiment, the symbol table subdirectory can be named obj or other names that can identify the purpose of the symbol file. Through the above hierarchical directory structure, the symbol files can be stored in a versioned manner in the form of "root directory / module name / Maven coordinate / version number / build number / symbol table subdirectory", so that subsequent symbol file backups of corresponding versions can be quickly located based on the module, version number, and build number.

[0028] After the creation of the backup directory is completed, the eligible symbol files generated in this build are obtained from the project build product directory and copied to the symbol table subdirectory to form a backup of the symbol files corresponding to this build. Specifically, for an Android library project using CMake for native library compilation, the so file and its symbol table file are usually output in the obj subdirectory generated by CMake compilation under the project build directory, which is a centralized directory for storing so files and related intermediate files of each CPU architecture. In this embodiment, the obj subdirectory output by CMake compilation is used as the source directory of the symbol files, and the file list is traversed in the source directory and its subdirectories, and the symbol files to be copied are filtered by judging the file extension, and only the dynamic library files with the extension “.so” and the symbol table files with the extension “.sym” are selected as the copy objects to avoid copying irrelevant intermediate files. For the.so files and.sym files obtained by filtering, a cross-platform file copying mechanism provided by the build system is used to copy them from the symbol file source directory to the symbol table subdirectory in the aforementioned hierarchical backup directory, so that the automatic backup of the symbol files can be completed in the same way under different operating system environments such as Windows, Linux and macOS. After the above copying is completed, the so symbol files corresponding to the current build are versioned and saved in the symbol table subdirectory corresponding to the build number.

[0029] In the directory creation and file copying process, the embodiment also checks the existence state of the backup directory and the result of the symbol file copying, and performs exception handling operation when detecting abnormal situation, to ensure the integrity and availability of the symbol file backup. Specifically, before creating the target backup directory, first detect whether the target backup directory path already exists and its type: when detecting that the target backup directory path already exists and is a file, it means that there is a file with the same name as the directory on the path, which does not match the current backup requirement, at this time, delete the file, and re-create the target backup directory and its symbol table subdirectory according to the predefined hierarchical directory structure; when detecting that the target backup directory path already exists and is a directory, it means that there may be old backup content before, in order to avoid interference of the old backup file to this backup, empty the existing content in the directory, and rebuild it as an empty directory, and then create the lower symbol table subdirectory when needed; when detecting that the target backup directory path does not exist, then directly create the complete backup directory and its symbol table subdirectory according to the predefined hierarchical directory structure. When performing the above directory creation or cleaning operation, if the directory or any upper directory creation fails, the embodiment throws a runtime exception and outputs the absolute path information of the failed directory to prompt the backup directory creation failure, so as to facilitate the developer to find and handle in time. When performing the symbol file copying operation, when detecting that the source file does not exist, the access permission is insufficient, or the copying operation returns failure, etc. Abnormal situation, also throw a runtime exception, and record the failed source directory path and target directory path to prompt the symbol file copy failure. Through the above exception handling mechanism, the problem that the system still mistakenly thinks that the symbol file has been successfully backed up in the case of backup failure is avoided, thereby improving the reliability of the backup result.

[0030] In the embodiment, the build number is used as an identifier to distinguish different build records, which is generated according to the timestamp when the current build is triggered, the build serial number or the combination of the two at the beginning of each build, for example, the date and time string can be spliced with the incremental serial number to form a build number string, and the string is used as the name of the build number directory. With the execution of different builds, different build number directories will be created under the corresponding module name directory, Maven coordinate directory and version number directory in turn, and each build number directory has its own symbol table subdirectory for storing the.so file and.sym symbol table file of this build, thereby realizing the differentiated storage and tracing of the symbol file backup corresponding to different builds. When subsequent positioning of a crash problem of a historical build is needed, the symbol table subdirectory corresponding to the crash can be accurately located according to the version number and build number corresponding to the crash, so as to extract the symbol file completely matching the build version.

[0031] In the application running process, when a version of so file crashes, the embodiment uses the aforementioned symbol file backup to complete the crash positioning. Specifically, when the system or log platform records a crash event, the aar version number used when the crash occurs and the corresponding build number are usually recorded, and the crash stack information is also recorded, including the memory address triggering the crash and the like. In the crash analysis, according to the aar version number and the build number recorded in the crash log, the build number directory corresponding to the version number and the build number in the hierarchical backup directory is located, and then the.so file and the.sym symbol table file corresponding to the crashed so file are extracted from the symbol table subdirectory. Then, the addr2line tool provided in the Android NDK is called, and the extracted symbol table file and the memory address in the crash stack are taken as inputs. The addr2line tool can parse the crash address into the corresponding source code file path and line number based on the symbol table. The developer can quickly determine the specific source file and code location where the crash occurs, significantly shorten the crash troubleshooting time and improve the problem positioning efficiency. Through the above embodiment, the method of the present application realizes the automatic and versioned backup of so symbol files without changing the original aar build process, and establishes a tracing mechanism combined with the crash log information, effectively solving the technical problems that the symbol files are easily lost and the crash problem is difficult to locate in the traditional technology.

[0032] The above description is only the preferred embodiment of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields, or the like made under the inventive concept of the present application, using the content of the present application specification and drawings, is included in the patent protection scope of the present application.

Claims

1. A method for automatically backing up .so symbol files when packaging an Android AAR file, characterized in that, Includes the following steps: Step S1: After the Android library project completes the build task to package and generate aar files, a backup task is automatically triggered to back up the so symbol files generated in this build. Step S2: The backup task creates a backup directory in sequence according to a predefined hierarchical directory structure, which includes a root directory, a module name directory, a Maven coordinates directory, a version number directory, a build number directory, and a symbol table subdirectory. Step S3: Obtain the dynamic library file with the ".so" extension and its corresponding symbol table file with the ".sym" extension generated in this build from the project build artifact directory, and copy the above symbol file to the symbol table subdirectory in the backup directory to form a symbol file backup corresponding to this build; Step S4: During the directory creation and file copying process, the existence status of the backup directory and the result of symbol file copying are verified. If an anomaly is detected, an exception handling operation is performed to ensure the integrity and availability of the symbol file backup.

2. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S1, the build task is executed by the Gradle build tool. The backup task is defined as a custom task in the build script file build.gradle of the Android library project, and the custom backup task is bound to the assembleRelease task used to generate aar files by using the doLast hook, so that the backup task is automatically executed after the assembleRelease task is completed.

3. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S2, the hierarchical directory structure specifically includes: As the first-level directory of the root backup directory; The module name directory, named after the Android library module name, serves as the second-level directory under the root backup directory; The Maven coordinates directory, named after the Maven coordinates of the library module, serves as the third-level directory under the module name directory; The version number directory, named after the library module version number, serves as the fourth-level directory under the Maven coordinate directory. The build number directory, named after the build number, serves as the fifth-level directory under the version number directory. A symbol table subdirectory is set up under the build number directory to store the .so files and the .sym symbol table files.

4. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S3, the source directory of the symbol file is the obj subdirectory output by CMake in the project build artifact directory, and the symbol table subdirectory is the obj symbol table subdirectory under the build number directory corresponding to the current build number in the hierarchical backup directory created in step S2. The symbol file in the source directory is copied to the symbol table subdirectory.

5. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S4, verifying the existence status of the target backup directory includes: When the target backup directory path is detected to already exist and is a file, delete the file and recreate the target backup directory and its symbol table subdirectory according to the predefined hierarchical directory structure; When the target backup directory path is detected to already exist and is a directory, clear the existing contents of the directory and rebuild it as an empty directory to avoid old backup files interfering with this backup. When the target backup directory path is detected to be non-existent, a complete backup directory and its symbol table subdirectory are created directly according to the predefined hierarchical directory structure.

6. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S3, when filtering symbol files to be copied from the symbol file source directory, the file extension is determined, and only dynamic library files with the extension .so and symbol table files with the extension .sym are selected as the copying objects, and the selected files are copied to the symbol table subdirectory.

7. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: The exception handling operation in step S4 includes: If the creation of the backup directory or any of its parent directories fails, a runtime exception is thrown and the absolute path of the failed directory is output to indicate that the backup directory creation failed. When performing symbol file copying, if the source file is detected as non-existent, access permissions are insufficient, or the copying operation returns as a failure, a runtime exception is thrown and the source directory path and target directory path of the failure are recorded to indicate that the symbol file copying failed.

8. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S2, the build number is an identifier used to distinguish different build records. The build number is generated by the timestamp when the current build is triggered, the build serial number, or a combination of both, and serves as the naming basis for the build number directory in the hierarchical directory structure, so as to realize the distinguished storage and traceability of symbol file backups corresponding to different builds.

9. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: When a version of a .so file crashes during runtime, the following steps are involved: Based on the AAR version number and its corresponding build number recorded in the crash log, locate the symbol table subdirectory under the build number directory corresponding to the version number and build number in the hierarchical backup directory; Extract the .so file and .sym symbol table file corresponding to the crashed .so file from the symbol table subdirectory; The addr2line tool provided in the Android NDK is called, and the extracted symbol table file and the memory address in the crash stack are used as input to parse out the source code file path and line number corresponding to the crash, so as to complete the location of the crash problem.

10. The method for automatically backing up .so symbol files when packaging an Android AAR file according to claim 1, characterized in that: In step S3, when copying the symbol file, the cross-platform file copying mechanism provided by the building system is used to perform the copying operation from the source directory of the symbol file to the symbol table subdirectory, so that the automatic backup of the symbol file can be completed in the same way in different operating system environments such as Windows, Linux and macOS.

Images