An extension module processing method and system for an Android system

Abstract

The application provides an extension module processing method and system for an Android system, which comprises the following steps: when a target Android system is started and a package management service execution system is ready, all installed application packages are traversed, and it is judged whether an extension module identification key or a framework identification key is contained in the metadata of the application packages, to obtain a judgment result, and write the complete path of the corresponding application package into a corresponding list file; a listener is registered in the package management service execution system, the application installation or uninstallation signal is listened to through the listener, a listening result is obtained, and the complete path of the corresponding application package is processed according to the listening result, to obtain a processing result; when any application is started, a class loader is created according to the processing result, and all plug-in frameworks in the list file are loaded through the class loader after the plug-in frameworks are initialized.

Description

Technical Field

[0001] This invention relates to the field of Android operating system management technology, and in particular to a method and system for processing extension modules in an Android system. Background Technology

[0002] In Android systems, to implement system-level feature extensions or modify application behavior, it is usually necessary to modify the system source code and recompile and flash the firmware, or replace system files with root privileges. This approach has many inconveniences: 1. The development cycle is long, and each modification requires a complete system recompile; 2. Poor flexibility; unable to dynamically load and unload functional modules; 3. High maintenance costs; all modifications need to be re-adapted when the system is upgraded.

[0003] Currently, there are several dynamically extended frameworks on the market, such as the X-posed framework. X-posed is a framework service that can affect program execution (i.e., modify the system) without altering the installation package file format. It achieves runtime message processing functionality by modifying the Zygote process and the ART virtual machine. The general implementation method in existing technologies is as follows: 1. Modify the Zygote process during system startup to inject framework code; 2. When the application starts, the framework scans for module installation package file formats in a specific directory; 3. Load module code through the class loader and perform information processing operations.

[0004] However, in the process of researching and practicing existing technologies, the following shortcomings were found: Inadequate module management: Existing solutions typically scan file directories directly, lacking integration for managing application packages, resulting in the inability to synchronize module status in a timely manner during installation, uninstallation, and updates; The installation process is incomplete: After users install the module's installation package file format, they need to manually restart the system or enable it in the framework interface, which is complicated and easy to miss. High performance overhead: Each time the application starts, it needs to scan the file system and parse the metadata of the installation package file format, which increases the application startup time; Lack of version management: The framework cannot effectively manage module version information and dependencies, which can easily lead to compatibility issues; Lack of security mechanisms: Existing solutions typically use plaintext to store the module list, configuration files can be easily tampered with, and there is a lack of signature verification mechanisms. Malicious applications can forge metadata identifiers to inject malicious code, posing serious security risks. Lack of auditing capabilities: There is no sound operation log recording mechanism, and key operations such as module installation, uninstallation, activation, and disabling cannot be traced, failing to meet the compliance requirements of enterprise-level deployment; Weak access control: Ordinary applications may tamper with module configurations through file permission vulnerabilities or root privileges, lacking hardware-based security protection mechanisms, and with non-standard key management. Summary of the Invention

[0005] This invention provides a method and system for processing extension modules in the Android system. Its purpose is to reduce file scanning overhead during application startup and improve system performance by injecting custom functions into all running apps.

[0006] To achieve the above objectives, the present invention provides a method for processing extension modules in an Android system, comprising: Step 1: When the target Android system starts up and the package management service is ready, iterate through all installed application packages and check the metadata in each application package. Step 2: For each application package, determine whether the metadata of the application package contains an extension module identifier key or a framework identifier key, obtain the determination result, and write the full path of the corresponding application package into the corresponding list file according to the determination result; Step 3: Register a listener in the package management service execution system, listen for application installation or uninstallation signals through the listener, obtain the listening results, and process the full path of the corresponding application package according to the listening results to obtain the processing results; Step 4: When any application starts, a class loader is created based on the processing result, and after the plugin framework is initialized, the plugins in all the list files are loaded through the class loader.

[0007] Furthermore, based on the judgment result, the full path of the corresponding application package is written to the corresponding list file, including: When the determination result is that the application package's metadata contains an extension module identifier key, the full path of the application package is written to the module list file; If the determination result indicates that the application package's metadata contains a framework identifier key, the full path of that application package is written to the framework list file.

[0008] Furthermore, the full path to the application package is written to the module list file, including: Convert the full path of the application package into a structured data format to obtain a data object; The data object is then written to the module list file after being subjected to advanced encryption using an Android key.

[0009] Furthermore, the outermost layer of the data object contains an array of modules and a timestamp field for the last update; Each module object in the module array contains the package name, application package path, version number, version name, signature hash, installation timestamp, enabled status, and minimum framework version requirement.

[0010] Furthermore, after using Android keys to perform advanced encryption on the data objects, they are written to the module list file, including: When the target Android system boots for the first time, several sets of keys are generated by the key generator and stored in the Android key storage. Add a message authentication code signature field to the data object to obtain the data object with the message authentication code signature field added. In the Android key storage, select any set of keys to sign the key fields in the data object after adding the message authentication code signature field, and then write it to the module list file.

[0011] Furthermore, based on the monitoring results, the full path of the corresponding application package is processed to obtain the processing results, including: When the monitoring result indicates that the application is uninstalled, delete the full path of the application package of that application; When the monitoring result indicates that an application is being installed, the application package data of the new application is obtained, and the data identifier key type in the application package data is checked. The type of the new application is determined based on the data identifier key type, and the full path corresponding to the new application is written to the corresponding list file based on the type of the new application.

[0012] Furthermore, a class loader is created based on the processing results, including: Based on the processing results, an application context is created. During the creation of the application context, if the required loading flag is true, the path of the framework application package is obtained by reading the framework list file. A class loader is created using the path to the framework application package. The first parameter of the class loader is the path to the application package file, and the second parameter specifies the parent loader.

[0013] The present invention also provides an extension module processing system for the Android system, comprising: The scanning module is used to traverse all installed application packages and check the metadata in each application package when the target Android system starts up and the package management service is ready. The judgment module is used to determine whether the metadata of each application package contains an extension module identifier key or a framework identifier key, obtain the judgment result, and write the full path of the corresponding application package into the corresponding list file based on the judgment result; The listening module is used to register listeners in the package management service execution system. The listeners listen for application installation or uninstallation signals, obtain the listening results, and process the full path of the corresponding application package based on the listening results to obtain the processing results. Create a module that, when any application starts, creates a class loader based on the processing results, and loads plugins from all list files through the class loader after initializing the plugin framework.

[0014] The above-described solution of the present invention has the following beneficial effects: Compared with existing technologies, this invention, when the target Android system starts and the package management service execution system is ready, iterates through all installed application packages and checks the metadata in each application package. For each application package, it determines whether the metadata of the application package contains an extension module identifier key or a framework identifier key, obtains the judgment result, and writes the full path of the corresponding application package into the corresponding list file according to the judgment result. A listener is registered in the package management service execution system to listen for application installation or uninstallation signals, obtains the listening result, and processes the full path of the corresponding application package according to the listening result to obtain the processing result. When any application starts, a class loader is created according to the processing result, and after initializing the plugin framework, the class loader loads the plugins in all list files. Compared with existing technologies, this invention avoids the repetitive overhead of scanning the file system and parsing application package metadata every time an application starts, significantly reducing application startup time and improving overall system performance. Registering a listener in the package management service execution system to listen for application installation or uninstallation signals allows for custom function injection for all running apps, avoiding inconsistencies such as modules being uninstalled but still loaded, or modules being installed but not effective.

[0015] Other beneficial effects of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an embodiment of the present invention. Detailed Implementation

[0017] To make the technical problems, solutions, and advantages of this invention clearer, a detailed description will be provided below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0018] In the description of this invention, it should be noted that the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0019] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0020] This invention addresses existing problems by providing a method and system for processing extension modules in the Android system.

[0021] like Figure 1 As shown, an embodiment of the present invention provides a method for processing extension modules in an Android system, including: Step 1: When the target Android system starts up and the package management service is ready, iterate through all installed application packages and check the metadata in each application package. Step 2: For each application package, determine whether the metadata of the application package contains an extension module identifier key or a framework identifier key, obtain the determination result, and write the full path of the corresponding application package into the corresponding list file according to the determination result; Step 3: Register a listener in the package management service execution system, listen for application installation or uninstallation signals through the listener, obtain the listening results, and process the full path of the corresponding application package according to the listening results to obtain the processing results; Step 4: When any application starts, a class loader is created based on the processing result, and after the plugin framework is initialized, the plugins in all the list files are loaded through the class loader.

[0022] Specifically, step 1 is when the target Android system has finished booting and the package management service is performing system ready initialization, it will traverse all installed applications in the application package. For each application package, the target Android system will obtain the metadata under the application tag declared in the Android manifest file.

[0023] Specifically, based on the judgment result, the full path of the corresponding application package is written to the corresponding list file, including: When the determination result is that the application package's metadata contains an extension module identifier key, the full path of the application package is written to the module list file; If the determination result indicates that the application package's metadata contains a framework identifier key, the full path of that application package is written to the framework list file.

[0024] In this embodiment of the invention, when the determination result is that the metadata of the application package contains an extension module identifier key, the target Android system creates a buffer writer object, opens the module list file, obtains the application package path and writes it to the module list file. The module list file records the paths of all installed extension modules, which are used by subsequent application processes when loading.

[0025] In this embodiment of the invention, when the determination result is that the application package's metadata contains a frame identifier key, the target Android system also creates a buffer writer object, opens the frame list file to obtain the complete path of the application package, and writes the complete path into the frame list file, with each path occupying a separate line.

[0026] Specifically, the full path to the application package is written to the module list file, including: The complete path of the application package is converted into a structured data format to obtain a data object. The data object contains complete information such as the application package path, package name, version number, signature hash value, and installation timestamp of the module. The data object is then written to the module list file after being subjected to advanced encryption using an Android key.

[0027] In order to enhance the security and traceability of module management, this embodiment of the invention uses a structured data format instead of a plain text list to store module information. The outermost layer of the resulting data object contains a module array and a timestamp field of the last update. Each module object in the module array contains fields such as package name, application package path, version number (integer type), version name (string type, such as 1, 0), signature hash value, installation timestamp (long integer timestamp), enabled status (boolean type), and minimum framework version requirement (integer type, such as 53).

[0028] In this embodiment of the invention, a secure hash algorithm is used to generate a signature hash value in the format of SHA256 plus a hash value; the last updated timestamp field is the last updated timestamp of the record list file.

[0029] This invention enables the system to perform multi-dimensional verification before loading modules by converting data to a structured data format, including version compatibility checks, signature verification, and activation status determination, which greatly improves security.

[0030] Specifically, after using an Android key to perform advanced encryption on the data object, it is written to the module list file, including: When the target Android system boots for the first time, several sets of keys are generated by the key generator and stored in the Android key storage. Add a message authentication code signature field to the data object to obtain the data object with the message authentication code signature field added. In the Android key storage, select any set of keys to sign the key fields in the data object after adding the message authentication code signature field, and then write it to the module list file.

[0031] In this embodiment of the invention, firstly, an Android key storage instance is obtained and loaded. Then, a key object with the alias "module_list_key" is obtained from the Android key storage. Next, an encryptor instance is obtained, the encryptor is initialized in encryption mode, and an automatically generated initialization vector is obtained. The module data is converted into a data string, then into a byte array, and an encryption operation is performed to obtain the encrypted data. A file stream object is created to open the encrypted configuration file, and a four-byte magic number, a four-byte version number, a 12-byte initialization vector, and the encrypted data are written sequentially. Then, the file stream object is closed. Finally, the file stream object points to the encrypted file. First, all users' read permissions are canceled, and only the owner is granted read permissions. Write permissions are set to be writable only by the owner in the same way, thereby achieving strict permission control.

[0032] To meet the compliance requirements and security audit needs of enterprise-level deployments, this embodiment of the invention implements a complete operation audit mechanism. Whenever the module list changes, the operation details are recorded and appended to the audit log file. The specific process is as follows: The audit log file uses a format of one data object per line. Each line is an independent data object containing the following fields: Timestamp field records the operation timestamp (long integer timestamp), Operation field records the operation type (string, such as INSTALL for installation, ENABLE for enabling, UNINSTALL for uninstallation), Package name field records the module package name, User ID field records the user ID of the user performing the operation, Result field records the operation result (SUCCESS for success, BLOCKED for blocking), Application package path field records the application package file path (optional), Signature hash field records the signature hash value (optional), and Reason field records the reason for failure or blocking (optional, such as "Signature mismatch" for signature mismatch). For example, a successful installation log entry includes a timestamp of 1702123456789, operation type INSTALL, package name, user ID 10086, result SUCCESS, and application package path and signature hash information; an enable operation log entry includes a timestamp, ENABLE operation type, package name, and success result; and a blocked uninstall operation log entry includes UNINSTALL operation type, BLOCKED result, and specific blocking reason.

[0033] Specifically, based on the monitoring results, the full path of the corresponding application package is processed to obtain the processing results, including: When the monitoring result indicates that the application is uninstalled, delete the full path of the application package of that application; When the monitoring result indicates that an application is being installed, the application package data of the new application is obtained, and the data identifier key type in the application package data is checked. The type of the new application is determined based on the data identifier key type, and the full path corresponding to the new application is written to the corresponding list file based on the type of the new application.

[0034] Specifically, a class loader is created based on the processing results, including: Based on the processing results, an application context is created. During the creation of the application context, if the required loading flag is true, the path of the framework application package is obtained by reading the framework list file. A class loader is created using the path to the framework application package. The first parameter of the class loader is the path to the application package file, and the second parameter specifies the parent loader.

[0035] In this embodiment of the invention, during the creation of the application context, the loading flag is checked to be true, that is, the application context is checked to see if it exists and is readable by the file judgment method and the readability judgment method. If the application context is valid, a buffer reader is created and the file content is read line by line to obtain the complete path of the framework application package and store it in the package name. The package name contains only one line, that is, the path of the framework application package.

[0036] Compared with existing technologies, this invention, when the target Android system starts and the package management service execution system is ready, it iterates through all installed application packages and checks the metadata in each application package. For each application package, it determines whether the metadata of the application package contains an extension module identifier key or a framework identifier key, obtains the judgment result, and writes the complete path of the corresponding application package into the corresponding list file according to the judgment result. A listener is registered in the package management service execution system to listen for application installation or uninstallation signals, obtains the listening result, and processes the complete path of the corresponding application package according to the listening result to obtain the processing result. When any application starts, a class loader is created according to the processing result, and after the plugin framework is initialized, the class loader loads the plugins in all list files, which can realize the injection of custom functions for all running APPs. Compared with existing technologies, this invention avoids the repetitive overhead of scanning the file system and parsing application package metadata every time the application starts, significantly reducing the application startup time and improving the overall system performance. Registering a listener in the package management service execution system to listen for application installation or uninstallation signals avoids the inconsistency problem of modules being uninstalled but still loaded, or modules being installed but not effective.

[0037] Corresponding to the above-described method for processing extension modules in the Android system, this embodiment of the invention also provides a system for processing extension modules in the Android system, comprising: The scanning module is used to traverse all installed application packages and check the metadata in each application package when the target Android system starts up and the package management service is ready. The judgment module is used to determine whether the metadata of each application package contains an extension module identifier key or a framework identifier key, obtain the judgment result, and write the full path of the corresponding application package into the corresponding list file based on the judgment result; The listening module is used to register listeners in the package management service execution system. The listeners listen for application installation or uninstallation signals, obtain the listening results, and process the full path of the corresponding application package based on the listening results to obtain the processing results. Create a module that, when any application starts, creates a class loader based on the processing results, and loads plugins from all list files through the class loader after initializing the plugin framework.

[0038] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for processing extension modules in an Android system, characterized in that, include: Step 1: When the target Android system starts up and the package management service is ready, iterate through all installed application packages and check the metadata in each application package. Step 2: For each application package, determine whether the metadata of the application package contains an extension module identifier key or a framework identifier key, obtain the determination result, and write the full path of the corresponding application package into the corresponding list file according to the determination result; Step 3: Register a listener in the package management service execution system, listen for application installation or uninstallation signals through the listener, obtain the listening results, and process the full path of the corresponding application package according to the listening results to obtain the processing results; Step 4: When any application starts, a class loader is created based on the processing result, and after the plugin framework is initialized, the class loader loads the plugins in all the list files.

2. The method for processing extension modules in an Android system according to claim 1, characterized in that, Based on the judgment result, the full path of the corresponding application package is written into the corresponding list file, including: When the determination result is that the application package's metadata contains an extension module identifier key, the full path of the application package is written to the module list file; When the determination result indicates that the application package's metadata contains a framework identifier key, the full path of the application package is written to the framework list file.

3. The method for processing extension modules in an Android system according to claim 2, characterized in that, Write the full path of the application package to the module list file, including: Convert the full path of the application package into a structured data format to obtain a data object; The data object is then written to the module list file after being subjected to advanced encryption using an Android key.

4. The method for processing extension modules in an Android system according to claim 3, characterized in that, The outermost layer of the data object contains an array of modules and a timestamp field for the last update; Each module object in the module array contains the package name, application package path, version number, version name, signature hash, installation timestamp, enabled status, and minimum framework version requirement.

5. The method for processing extension modules for an Android system according to claim 3, wherein the data object is written to a module list file after advanced encryption using an Android key, comprising: When the target Android system is first started, a number of keys are generated by a key generator and stored in the Android key storage. Add a message authentication code signature field to the data object to obtain the data object with the message authentication code signature field added. After selecting any set of keys in the Android key storage, the key fields in the data object after adding the message authentication code signature field are signed and written to the module list file.

6. The method for processing extension modules in an Android system according to claim 1, characterized in that, Based on the monitoring results, the complete path of the corresponding application package is processed to obtain the processing results, including: When the monitoring result indicates that the application is uninstalled, delete the full path of the application package of that application. When the monitoring result indicates that an application is installed, the application package data of the new application is obtained, and the data identifier key type in the application package data is checked. The type of the new application is determined based on the data identifier key type, and the full path corresponding to the new application is written to the corresponding list file based on the type of the new application.

7. The method for processing extension modules in an Android system according to claim 6, characterized in that, Creating a class loader based on the processing result includes: Based on the processing result, an application context is created. During the creation of the application context, if the required loading flag is true, the path of the framework application package is obtained by reading the framework list file. A class loader is created using the path to the framework application package. The first parameter of the class loader is the application package file path, and the second parameter specifies the parent loader.

8. An extension module processing system for the Android system, characterized in that, include: The scanning module is used to traverse all installed application packages and check the metadata in each application package when the target Android system starts up and the package management service is ready. The judgment module is used to determine whether the metadata of each application package contains an extension module identifier key or a framework identifier key, obtain the judgment result, and write the full path of the corresponding application package into the corresponding list file according to the judgment result; The listening module is used to register a listener in the package management service execution system, listen for application installation or uninstallation signals through the listener, obtain the listening results, and process the full path of the corresponding application package according to the listening results to obtain the processing results; A module is created to generate a class loader based on the processing result when any application starts, and to load plugins from all list files through the class loader after initializing the plugin framework.

Images