Android Service plug-in implementation method, system, equipment and medium

Abstract

The invention discloses an Android Service plug-in implementation method, an Android Service plug-in implementation system, Android Service plug-in implementation equipment and a medium. The Android Service plug-in implementation method specifically comprises the following steps: deploying proxy service in a host application, creating a standard interface IServiceInterface, and fusing host and plug-in resources by rewriting a context loading method of Android Service; constructing a service life cycle prediction model through a federated learning framework based on multi-device service behavior data collected during proxy service operation; generating a dynamic scheduling strategy based on an output result of the service life cycle prediction model in combination with the equipment electric quantity, the network type and the CPU load; and based on a dynamic scheduling strategy, writing the plug-in metadata hash, the federated model fingerprint and the device state snapshot into a block chain smart contract, and verifying the integrity of the plug-in through a light node on the chain to obtain a block chain verification result. According to the method, the stability and the reliability of the Service plug-in are improved, and powerful support is provided for the hot update function of the Android application.

Description

Technical Field

[0001] The present invention relates to the field of application technology, and in particular to an Android Service plug-in implementation method, system, device, and medium. Background Art

[0002] With the rapid development of mobile internet technology, the functionality of applications (APPs) and software development kits (SDKs) on the Android platform has become increasingly rich and complex. Pluginization is a key approach to implementing hot updates on the Android platform. It divides an application or SDK into a host and a plugin. The host, serving as the application's foundational framework, is responsible for loading and managing the plugin. Upon startup, the connected app can dynamically load plugins, enabling dynamic functionality updates, eliminating the need for users to manually download and install new versions of the app. However, in the practical application of Android pluginization, the implementation of plugin-based services faces numerous challenges.

[0003] First, the dynamic integration of host and plug-in resources is key to achieving service plug-inization. In a plug-in architecture, the host and plug-in may each have independent resource files, such as layout files, images, and strings. Traditional resource loading mechanisms often struggle to effectively handle resource conflicts and dependencies between the host and plug-ins. For example, when resources with the same name exist in the host and the plug-in, traditional resource loading mechanisms may not be able to correctly identify and load the required resources, resulting in resource loading failure or application crashes. Furthermore, the dynamic loading and unloading of resources requires sophisticated management mechanisms to ensure timely resource release and avoid memory leaks.

[0004] Secondly, Service lifecycle management involves multiple stages and callback methods. Plugin-based implementations need to ensure that these methods are called correctly and remain consistent across devices. However, due to differences in device performance, system versions, and other factors, traditional lifecycle management solutions often struggle to adapt to complex and changing environments. For example, on some low-performance devices, the startup and operation of a Service may be subject to resource constraints, resulting in delays or exceptions in the execution of lifecycle callback methods. Furthermore, different Android system versions may also differ in their management of the Service lifecycle, adding to the complexity of plugin-based implementations.

[0005] Furthermore, in a multi-device environment, device factors can affect the efficiency and stability of services. Traditional scheduling strategies often lack the ability to dynamically perceive and adapt to these factors, forcing services to start even under unfavorable conditions, leading to performance degradation or crashes. For example, when battery life is low or network conditions are poor, starting a high-energy service can accelerate device battery drain or cause network request failures, impacting user experience and application stability.

[0006] Furthermore, plug-in implementations must ensure the integrity and trustworthiness of plug-ins to prevent malicious injection and tampering. With the widespread adoption of mobile internet, application security faces increasing threats. Malicious plug-ins may tamper with code or resource files to steal user data, disrupt application functionality, or perform other malicious activities. However, traditional verification mechanisms often struggle to effectively address complex and diverse attack vectors. For example, simple hash checks or digital signature verification may not be able to protect against advanced tampering attacks, exposing applications to security risks. Summary of the Invention

[0007] The purpose of the present invention is to provide an Android Service plug-in implementation method, system, device and medium, which not only improves the stability and reliability of Service plug-in, but also provides strong support for the hot update function of Android applications, so as to solve at least one of the above-mentioned existing technical problems.

[0008] In a first aspect, the present invention provides a method for implementing an Android Service plug-in, the method specifically comprising: Deploy the proxy service in the host application, create the standard interface IServiceInterface, and integrate the host and plug-in resources by overriding the context loading method of the Android Service; Based on the multi-device service behavior data collected during proxy service operation, a service lifecycle prediction model is constructed through a federated learning framework. The service lifecycle prediction model is used to output the crash probability and resource usage prediction value of the plug-in service; Generate dynamic scheduling strategies based on the output of the service lifecycle prediction model, combined with device power, network type, and CPU load; Based on the dynamic scheduling strategy, the plug-in metadata hash, federated model fingerprint, and device status snapshot are written into the blockchain smart contract. The plug-in integrity is verified by the on-chain light node to obtain the blockchain verification result. If the blockchain verification result is determined to be a failure, the incremental update process of the service lifecycle prediction model is triggered and the dynamic scheduling strategy is regenerated.

[0009] In a second aspect, the present invention provides an Android Service plug-in implementation system, the system specifically comprising: The proxy service deployment module is used to deploy the proxy service in the host application, create the standard interface IServiceInterface, and integrate the host and plug-in resources by overriding the context loading method of Android Service; A prediction model building module is used to build a service lifecycle prediction model through a federated learning framework based on the multi-device service behavior data collected during the proxy service runtime. The service lifecycle prediction model is used to output the crash probability and resource usage prediction value of the plug-in service; The scheduling strategy generation module is used to generate dynamic scheduling strategies based on the output of the service lifecycle prediction model, combined with device power, network type, and CPU load; The blockchain verification module is used to write the plug-in metadata hash, federated model fingerprint, and device status snapshot into the blockchain smart contract based on the dynamic scheduling strategy, and verify the plug-in integrity through the on-chain light node to obtain the blockchain verification result; The model incremental update module is used to trigger the incremental update process of the service lifecycle prediction model and regenerate the dynamic scheduling strategy if the blockchain verification result is determined to be a failure.

[0010] In a third aspect, the present invention provides a computer device comprising: a memory and a processor and a computer program stored in the memory. When the computer program is executed on the processor, the Android Service plug-in implementation method as described in any one of the above methods is implemented.

[0011] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for implementing Android Service plug-in as described in any one of the above methods is implemented.

[0012] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention not only improves the stability and reliability of Service plug-in, but also provides strong support for the hot update function of Android applications.

[0013] 2. The present invention realizes the dynamic integration of host and plug-in resources by deploying proxy services and creating standard interfaces, and improves the success rate and stability of plug-in service loading and lifecycle scheduling through the service lifecycle prediction model constructed by federated learning.

[0014] 3. The present invention realizes the dynamic integration of host and plug-in resources by rewriting the context loading method of Android Service, and dynamically allocates resource loading weights through the resource priority formula, effectively solving the resource conflict problem and improving resource loading efficiency.

[0015] 4. This invention collects multi-device service behavior data and builds a local LSTM prediction model. It then uses the federated learning framework to aggregate multi-device model parameters to generate an accurate service lifecycle prediction model, providing strong support for dynamic scheduling strategies.

[0016] 5. The present invention generates a more accurate service lifecycle prediction model by inputting time series data into a pre-trained initial LSTM prediction model and using a federated learning framework to aggregate multi-device model parameters, thereby improving prediction accuracy and model generalization capabilities.

[0017] 6. The present invention combines the output results of the service life cycle prediction model and the device status information to generate a dynamic scheduling strategy, realizes the intelligent scheduling of the plug-in service, and improves the stability of the system and resource utilization.

[0018] 7. This invention ensures the credibility and security of the plug-in by writing the plug-in metadata hash, federated model fingerprint and device status snapshot into the blockchain smart contract, and using the on-chain light node to verify the integrity of the plug-in, thereby preventing the injection and tampering of malicious plug-ins.

[0019] 8. When the blockchain verification result is a failure, the present invention triggers the incremental update process of the service lifecycle prediction model and regenerates the dynamic scheduling strategy, thereby realizing the adaptive update of the model and the dynamic adjustment of the scheduling strategy, thereby improving the robustness of the system and its ability to cope with complex environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 This is a flowchart of a method for implementing an Android Service plug-in provided by one embodiment of the present invention; Figure 2 This is a structural diagram of an Android Service plug-in implementation system provided by one embodiment of the present invention; Figure 3 It is a structural diagram of a computer device provided by one embodiment of the present invention. DETAILED DESCRIPTION

[0022] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0023] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0024] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0025] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0026] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0027] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] In the embodiments of the present application, the execution subject of the process includes a terminal device, which includes but is not limited to: a server, a computer, a smart phone, a tablet computer, and other devices capable of executing the method disclosed in the present application. Figure 1 A flow chart of a method for implementing an Android Service plug-in according to an embodiment of the present invention is shown, and is described in detail as follows: S101, deploying a proxy service in the host application, creating a standard interface IServiceInterface, and integrating the host and plug-in resources by overriding the context loading method of the Android Service.

[0029] In this embodiment, resource integration between the host application and the plugin is a key issue in implementing Android Service plugins. Because the host and plugin may each have independent resource files, traditional resource loading mechanisms struggle to effectively handle resource conflicts and dependencies, potentially leading to resource loading failures or application crashes. Therefore, a solution is needed that deploys a proxy service within the host application, creates a standard interface, and implements resource integration between the host and plugin by overriding the context loading method.

[0030] First, create an independent proxy service (ProxyService) module in the host application. This module acts as a bridge between the host and the plugin, responsible for loading, managing, and scheduling resources. The proxy service adopts a modular design to facilitate subsequent maintenance and expansion. The proxy service has an independent lifecycle management mechanism that automatically initializes when the host application starts and continuously monitors and manages the plugin's resource usage while the host application is running. Register the proxy service in the host application's AndroidManifest.xml file, specifying the service name, startup method, and other attributes. Ensure that the proxy service is correctly identified and loaded by the system when the host application starts.

[0031] Define a standard interface, IServiceInterface, which is used to regulate the interaction between the host and the plug-in. The interface should include method declarations related to resource loading, lifecycle management, etc. Interface design should follow the single responsibility principle, with each method responsible for only one specific function to improve the maintainability and scalability of the interface. Implement the IServiceInterface interface in the host application and the plug-in respectively. The implementation in the host application is responsible for calling the system resource loading method, while the implementation in the plug-in is responsible for providing the plug-in's own resources. Through the unified specification of the interface, the host application and the plug-in can interact without directly relying on each other's specific implementation, which improves the flexibility and scalability of the system.

[0032] Analyze the context loading method of an Android service to understand its resource loading process and mechanism. Typically, a service's context loading method is called when the service starts and is responsible for loading the resources required by the service. Traditional context loading methods may not directly handle resource integration between the host and plugins, so they need to be rewritten.

[0033] In the proxy service, override the Android Service context loading method. In the overridden method, first check whether the resource being loaded is a plugin resource. If so, the proxy service calls the plugin's resource loading implementation through the IServiceInterface interface to retrieve the plugin resource. If the resource is a host resource, the proxy service directly calls the system resource loading method to load the host resource. During the resource loading process, the proxy service must handle resource conflicts and dependencies between the host and plugin.

[0034] To ensure timely resource release and avoid memory leaks, the proxy service needs to establish a resource integration management mechanism. After loading resources, the proxy service will record the loading status and usage of the resources. When resources are no longer needed, the proxy service will promptly release them based on their type and usage, ensuring system stability and performance.

[0035] In this embodiment, by deploying a proxy service within the host application, creating a standard interface, IServiceInterface, and integrating host and plugin resources by overriding the Android Service context loading method, we can effectively resolve resource conflicts and dependencies between the host and plugins. This embodiment improves the accuracy and stability of resource loading, avoiding user experience degradation caused by resource loading failures or application crashes. Furthermore, this solution provides a solid foundation for subsequent steps such as Service lifecycle management and dynamic scheduling strategy generation, contributing to the efficient plug-in implementation of Android Services.

[0036] S102, based on the multi-device service behavior data collected during the proxy service runtime, a service lifecycle prediction model is constructed through a federated learning framework, wherein the service lifecycle prediction model is used to output the crash probability and resource occupancy prediction value of the plug-in service.

[0037] In this embodiment, during the implementation of Android Service plug-ins, traditional lifecycle management solutions struggle to adapt to complex and changing environments due to differences in device performance, system versions, and other factors. This results in inconsistent service performance across different devices, potentially leading to increased crash probability and unreasonable resource usage. To proactively predict the operating status of plug-in services on different devices and implement targeted optimization measures, a service lifecycle prediction model is constructed using a federated learning framework based on multi-device service behavior data collected during proxy service runtime.

[0038] Specifically, multiple data collection points are set up in the proxy service to comprehensively capture behavioral data from the plug-in service at different stages of its lifecycle. For example, during the service startup phase, data such as startup time and initial resource usage (such as memory and CPU utilization) is collected; during the running phase, data such as runtime, resource usage fluctuations, and task processing volume are collected; and during the stopping phase, data such as stop time and resource release status are collected. Furthermore, device-related information such as device model, system version, CPU model, and memory size is recorded. This device information serves as important input features for the model, used to distinguish the operating environments of different devices.

[0039] Determine the appropriate data collection frequency based on the service's operational characteristics and actual needs. For services with rapidly changing operational status, the collection frequency can be increased to obtain more detailed behavioral data. For services with relatively stable operational status, the collection frequency can be reduced to minimize the impact of data collection on system performance. Data collection can be performed using either periodic polling or event-driven methods. Periodic polling involves sending query requests to the service at fixed intervals to obtain its current behavioral data. Event-driven methods automatically trigger data collection when specific events occur in the service (such as starting, stopping, and task completion).

[0040] Establish a local database within the host application to store collected multi-device service behavior data. The database should have a well-structured data storage structure to facilitate subsequent data query and analysis. For example, data can be categorized and stored by fields such as device ID, service name, and collection time. Regularly clean and back up data in the local database to avoid insufficient storage space due to excessive data volume and prevent data loss.

[0041] Select a federated learning framework that is suitable for the Android platform and meets your project requirements. Currently, there are several federated learning frameworks available, such as FATE (Federated AI Technology Enabler) and PySyft. When choosing, consider factors such as the framework's ease of use, performance, security, and Android platform support. Ensure that the selected framework supports distributed training, allowing participants to collaboratively train models without sharing original data, thereby protecting user privacy and data security. Use multiple devices with the host application installed as federated learning participants. These devices have varying hardware configurations and system environments, providing diverse service behavior data and helping improve model generalization. Identify a central server as the federated learning coordinator, responsible for coordinating and managing tasks such as model initialization, parameter aggregation, and model updates. The central server should have high computing power and stability to ensure the smooth progress of the federated learning process.

[0042] Design an appropriate model architecture based on the needs of service lifecycle prediction. Each participant (device) trains an initialized local model using locally collected service behavior data. During training, the participant calculates the model gradient based on the local data and updates the local model parameters using an optimization algorithm (such as stochastic gradient descent (SGD). To improve model training efficiency and accuracy, participants can preprocess the local data, such as performing data normalization and feature selection. Furthermore, appropriate training rounds and batch sizes are set to avoid overfitting or underfitting.

[0043] Each participant uploads the parameters obtained from local model training to the central server. After receiving the parameters from all participants, the central server aggregates them using the Federated Averaging algorithm or another suitable aggregation algorithm. The basic idea of ​​the Federated Averaging algorithm is to take a weighted average of the parameters of each participant, with the weights determined based on the amount of data provided by the participant or other factors. Through parameter aggregation, the central server obtains global model parameters.

[0044] The central server distributes the aggregated global model parameters to each participant. Each participant replaces their local model parameters with the updated global model parameters, completing the global model update. This process of local model training, model parameter aggregation, and global model update repeats until the model converges or reaches the preset training rounds. Through multiple rounds of iterative training, the model continuously learns the characteristics of service behavior data on different devices, improving prediction accuracy.

[0045] During the actual operation of the plug-in service, the collected real-time service behavior data and device information are input into the trained service lifecycle prediction model. The model then outputs the plug-in service's crash probability and resource usage predictions. Based on the model's predictions, appropriate optimization measures are taken. For example, if the plug-in service is predicted to have a high crash probability on a particular device, the service on that device can be optimized or the scheduling strategy adjusted in advance. If the resource usage prediction exceeds a preset threshold, unnecessary resources can be released promptly to avoid system performance degradation.

[0046] Regularly collect actual operational data from the plug-in service, including actual crashes and resource usage, and compare it with the model's predictions to assess model accuracy and reliability. Use appropriate evaluation metrics, such as accuracy, recall, and mean squared error, to quantitatively assess model performance. If the model evaluation results are unsatisfactory, analyze the causes and adjust and optimize the model architecture, training data, or training process. This can include increasing the amount of training data, adjusting model hyperparameters, and improving feature engineering. Then, retrain and reevaluate the model until satisfactory performance is achieved.

[0047] In this embodiment, a service lifecycle prediction model is constructed using a federated learning framework based on multi-device service behavior data collected during proxy service runtime. This model can predict the crash probability and resource usage of plug-in services on different devices in advance. This embodiment fully considers device diversity, improves the model's generalization and prediction accuracy, and helps developers take proactive optimization measures to reduce the risk of plug-in service crashes, rationally allocate system resources, and improve the stability and performance of Android service plug-ins.

[0048] S103: Generate a dynamic scheduling strategy based on the output of the service lifecycle prediction model and in combination with device power, network type, and CPU load.

[0049] In this embodiment, in the Android Service plug-in implementation, a reasonable dynamic scheduling strategy is required to ensure the stable and efficient operation of the plug-in service in different device environments. The service lifecycle prediction model can output the crash probability and resource utilization prediction of the plug-in service, but scheduling based solely on these predictions is insufficient. Actual operating environment factors such as device power, network type, and CPU load have a significant impact on the performance and stability of the service. Therefore, it is necessary to integrate the output of the service lifecycle prediction model with this device status information to generate a scientific and reasonable dynamic scheduling strategy.

[0050] Specifically, set up a scheduled task in the host application to periodically obtain device battery information. Use the BatteryManager class provided by the Android system to obtain the current device battery percentage and record battery trends, such as the rate of battery decline over a period of time, to determine whether the device is low on battery or rapidly depleting.

[0051] Use the Android ConnectivityManager class to monitor the device's network connection status in real time and obtain the current network type, such as Wi-Fi, 4G, 3G, 2G, or no network connection. For Wi-Fi networks, you can further obtain the network signal strength; for mobile data networks, you can obtain network operator information and signal quality level.

[0052] Use system-provided interfaces or third-party libraries to regularly collect device CPU load data. This allows you to obtain current CPU usage and the distribution of usage across cores, providing a comprehensive understanding of the device's CPU resource usage. Additionally, you can record historical CPU load data and analyze its fluctuation patterns.

[0053] Obtain real-time predictions of plug-in service crash probabilities and resource usage from the service lifecycle prediction model. Ensure that the obtained prediction results correspond to the current device status data in time to facilitate comprehensive analysis.

[0054] When the crash probability of a plug-in service exceeds a preset threshold (e.g., 30%), consider restricting or optimizing the plug-in service. For example, lowering its operating priority, reducing the system resources it consumes, or temporarily suspending the service and restarting it when conditions permit. If the predicted resource usage exceeds a certain percentage of the device's currently available resources (e.g., 80%), adjust the resource allocation for the plug-in service, such as reducing its memory allocation or limiting its CPU usage, to ensure the normal operation of other critical device functions.

[0055] When the device is in a low-battery state, high-energy-consuming plug-in services should be stopped or restricted first. For example, plug-in services that run continuously in the background and consume a lot of resources can be stopped directly when the battery is low to extend the device's usability. If the device is in a medium-battery state, resources can be allocated appropriately based on the service priority and resource usage. Important plug-in services with low resource usage can be allowed to run normally; unimportant or high-resource plug-in services can be appropriately restricted.

[0056] In high-speed network environments, plug-in services that require large amounts of network data transmission can be allowed to run at higher speeds to fully utilize the network's performance advantages. In medium-speed network environments, network requests for plug-in services can be optimized, such as reducing data transmission frequency and compressing packet size, to reduce network bandwidth usage and ensure stable service operation. In low-speed network environments or in environments without a network connection, plug-in services that rely on network connectivity should be suspended or switched to local caching mode.

[0057] When the CPU is under high load, non-critical plug-in services should be suspended or their operating frequency reduced to reduce the CPU burden. If the CPU is under moderate load, the operating status of plug-in services can be dynamically adjusted based on service priority and resource requirements. Important plug-in services with low CPU resource requirements can be allowed to operate normally; non-critical plug-in services or those with high CPU resource requirements should be appropriately restricted.

[0058] Based on the rules established above, a decision tree model is constructed. The nodes of the decision tree represent different decision conditions, such as service crash probability, device power level, network type, and CPU load level. The branches of the decision tree represent different choices made based on the decision conditions. The leaf nodes of the decision tree represent the final scheduling strategy, such as starting or stopping a service, limiting resources, and adjusting priorities. When constructing the decision tree, it is necessary to comprehensively consider the priorities and interrelationships between the various rules.

[0059] After obtaining the output of the service lifecycle prediction model and data such as device power, network type, and CPU load, and completing data preprocessing, the preprocessed data is used as input and substituted into the decision tree model for inference. Based on the inference results of the decision tree, a specific dynamic scheduling strategy is generated.

[0060] A scheduling management module is established in the host application, which is responsible for receiving the generated dynamic scheduling strategy and performing the corresponding scheduling operations. For the scheduling strategy of starting the service, the scheduling management module calls the startup interface of the plug-in through the proxy service to initialize and run the plug-in service. For the scheduling strategy of stopping the service, the scheduling management module sends a stop instruction to the plug-in service and releases the relevant resources occupied by the service, such as memory, threads, etc. For the scheduling strategy of limiting resources, the scheduling management module adjusts its resource allocation parameters through the interactive interface with the plug-in service, such as limiting memory usage, lowering CPU priority, etc. For the scheduling strategy of adjusting priority, the scheduling management module modifies the running priority of the plug-in service in the system to ensure that high-priority services can obtain system resources first.

[0061] Regularly collect performance data and user feedback from plug-in services during actual operation to evaluate the effectiveness of dynamic scheduling strategies. Performance data includes service crash rates, resource usage, response times, and other aspects. User feedback can be obtained through user reviews and complaints. Based on the evaluation results, analyze whether the dynamic scheduling strategy has achieved its intended goals, such as reducing service crash rates, improving device battery life, and enhancing user experience.

[0062] If the evaluation results indicate deficiencies in the dynamic scheduling strategy, the decision tree model can be adjusted and optimized based on the evaluation results. For example, if certain rules are found to be ineffective in actual applications, the rule thresholds or conditions can be modified; if the branch structure of the decision tree is found to be unreasonable, the decision tree can be pruned or rebuilt.

[0063] At the same time, we continuously collect new service lifecycle prediction data and device status data, and continuously enrich and update the training dataset to improve the accuracy and adaptability of the decision tree model. Through repeated evaluation and optimization, the dynamic scheduling strategy can better adapt to different device environments and user needs.

[0064] In this embodiment, a dynamic scheduling strategy is generated based on the output of the service lifecycle prediction model, combined with device power consumption, network type, and CPU load. This allows for real-time adjustments to the plug-in service's operating status and resource allocation based on the device's actual operating status and the plug-in service's predicted performance. This helps improve the stability and performance of plug-in services in different device environments, reduces the risk of service crashes, optimizes device resource utilization, and extends device battery life, thereby enhancing user experience and application competitiveness.

[0065] S104, based on the dynamic scheduling strategy, write the plug-in metadata hash, federated model fingerprint and device status snapshot into the blockchain smart contract, and verify the plug-in integrity through the on-chain light node to obtain the blockchain verification result.

[0066] In this embodiment, blockchain technology is introduced for verification during the Android Service plug-in implementation process to ensure the integrity and credibility of plug-ins and prevent malicious injection and tampering. Dynamic scheduling strategies are generated based on device status and service lifecycle predictions. Based on this strategy, the plug-in metadata hash, federated model fingerprint, and device status snapshot are written to the blockchain smart contract and verified using on-chain light nodes, providing reliable protection for plug-in security.

[0067] Specifically, during the plug-in development phase, the plug-in metadata is comprehensively collected. Plugin metadata includes, but is not limited to, the plug-in version number, developer information, function description, resource file list, etc. This metadata can uniquely identify the plug-in's features and attributes. A suitable hash algorithm (such as SHA-256) is used to perform a hash calculation on the collected plug-in metadata. The hash algorithm can convert input data of any length into a fixed-length hash value with uniqueness and irreversibility. Through hash calculation, the plug-in metadata is converted into a unique hash value, which will serve as the identifier of the plug-in metadata for subsequent verification processes.

[0068] During the training process, the service lifecycle prediction model built by the federated learning framework generates a series of feature parameters and model structure information. Key features are extracted from this information, such as the number of model layers, the number of neurons in each layer, and the distribution characteristics of weight parameters. These features reflect the uniqueness and structural characteristics of the model. The extracted key model features are encoded and combined to generate a federated model fingerprint. A hash algorithm is used to calculate the combined features, generating a fixed-length string as the federated model fingerprint. This fingerprint uniquely identifies the service lifecycle prediction model built by the federated learning framework, ensuring model integrity and traceability.

[0069] A dedicated module is set up in the host application to collect device status information. Device status information includes, but is not limited to, device model, operating system version, current battery level, network type, CPU load, and memory usage. This information reflects the device's actual operating environment when executing the plug-in service. The collected device status information is organized and packaged to generate a device status snapshot.

[0070] The smart contract needs to design a corresponding data structure to store the plugin metadata hash, federated model fingerprint, and device status snapshot. Three different data fields can be defined, corresponding to these three types of data. Furthermore, appropriate access permissions and storage rules should be set for each data field to ensure data security and integrity. Verification logic should be written into the smart contract to verify the integrity of the plugin. This verification logic primarily involves matching the plugin metadata hash, federated model fingerprint, and device status snapshot. Upon receiving a verification request, the smart contract retrieves the corresponding data stored on-chain and compares it with the data provided in the request. If the data matches exactly, verification passes; otherwise, verification fails. The smart contract also needs to define an event triggering mechanism to trigger the corresponding event when the verification result is confirmed.

[0071] Based on actual needs and application scenarios, select an appropriate blockchain platform for smart contract deployment. Common blockchain platforms such as Ethereum and Hyperledger Fabric provide a wealth of development tools and comprehensive blockchain infrastructure to meet the deployment and operation requirements of smart contracts. Use appropriate development tools (such as the Solidity compiler) to compile the designed smart contract to generate a deployable bytecode file. Then, deploy the bytecode file to the selected blockchain platform. During the deployment process, you need to set initial smart contract parameters, such as the administrator address and data storage capacity.

[0072] The generated plugin metadata hash, federated model fingerprint, and device status snapshot are encapsulated in the data format required by the smart contract. A data object containing these three data fields can be created and serialized for easy transmission and storage within the blockchain network.

[0073] In the host application, a transaction is initiated through a blockchain client library (such as Web3.js or the Ethereum Java library) to send the encapsulated data object to the blockchain network. The transaction's destination address is the address of the smart contract. The transaction contains the data to be written to the smart contract and the corresponding operation instructions (such as storing data). After receiving the transaction, the miner nodes in the blockchain network will verify and package it. Transactions that pass verification will be included in a new block and added to the blockchain. Once the transaction is confirmed and written to the blockchain, the plugin metadata hash, federation model fingerprint, and device status snapshot are permanently stored in the smart contract and cannot be tampered with.

[0074] Deploy an on-chain light node in the blockchain network. A light node is a lightweight blockchain client that doesn't require full blockchain data storage, only block header information. Light nodes can communicate with full nodes to obtain required transaction data and status information. Configure the light node's verification rules and parameters so that it can verify the integrity of plugins based on the smart contract's verification logic. For example, set the data fields the light node needs to verify and the verification threshold. When the integrity of a plugin needs to be verified, the host application initiates a verification request to the on-chain light node. This verification request includes the plugin's metadata hash, the federated model fingerprint, and a device status snapshot (either current real-time data or previously stored data).

[0075] After receiving a verification request, the light node first retrieves the corresponding data stored in the smart contract from the blockchain. It then compares the data provided in the request with the data retrieved from the blockchain. Following the verification logic defined in the smart contract, the light node sequentially verifies the plugin metadata hash, federated model fingerprint, and device status snapshot. If all data matches, the plugin is considered complete and verification passes. If any data does not match, the plugin is considered potentially tampered with and verification fails.

[0076] The light node feeds the verification results back to the host application. Verification results can be delivered via a specific message format or interface, clearly informing the host application whether the plugin is complete. The host application then takes appropriate action based on the verification result. If verification passes, the plugin service continues to execute. If verification fails, the incremental update process of the service lifecycle prediction model is triggered, and the dynamic scheduling policy is regenerated.

[0077] In this embodiment, by writing plugin metadata hashes, federated model fingerprints, and device status snapshots into blockchain smart contracts based on a dynamic scheduling strategy and verifying plugin integrity via on-chain light nodes, we effectively prevent malicious plugin injection and tampering, ensuring the security and reliability of Android Service plug-ins. The blockchain's immutable and decentralized nature ensures data authenticity and credibility, while the light node verification mechanism improves efficiency and flexibility, providing a solid security guarantee for hot updates and plug-in implementations of Android applications.

[0078] S105: If the blockchain verification result is determined to be a failure, the incremental update process of the service lifecycle prediction model is triggered, and the dynamic scheduling strategy is regenerated.

[0079] In this embodiment, during the implementation of Android Service plug-ins, verifying the plug-in integrity through blockchain is a critical step in ensuring application security. A blockchain verification failure indicates potential tampering or other security issues with the plug-in, necessitating measures to improve the reliability and security of subsequent plug-in operations. Triggering the incremental update process of the service lifecycle prediction model and regenerating the dynamic scheduling policy enables the model and scheduling policy to better adapt to potential anomalies, thereby improving the plug-in's stability and security in complex environments.

[0080] Specifically, after receiving the blockchain verification results from the on-chain light node, the host application parses them. Verification results typically indicate success or failure using a specific message format or identifier. If the verification result is determined to be a failure, the host application generates a trigger signal. This trigger signal can be a specific event or message, notifying the relevant modules to begin the incremental update process for the service lifecycle prediction model and the regeneration of the dynamic scheduling policy. The host application then transmits the trigger signal to the modules responsible for model updates and policy generation. Signal transmission can be accomplished through internal mechanisms such as message queues and event buses to ensure timely responses from relevant modules.

[0081] After the incremental update process is triggered, abnormal data related to the current plug-in verification failure begins to be collected. This abnormal data may include, but is not limited to, plug-in metadata, federated model fingerprints, device status snapshots, and system logs at the time of verification failure. The collected abnormal data is analyzed to identify the cause of the verification failure. For example, analysis may be performed to determine whether the plug-in metadata has been tampered with, whether the federated model has been attacked, or whether the device status is abnormal. Through data analysis, model features or parameters that require special attention and adjustment are identified.

[0082] Based on the results of abnormal data analysis, the features of the service lifecycle prediction model are adjusted and optimized. For example, if a feature of the plug-in metadata is found to be abnormal when verification fails, the weight of the feature can be increased or new related features can be introduced.

[0083] Obtain incremental data related to the current plug-in. Incremental data can be recently collected data related to plug-in operation, device status, and other aspects. This data can reflect the latest application environment and user behavior. Use the incremental data to train the adjusted service lifecycle prediction model. During training, online learning or incremental learning methods can be used to enable the model to quickly adapt to the new data distribution, improving the model's accuracy and generalization capabilities. Evaluate and verify the incrementally updated service lifecycle prediction model. Use a portion of reserved test data to test the model and assess its accuracy in predicting the probability of plug-in service crashes and resource usage. If the model evaluation results meet the preset performance indicators (such as accuracy and recall), the incremental model update is considered successful. If the evaluation results are unsatisfactory, further analysis is required, and the aforementioned feature adjustment, data acquisition, and training processes must be repeated until the model performance meets the requirements.

[0084] After the incremental update of the service lifecycle prediction model is completed, the updated model is used to predict the current plug-in service, obtaining new predictions for the plug-in service crash probability and resource usage. These predictions serve as an important basis for regenerating dynamic scheduling policies. The current device status information, including device power, network type, and CPU load, is recollected. This device status information reflects the actual operating environment of the current device and is crucial for generating appropriate dynamic scheduling policies.

[0085] Based on the new model output and device status information, the dynamic scheduling policy generation rules are adjusted. For example, if the new model predicts a high probability of a plug-in service crashing and the device battery is low, the policy can be adjusted to lower the startup priority of the plug-in service or reduce its resource usage.

[0086] Refine the scheduling policy to account for differences in device performance and system versions. Regenerate the dynamic scheduling policy based on the adjusted rules. Dynamic scheduling policies can be described in a structured data format, clarifying the rules for starting, running, and stopping services under different conditions. Deploy the regenerated dynamic scheduling policy to the host application. This can be achieved through internal configuration file updates and policy engine loading, ensuring that the new scheduling policy takes effect promptly and guides the operation of the plug-in service.

[0087] After regenerating and deploying the dynamic scheduling policy, the operation of the plug-in service is continuously monitored. Monitoring metrics include service crashes, resource usage, and performance. By embedding a monitoring module in the application, relevant data can be regularly collected and analyzed. If problems with the plug-in service are still detected during monitoring, such as a high crash probability or abnormal resource usage, the issues are promptly reported to the model update and policy generation module. Based on the reported issues, the incremental update process of the service lifecycle prediction model and the regeneration process of the dynamic scheduling policy are triggered again for iterative optimization, continuously improving the stability and security of the plug-in in complex environments.

[0088] In this embodiment, by triggering an incremental update process for the service lifecycle prediction model and regenerating a dynamic scheduling policy when blockchain verification fails, Android Service plug-ins can better address potential security issues and complex environmental changes. This incremental update model and regeneration policy enable timely adjustments and optimization of plug-in operations, improving plug-in reliability and stability, and ensuring user experience and application security.

[0089] In some embodiments, in step S101 above, deploying a proxy service in the host application, creating a standard interface IServiceInterface, and integrating host and plug-in resources by rewriting the context loading method of the Android Service specifically includes: Deploy the proxy service in the host application, inherit android.app.Service and rewrite the getClassLoader method and getResources method to achieve dynamic fusion of host and plug-in resources and obtain a hybrid loader; Based on the hybrid loader, a standard interface IServiceInterface is created in the proxy service. The standard interface IServiceInterface includes the resource injection method insertContext and the lifecycle methods onCreate and onStartCommand. A resource priority formula is constructed based on device power, network type, and historical resource usage frequency, and resource loading weights of the host and plug-ins are dynamically allocated based on the resource priority formula. In response to resource conflict events, based on resource loading weights, host or plug-in resources are selected for loading, and conflicting resources are merged through the MergedResources object.

[0090] In this embodiment, a new Java class is created in the host application's project directory as a proxy service. This class inherits from android.app.Service, giving it the basic functionality of an Android Service. The proxy service acts as a bridge between the host and the plugin, coordinating resource loading and management. When creating a proxy service, it is necessary to ensure that it can be correctly recognized and started by the Android system. Therefore, the corresponding configuration is required in the host application's AndroidManifest.xml file, declaring the proxy service and specifying its relevant properties.

[0091] In the proxy service class, override the getClassLoader method. By default, the class loader returned by this method can only load class files from the host application. By overriding this method, we can customize the behavior of the class loader so that it can load class files from both the host application and the plugin. In specific implementation, we can create a new class loader that first attempts to load classes from the host application's class path. If it cannot find the class, it loads it from the plugin's class path. In this way, dynamic loading of host and plugin classes is achieved. Similarly, override the getResources method. This method returns the host application's resource object by default. We rewrite it so that it can dynamically choose to load host or plugin resources based on the resource loading strategy. During the rewriting process, we need to build a hybrid loader that can integrate the resource files of the host and plugin and dynamically switch resources when needed.

[0092] The hybrid loader is the core component that implements the dynamic fusion of host and plug-in resources. When building a hybrid loader, you first need to obtain the resource file paths of the host application and the plug-in respectively. The resource path of the host application can be obtained through the relevant APIs of the Android system. For plug-in resources, you can obtain the directory path where its resource file is located when the plug-in is loaded. Then, create a new resource loader instance. When loading resources, this instance first determines whether to load host resources or plug-in resources based on the resource loading strategy. If host resources need to be loaded, they are obtained from the resource path of the host application; if plug-in resources need to be loaded, they are obtained from the resource path of the plug-in. In this way, the hybrid loader can flexibly handle loading requests for host and plug-in resources and realize dynamic fusion of resources.

[0093] In the proxy service, a standard interface named IServiceInterface is created. This interface serves as a specification for communication and resource interaction between the host and the plug-in, and defines a series of methods for implementing resource injection and lifecycle management.

[0094] The insertContext method is defined in the IServiceInterface interface. This method is used to inject the host application's context information into the plug-in. This context information includes various resources and runtime environment information of the host application, such as resource objects and Activity instances. Through the insertContext method, the plug-in can obtain the host application's context, thereby accessing its resources and services and implementing dynamic resource injection.

[0095] Define the onCreate method, which is called when the plugin service is created. In the onCreate method, you can perform some initialization operations, such as loading the plugin's resources and initializing the plugin's internal state. This method ensures that the plugin's runtime environment is properly initialized when it is created.

[0096] Define the onStartCommand method, which is called when the plug-in service starts. In the onStartCommand method, you can perform operations based on business needs, such as starting background tasks and processing network requests. Through the onStartCommand method, you can control and manage the startup behavior of the plug-in service.

[0097] Get the current power information of the device through the Android system's battery management API. The device power is one of the important factors affecting the resource loading strategy. When the device power is low, resources that consume less power should be loaded first to extend the device's battery life. Use the Android system's network connection API to get the device's current network type, such as Wi-Fi, 4G, 3G, etc. Different network types have different bandwidths and stabilities. Resources that require large amounts of data transmission can be loaded first when the network conditions are good. Establish a resource usage record database in the host application to record the frequency of historical usage of each resource. The historical frequency of resource usage reflects the importance and frequency of use of the resource. Resources with higher usage frequencies can be given higher priority.

[0098] Based on the collected factors such as device power, network type, and historical resource usage frequency, a resource priority formula is constructed. This formula can use a weighted average method to assign different weights to each factor, and then calculate the priority score of the resource based on the actual value of each factor. According to the priority score calculated by the resource priority formula, the resource loading weights of the host and plug-in are dynamically allocated. The resources are sorted from high to low according to the priority score, and then a loading weight is assigned to each resource based on the sorting result. For example, for resources with higher priority scores, a higher loading weight can be assigned to give them a higher priority when loading resources. In this way, the purpose of dynamically adjusting the resource loading weights of the host and plug-in according to the device status and resource usage is achieved.

[0099] Establish a resource conflict monitoring mechanism in the proxy service. When the hybrid loader detects a resource with the same name or other resource conflicts between the host and the plugin while loading a resource, a resource conflict event is triggered. You can add conflict detection logic to the hybrid loader's resource loading method. When a resource conflict is detected, a resource conflict notification is sent to the proxy service.

[0100] After receiving a notification of a resource conflict event, the proxy service decides whether to load the host resource or the plug-in resource based on the previously assigned resource loading weight. Compare the loading weights of the host resource and the plug-in resource, and choose to load the resource with the higher loading weight. For the selected resource (whether it is a host resource or a plug-in resource), if it needs to be merged with another resource (for example, when both resources contain some useful information), use the MergedResources object to merge it. The MergedResources object is a tool class specifically used to merge resources. It can integrate the different parts of two resources to generate a new resource object. During the merging process, the corresponding merging strategy is adopted according to the type and content of the resource. For example, for layout files, the view components can be merged; for string resources, different string values ​​can be merged, etc. Through the MergedResources object, the effective merging of conflicting resources is achieved, ensuring that the application can correctly use the required resources.

[0101] In this embodiment, by deploying a proxy service within the host application and dynamically integrating host and plugin resources according to the above scheme, the conflicts and dependencies encountered by traditional resource loading mechanisms when handling host and plugin resources can be resolved. The use of a hybrid loader makes resource loading more flexible and efficient, and the creation of a standard interface standardizes communication and resource interaction between the host and plugin. The resource priority formula, the allocation of loading weights, and the resource conflict handling mechanism further improve the rationality and stability of resource loading, ensure the smooth implementation of Android Service plug-ins, and enhance the user experience and reliability of applications.

[0102] In some embodiments, in step S102 above, building a service lifecycle prediction model through a federated learning framework based on the multi-device service behavior data collected during the proxy service runtime specifically includes: Embed a data collection module in the proxy service to collect startup delays, memory peaks, abnormal termination frequencies, and thread occupancy rates through real-time monitoring of the plug-in service lifecycle to obtain time series data. Build a local LSTM prediction model based on time series data, and aggregate multi-device model parameters through a federated learning framework to generate a service lifecycle prediction model. Based on the service lifecycle prediction model, the crash probability and resource usage prediction value of the plug-in service are output. When the crash probability exceeds the preset crash probability threshold or the resource usage prediction value exceeds the available memory, the service startup is delayed or an isolated execution environment is allocated.

[0103] In this embodiment, a dedicated data acquisition module is designed and embedded within the host application's proxy service. This module, as an independent functional unit, is responsible for real-time monitoring of method calls within the plug-in service's lifecycle, ensuring accurate capture of key information during service operation. To ensure the stability and accuracy of data acquisition, the data acquisition module is lightweight and avoids excessive interference with the normal operation of the plug-in service. Furthermore, a thread-safe mechanism is implemented to ensure accurate data collection and processing in a multi-threaded environment.

[0104] Set timestamps before and after the onCreate and onStartCommand methods are called during the plugin service lifecycle. Calculate the difference between these timestamps to determine the plugin service startup delay. Startup delay reflects the service's response speed from initialization to the start of task execution and is a key indicator of service performance.

[0105] Using the memory management API provided by the Android system, periodically obtain the memory usage of the plug-in service during operation and record the maximum memory usage value as the peak memory usage. The peak memory usage value can help understand the memory resource consumption of the service during operation. Excessively high memory usage may cause insufficient device memory and affect system stability.

[0106] Monitor plug-in services for abnormal terminations, such as service crashes caused by uncaught exceptions. Calculate the abnormal termination frequency by counting the number of abnormal terminations per unit time. A high abnormal termination frequency indicates service stability issues that require timely optimization and resolution.

[0107] Within the plug-in service, thread management APIs are used to obtain the number of threads created by the service and then combined with the total number of threads on the device to calculate thread occupancy. Thread occupancy reflects the service's use of system thread resources. Excessive thread occupancy can lead to system thread scheduling constraints and affect the normal operation of other services.

[0108] The collected data, such as startup delay, memory peak, abnormal termination frequency, and thread occupancy, is organized chronologically to form time series data. Time series data can clearly show the changes in the running status of the plug-in service at different time points, providing rich feature information for subsequent model training.

[0109] A long short-term memory (LSTM) prediction model is built locally on the proxy service based on the collected time series data. The LSTM model has the advantage of processing time series data and can capture long-term dependencies in the data, making it suitable for predicting lifecycle metrics related to plug-in services. The local LSTM prediction model consists of an input layer, an LSTM layer, a fully connected layer, and an output layer. The input layer receives time series data and converts it into a format that the model can process. The LSTM layer is the core of the model, extracting features from the time series data and performing time series modeling using multiple LSTM units. The fully connected layer further processes and transforms the features extracted by the LSTM layer, and the output layer provides the prediction results.

[0110] The collected time series data is divided into a training set and a validation set. The training set is used to learn and adjust model parameters, while the validation set is used to evaluate model performance and generalization. The local LSTM prediction model is trained using the training set. During training, supervised learning is used, using the data from the first few time points in the time series data as input and the target metric (such as startup latency or memory peak) at the next time point as output. The model parameters are continuously adjusted to ensure that the model can predict the target metric as accurately as possible. The model is evaluated during training using the validation set to observe the model's prediction error on the validation set. Based on the evaluation results, model hyperparameters such as the learning rate, number of LSTM layers, and number of hidden layer neurons are adjusted to improve model performance.

[0111] A federated learning framework was built to aggregate the parameters of local LSTM prediction models trained on multiple devices. This framework uses a distributed architecture consisting of a central server and multiple participating devices (i.e., devices with the plug-in service deployed). The central server coordinates the entire federated learning process, including the collection, aggregation, and distribution of model parameters. Participating devices are responsible for training the model locally using their own data and uploading the resulting model parameters to the central server. After completing training of the local LSTM prediction model, each participating device uploads the resulting model parameters to the central server. Model parameters include the weight matrix and bias vector of the LSTM layer.

[0112] After receiving the model parameters uploaded by each device, the central server aggregates them using the federated averaging algorithm. The basic idea of ​​the federated averaging algorithm is to take a weighted average of the model parameters uploaded by each device to obtain global model parameters. Weights can be assigned based on factors such as device data volume and quality to ensure that the aggregated model fully utilizes the advantages of multi-device data. The central server distributes the aggregated global model parameters to each participating device. After receiving the global model parameters, the device uses them to update its local LSTM prediction model, completing a round of federated learning.

[0113] Repeating the model training, parameter uploading, aggregation, and distribution process for multiple rounds of federated learning, the process continues until the global model reaches stable performance or meets a preset stopping condition. The resulting service lifecycle prediction model incorporates the data characteristics and operational patterns of multiple devices, resulting in enhanced generalization and prediction accuracy.

[0114] The constructed service lifecycle prediction model is deployed to the proxy service on each device. During actual operation, when a new plug-in service startup request arrives, the proxy service inputs current relevant data (such as device status and plug-in service type) into the service lifecycle prediction model. The model then outputs the plug-in service's crash probability and resource usage prediction. The crash probability reflects the likelihood of the plug-in service crashing within a certain period of time, while the resource usage prediction includes the estimated usage of resources such as memory and thread usage.

[0115] Set a preset crash probability threshold and available memory threshold. When the crash probability output by the service lifecycle prediction model exceeds the preset crash probability threshold, it indicates that the plug-in service has a high crash risk; when the resource usage prediction value exceeds the available memory, it means that the plug-in service may not be able to run normally due to insufficient memory. When the above situation occurs, the proxy service takes corresponding decision-making measures. One measure is to delay the service startup to give the system more time for resource allocation and optimization, thereby reducing the risk of service crashes. Another measure is to allocate an isolated execution environment and run the plug-in service in a separate process or container to prevent it from affecting other services while ensuring that the service can run stably with limited resources.

[0116] In this embodiment, by embedding a data collection module within the proxy service to collect multi-device service behavior data and utilizing a federated learning framework to build a service lifecycle prediction model, the advantages of multi-device data are fully utilized to improve the model's accuracy and generalization capabilities. Decision-making based on the predicted values ​​output by the model effectively prevents plug-in service crashes and resource utilization, ensuring stable operation of the plug-in service across different devices, and improving user experience and system reliability.

[0117] Furthermore, the local LSTM prediction model is constructed based on the time series data, and the multi-device model parameters are aggregated through the federated learning framework to generate a service lifecycle prediction model, which specifically includes: Input the time series data into the pre-trained initial LSTM prediction model, calculate the forget gate, input gate, candidate memory and hidden state through the gating mechanism, and output the crash probability and resource occupancy prediction value through the fully connected layer to form a local LSTM prediction model; Upload the model parameters and data volume of the local LSTM prediction models of multiple devices to the federated server, aggregate the model parameters and data volume of the local LSTM prediction models of multiple devices using a weighted average algorithm, and generate a service lifecycle prediction model; Download the service lifecycle prediction model on the device and replace the local LSTM prediction model.

[0118] In this embodiment, a pre-trained initial LSTM prediction model is prepared in the early stages of model construction. This model has a specific structure and initial parameters, serving as the basis for building local models on each device. The initial model can be initially trained using a public dataset to learn some common time series feature extraction capabilities. The model structure includes an input layer, an LSTM layer, a fully connected layer, and an output layer. The input layer receives time series data, the LSTM layer is the core component responsible for processing time series information, the fully connected layer further processes the LSTM layer's output, and the output layer provides prediction results.

[0119] The time series data collected by the proxy service is fed into the pre-trained initial LSTM prediction model. This time series data includes information such as the plug-in service's startup delay, memory peak, abnormal termination frequency, and thread occupancy at different time points. This data is arranged in chronological order and reflects the changing trends in the plug-in service's operating status.

[0120] In the LSTM layer, the forget gate determines which information to discard from the cell state. It calculates a forgetting factor based on the current input time series data and the hidden state at the previous time step. The forgetting factor is a value between 0 and 1. When the forgetting factor is close to 0, the corresponding information is almost completely discarded; when it is close to 1, it is almost completely retained. Using the forgetting gate, the model can filter out historical information that is irrelevant or has little impact on the current prediction task.

[0121] The input gate determines what new information is added to the cell state. It also calculates an input factor based on the current input and the hidden state at the previous time step. The input factor controls the influx of new information, allowing the model to selectively incorporate features that are useful for prediction.

[0122] Based on the input factors calculated by the input gate and the current input, a candidate memory is generated. The candidate memory contains new information that may be added to the cell state and is a potential representation of the current input data.

[0123] The forget gate, input gate, and candidate memory are combined to update the cell state and hidden state. The cell state stores long-term historical information, while the hidden state is a comprehensive representation of the information at the current time step. By continuously updating the hidden state, the model can capture long-term dependencies in time series data.

[0124] After processing by the LSTM layer, the hidden state is input into the fully connected layer. The fully connected layer performs linear transformations and nonlinear activation operations on the hidden state, mapping high-dimensional features into a low-dimensional prediction space. The output of the fully connected layer is the crash probability and resource usage prediction of the plug-in service. The crash probability reflects the likelihood of the plug-in service crashing in the future. The resource usage prediction includes the estimated usage of resources such as memory and thread usage.

[0125] Through the above steps, a local LSTM prediction model for the current device is formed based on local time series data and the pre-trained initial LSTM prediction model. This model can preliminarily predict lifecycle-related indicators based on the running data of the plug-in service on the device.

[0126] After completing local LSTM prediction model training on each device, the model parameters and data volume used for training are uploaded to the federated server. Model parameters include the LSTM layer's weight matrix and bias vector, which record the model's ability to extract features and recognize patterns in the data during the learning process. Data volume information reflects the scale of data used to train the model on the device and is important for subsequent parameter aggregation. To ensure the security and privacy of data transmission, encryption technology can be used to encrypt the uploaded model parameters and data volume information. For example, data can be encrypted using a symmetric encryption algorithm, with only the federated server possessing the corresponding decryption key, thus preventing data theft or tampering during transmission.

[0127] After receiving model parameters and data volume information uploaded by multiple devices, the federated server aggregates these parameters using a weighted averaging algorithm. The basic idea behind this algorithm is to assign weights to model parameters based on the amount of data on each device. Devices with larger data volumes receive higher weights during the aggregation process. Specifically, for each model parameter (such as a weight in an LSTM layer), a weighted average of that parameter across all devices is calculated. In this way, the local model parameters of multiple devices are combined to generate global model parameters. This aggregation method leverages the data advantages of multiple devices, enabling the generated model to learn a wider range of common features and patterns.

[0128] Using the aggregated global model parameters, a service lifecycle prediction model is constructed. This model incorporates the data characteristics and operating patterns of multiple devices, resulting in stronger generalization and prediction accuracy. During the construction process, the global model parameters are assigned to a model instance with the same structure as the local LSTM prediction model, resulting in the final service lifecycle prediction model. This model can more accurately predict crash probabilities and resource usage of plug-in services based on operational data from different devices.

[0129] The federated server distributes the generated service lifecycle prediction model to each device. After receiving the model download notification, the device downloads the service lifecycle prediction model from the federated server via a secure network connection. Encryption technology is also used during the download process to ensure the security of the model data. The device replaces the existing local LSTM prediction model with the downloaded service lifecycle prediction model. This replacement process includes updating the model's structure and parameters to ensure the new model can run properly on the device. After the model replacement is complete, the proxy service on the device uses the new service lifecycle prediction model to predict the lifecycle of the plug-in service. During the subsequent plug-in service startup process, the proxy service takes appropriate decisions based on the model's output prediction value, such as delaying service startup or allocating an isolated execution environment, to ensure the stable operation of the plug-in service.

[0130] In this embodiment, by building a local LSTM prediction model based on time series data and aggregating model parameters across multiple devices using a federated learning framework, we can fully leverage the data resources of multiple devices and improve the accuracy and generalization of the service lifecycle prediction model. After downloading and replacing the local model on the device side, we can accurately predict the crash probability and resource usage of the plug-in service, allowing us to take proactive measures to ensure stable service operation, improving user experience and system reliability.

[0131] In some embodiments, in step S103 above, generating a dynamic scheduling strategy based on the output of the service lifecycle prediction model in combination with device power, network type, and CPU load specifically includes: Calculate dynamic thresholds based on the crash probability and resource usage prediction values ​​of the plug-in service output by the service lifecycle prediction model, combined with the device's current power level, network type, and CPU load. Determine a scheduling strategy based on a dynamic threshold, a crash probability, and a resource occupancy prediction value, wherein the scheduling strategy is immediate start, delayed start, or sandbox isolation; When sandbox isolation is selected, a separate container is allocated and its memory and CPU resource limits are limited; If a plug-in service is delayed in starting, add the plug-in service to the priority queue and re-evaluate the scheduling policy after the device power or CPU load improves.

[0132] In this embodiment, the service lifecycle prediction model running on the device will output the crash probability and resource occupancy prediction value of the plug-in service based on the collected plug-in service runtime data. The crash probability reflects the possibility of the plug-in service crashing in the future, and the resource occupancy prediction value includes the expected usage of resources such as memory occupancy and CPU occupancy. The current power level, network type and CPU load information of the device are obtained in real time through the system interface of the device. The power level of the device can be obtained through the battery management module and expressed as a percentage; the network type can be divided into different types such as Wi-Fi, 4G, 5G, etc. Different network types have different impacts on the operation of the service. For example, Wi-Fi networks are usually more stable and have higher bandwidth; the CPU load can be obtained through the system performance monitoring tool, which indicates the current CPU usage rate.

[0133] Set threshold adjustment coefficients for different battery ranges. For example, when the device battery level is below 20%, the threshold adjustment coefficient is set to 0.8 to conserve power, lowering the dynamic threshold and making the service startup condition more stringent. When the battery level is between 20% and 50%, the adjustment coefficient is set to 0.9. When the battery level is above 50%, the adjustment coefficient is set to 1.0, indicating that the threshold is not adjusted based on battery factors.

[0134] Different network types are assigned different weights. Wi-Fi networks are weighted at 1.0, 4G networks at 0.8, and 5G networks at 1.2 (assuming 5G network performance is superior, the threshold can be relaxed appropriately). Multiply the network type weight by the base threshold to obtain the adjusted threshold for the network type.

[0135] When the CPU load is higher than 80%, to avoid system overload, the threshold adjustment coefficient is set to 0.7; when the CPU load is between 50% and 80%, the adjustment coefficient is set to 0.85; when the CPU load is lower than 50%, the adjustment coefficient is set to 1.0.

[0136] Determine the basic threshold. This threshold can be set based on historical data and experience. For example, the basic threshold for crash probability is 30%, and the basic threshold for resource usage prediction (such as memory usage) is 70% of the device's total memory. Then, calculate the dynamic threshold based on the adjustment factors for power consumption, network type, and CPU load. For example, the dynamic threshold for crash probability is calculated as follows: Dynamic crash probability threshold = Basic crash probability threshold × Power consumption adjustment factor × Network type weight × CPU load adjustment factor. The dynamic threshold for resource usage prediction is calculated similarly.

[0137] When the crash probability output by the service lifecycle prediction model is lower than the dynamic crash probability threshold, and the resource usage prediction value is lower than the dynamic resource usage prediction value threshold, the plug-in service is considered to be able to start immediately. This indicates that under the current device environment, the plug-in service has high stability and low resource consumption risk, and can start and run normally.

[0138] If the crash probability is higher than the dynamic crash probability threshold but the predicted resource usage is lower than the dynamic resource usage threshold, or if the predicted resource usage is higher than the dynamic resource usage threshold but the crash probability is lower than the dynamic crash probability threshold and the difference is within a certain range, the plug-in service startup is determined to be delayed. In this case, the plug-in service presents a certain risk, but it is not impossible to start. Delaying the startup allows the device environment to improve and mitigate the risk.

[0139] If the crash probability exceeds the dynamic crash probability threshold and the resource usage prediction value exceeds the dynamic resource usage prediction value threshold, the plug-in service is deemed to require sandbox isolation. In this case, the plug-in service has a high crash risk and consumes a lot of resources, and sandbox isolation can limit its impact on the system.

[0140] When sandbox isolation is adopted, the operating system or related management module on the device allocates a separate container for the plug-in service. This container is logically isolated from the rest of the system, with its own file system, process space, and network environment. This prevents plug-in service exceptions from affecting the rest of the system.

[0141] Set memory and CPU resource limits for independent containers based on the device's resources and the plug-in service's predicted resource usage. For CPU resources, set a limit on the number of CPU cores or a CPU usage cap based on the CPU load and the plug-in service's predicted CPU usage.

[0142] If a plug-in service is determined to be delayed, it will be added to a priority queue. The priority queue sorts plug-in services based on factors such as their importance and urgency. For example, certain business-critical plug-in services will be given a higher priority, while non-business-critical plug-in services will be given a lower priority.

[0143] Monitor the device's power level and CPU load in real time. When the device's power level increases or the CPU load decreases, a mechanism is triggered to re-evaluate the scheduling policy. During re-evaluation, the device's current power level, network type, and CPU load information are retrieved again, new dynamic thresholds are calculated, and the scheduling policy for the plug-in service is re-determined based on the latest output of the service lifecycle prediction model. If the conditions for immediate startup are met, the plug-in service is removed from the priority queue and started; if a delayed startup is still required, it remains in the queue awaiting the next evaluation.

[0144] In this embodiment, by generating a dynamic scheduling strategy based on the output of the service lifecycle prediction model and combining device power, network type, and CPU load, the startup and operation mode of the plug-in service can be flexibly adjusted according to the real-time changing device environment and service status. While ensuring the stable operation of the plug-in service, it rationally utilizes device resources to improve the overall system performance and user experience. The sandbox isolation strategy effectively reduces the impact of high-risk plug-in services on the system, and delayed startup and priority queue management optimize the timing and order of service startup, enabling the system to better cope with complex and changing environments.

[0145] In some embodiments, in step S104 above, based on the dynamic scheduling strategy, the plug-in metadata hash, the federated model fingerprint, and the device status snapshot are written into the blockchain smart contract, and the plug-in integrity is verified by the on-chain light node to obtain the blockchain verification result, which specifically includes: Based on the execution results of the dynamic scheduling strategy, the plugin metadata hash, federation model fingerprint and device status snapshot are generated, and the on-chain record hash is calculated through the cascade hash algorithm; Encapsulate the on-chain record hash and device digital signature into a transaction and write it into the blockchain smart contract; Before the host loads the plug-in, it obtains the hash of the chain record stored on the chain through the blockchain light node and calculates the hash of the local data; If the hash of the on-chain record is inconsistent with the hash of the local data or the signature verification fails, the plugin is marked as untrusted.

[0146] In this embodiment, a dynamic scheduling policy is executed on the device, determining the plug-in scheduling method (immediate start, delayed start, or sandbox isolation) based on the service lifecycle prediction model output, device power, network type, CPU load, and other information. The execution results of the scheduling policy will record the relevant decision basis and data status.

[0147] Collect plugin metadata, including the plugin name, version number, developer information, and dependency list. Preprocess this metadata to remove irrelevant information and unify its format. Then, use a hash algorithm (such as SHA-256) to hash the preprocessed metadata to generate a plugin metadata hash. This hash value uniquely identifies the plugin metadata and changes if the metadata changes.

[0148] The federated model fingerprint identifies the service lifecycle prediction model currently used on the device. During the federated learning process, model parameters are continuously updated and aggregated. The federated model fingerprint can be generated by summarizing key model parameters (such as the weight matrix and bias vector of the LSTM layer). For example, a fixed-length string can be generated by concatenating and hashing key eigenvalues ​​from the model parameters to form the federated model fingerprint.

[0149] When executing a dynamic scheduling policy, the current device status information is obtained, including device power, network type, CPU load, memory usage, etc. This device status information is organized according to a specific format to form a device status snapshot. A hash calculation is also performed on the device status snapshot to generate a device status snapshot hash.

[0150] Using a concatenated hashing algorithm, the plugin metadata hash, federation model fingerprint, and device state snapshot hash are concatenated in a predetermined order. For example, the plugin metadata hash, federation model fingerprint, and device state snapshot hash are concatenated into a long string, which is then hashed again to produce the on-chain record hash. The on-chain record hash comprehensively reflects the plugin metadata, federation model, and device state, and is subsequently recorded and verified on the blockchain.

[0151] The device uses its own private key to digitally sign the hash of the on-chain record. Digital signatures are a form of authentication based on asymmetric encryption technology that ensures the data's origin is authentic and has not been tampered with. The device's private key is a unique encryption key, and only a verifier with the corresponding public key can verify the validity of the signature.

[0152] The on-chain record hash and device digital signature are encapsulated into a transaction. A transaction is the basic unit of operation on the blockchain, containing the data to be recorded on the blockchain and related verification information. During the encapsulation process, the on-chain record hash and device digital signature are organized into a specific data structure according to the blockchain's transaction format requirements, and necessary information such as the transaction identifier and timestamp are added. The encapsulated transaction is then sent to the blockchain network and, through the blockchain's consensus mechanism, written into a smart contract. A smart contract is a self-executing contract whose code is stored on the blockchain and automatically executes corresponding operations when pre-set conditions are met.

[0153] Deploy a blockchain light node on the host device. A blockchain light node is a type of node in a blockchain network. It does not store the complete blockchain data, but instead interacts with full nodes to obtain required data and verification information. Light nodes offer advantages such as low resource usage and fast response times, making them suitable for resource-constrained environments such as mobile devices. Before loading the plugin on the host, the light node retrieves the on-chain record hash stored on the blockchain network. The light node sends a query request to a full node in the blockchain network, specifying the information related to the on-chain record hash (such as the transaction identifier) ​​to be retrieved. The full node searches the locally stored blockchain data based on the request and returns the retrieved on-chain record hash to the light node.

[0154] The light node obtains the plugin's local metadata, the currently used federated model, and device status information from the host device. It then calculates the local plugin metadata hash, the local federated model fingerprint, and the local device state snapshot hash using the same method used to generate the on-chain record hash. It also calculates the local data hash using a cascade hashing algorithm. The light node compares the calculated local data hash with the on-chain record hash obtained from the chain. Simultaneously, it verifies the device's digital signature corresponding to the on-chain record hash using the device's public key. If the on-chain record hash matches the local data hash and the signature verification succeeds, the plugin has not been tampered with since the on-chain record hash was generated. The plugin is trusted and can be loaded normally by the host. If the on-chain record hash does not match the local data hash, or if the signature verification fails, the plugin may have been tampered with or has an anomaly. The light node marks the plugin as untrusted and sends a warning message to the host, preventing the plugin from loading.

[0155] In this embodiment, by generating plugin metadata hashes, federated model fingerprints, and device status snapshots based on a dynamic scheduling strategy and then writing them into a blockchain smart contract for verification, the integrity of the plugin before loading can be effectively ensured. The blockchain's immutability ensures the authenticity and reliability of recorded data, while the light node's fast verification mechanism improves verification efficiency and reduces resource consumption on the host device. This significantly enhances the security of the Android Service plugin system and reduces the security risks associated with plugin tampering.

[0156] In some embodiments, in the above step S105, if the blockchain verification result is determined to be a failure, the incremental update process of the service lifecycle prediction model is triggered, and the dynamic scheduling strategy is regenerated, specifically including: If the blockchain verification result fails, the federated model difference and digital signature are downloaded from the decentralized storage network, and the legitimacy of the signature is verified using the server public key; When the signature verification passes, the federated model difference is merged into the local model weight based on the incremental learning rate to generate an updated service lifecycle prediction model; Based on the updated service lifecycle prediction model, the crash probability and resource usage prediction values ​​of the plug-in service are recalculated, and a new dynamic scheduling strategy is generated. If the new dynamic scheduling policy requires termination of the service, the current plug-in instance is destroyed and the exception log is sent back to the federated server.

[0157] In this embodiment, when the blockchain verification result fails, the plug-in management system on the device immediately triggers an incremental update process for the service lifecycle prediction model. This is because a verification failure may indicate that the local model data is inconsistent with the on-chain records or there is a potential risk of malicious tampering, requiring an update to restore its accuracy and credibility.

[0158] The plugin management system communicates with the decentralized storage network. This decentralized storage network stores model delta data generated at different stages of the federated learning process. This delta data reflects changes in the model across different training batches. Based on the local model version information, the plugin management system sends a request to the decentralized storage network to retrieve the federated model delta file corresponding to the local model version and the digital signature corresponding to this delta file. The digital signature is generated by the server in the federated learning process using its private key to encrypt the model delta file and ensure the legitimacy and integrity of the delta file.

[0159] The plugin management system pre-stores the public key of the federated learning server. After obtaining the federated model delta file and digital signature, the server's public key is used to verify the digital signature. This verification process primarily uses an asymmetric encryption algorithm to decrypt the digital signature using the public key. The decrypted signature is then compared with the hash value of the model delta file. If the comparison results match, the digital signature is valid, the model delta file has not been tampered with during transmission, and it indeed comes from a legitimate federated learning server. If the comparison results are inconsistent, the signature verification has failed, the model delta file is untrustworthy, the incremental update process is terminated, and a warning message is issued to the user or system administrator.

[0160] After signature verification, the plugin management system needs to determine the incremental learning rate based on the current system operating status and model characteristics. The incremental learning rate is a parameter used to control the magnitude of model weight updates. It determines the degree of influence of the federated model delta on the local model weights. For example, if the device is currently low on power, the incremental learning rate can be appropriately lowered to avoid excessive computing resource consumption due to model updates. If the device performance is good and the network environment is stable, a relatively high incremental learning rate can be used to speed up model updates. The incremental learning rate can be determined based on factors such as historical update experience, device performance indicators, and the urgency of the current task. The plugin management system merges the federated model delta into the local model weights according to the determined incremental learning rate.

[0161] After completing an incremental model update, you can use some local test data to perform a simple evaluation of the updated model. For example, use some plug-in service run data with known results, input it into the updated model, and calculate the deviation between the model's output of crash probability and resource usage predictions and the actual results. If the deviation is within an acceptable range, the model update is effective. If the deviation is large, you may need to further adjust the incremental learning rate or re-obtain the federated model delta for an update.

[0162] The plug-in management system applies the updated service lifecycle prediction model to plug-in service data. This model collects plug-in service runtime data, current device status information, and other information, and then feeds it into the updated model to recalculate the plug-in service's crash probability and resource usage predictions. By incorporating more federated learning knowledge, the updated model can more accurately predict the plug-in service's operating status and resource requirements.

[0163] Based on the recalculated crash probability and resource usage predictions for the plug-in service, combined with information such as the device's current battery level, network type, and CPU load, the dynamic scheduling policy is regenerated. The rules for generating the dynamic scheduling policy remain the same as before. For example, when the crash probability is below a certain threshold and the resource usage predictions are reasonable, the plug-in service is considered to be able to start immediately; when there is a certain risk, the startup is delayed; and when the risk is high, the sandbox isolation policy is adopted. By regenerating the dynamic scheduling policy, the plug-in service is ensured to be properly scheduled based on the latest model predictions and the device environment.

[0164] After generating a new dynamic scheduling policy, the plug-in management system checks whether the new scheduling policy requires the termination of the current plug-in service. If the new scheduling policy, based on the updated model prediction results and the device environment, determines that the current plug-in service has a high crash risk or resource usage problem that cannot be effectively addressed through other scheduling methods (such as delayed start and sandbox isolation), the current plug-in service will be terminated.

[0165] When it is determined that a service needs to be terminated, the plug-in management system will immediately destroy the currently running plug-in instance. The destruction process includes releasing system resources occupied by the plug-in, such as memory and CPU threads, and cleaning up temporary files and data related to the plug-in, ensuring the rational use of system resources and system stability.

[0166] When the plug-in instance is destroyed, the plug-in management system collects log information related to the plug-in service exception. The exception log includes the plug-in service's operation history, model prediction results, device environment information, and the specific reason that triggered the service termination. The exception log is then transmitted back to the federated server via a secure network channel. Based on this exception log information, the federated server can further analyze the model's performance on different devices, optimize the federated learning process, improve model performance, and provide a reference for model updates on other devices.

[0167] In this embodiment, by triggering the incremental update process of the service lifecycle prediction model when blockchain verification fails and regenerating the dynamic scheduling policy, potential model issues can be promptly fixed, improving the accuracy and reliability of the plug-in service scheduling policy. This incremental update method for the federated model reduces the computing resources and network bandwidth consumption of the model update, improving update efficiency. The return mechanism for exception logs facilitates the continuous optimization and improvement of the federated learning system, enhancing the security and stability of the entire Android Service plug-in system.

[0168] Reference Figure 2 An embodiment of the present invention provides an Android Service plug-in implementation system 2, wherein the system 2 specifically includes: The proxy service deployment module 201 is used to deploy the proxy service in the host application, create the standard interface IServiceInterface, and integrate the host and plug-in resources by overriding the context loading method of the Android Service; A prediction model building module 202 is configured to build a service lifecycle prediction model using a federated learning framework based on multi-device service behavior data collected during proxy service operation. The service lifecycle prediction model is configured to output a crash probability and resource usage prediction value for the plug-in service. The scheduling strategy generation module 203 is used to generate a dynamic scheduling strategy based on the output of the service lifecycle prediction model and in combination with the device power, network type and CPU load; The blockchain verification module 204 is used to write the plug-in metadata hash, federated model fingerprint, and device status snapshot into the blockchain smart contract based on the dynamic scheduling strategy, and verify the plug-in integrity through the on-chain light node to obtain the blockchain verification result; The model incremental update module 205 is used to trigger the incremental update process of the service lifecycle prediction model and regenerate the dynamic scheduling strategy if the blockchain verification result is determined to be a failure.

[0169] It is understandable that if Figure 1 The contents of the embodiment of the Android Service plug-in implementation method shown in the figure are applicable to the embodiment of the Android Service plug-in implementation system. The functions specifically implemented by the embodiment of the Android Service plug-in implementation system are the same as those in the embodiment of the Android Service plug-in implementation system. Figure 1 The Android Service plug-in implementation method shown in the embodiment is the same as that shown in the embodiment, and the beneficial effects achieved are the same as those shown in the embodiment. Figure 1 The beneficial effects achieved by the embodiment of the Android Service plug-in implementation method shown are also the same.

[0170] It should be noted that the information interaction, execution process and other contents between the above-mentioned systems are based on the same concept as the embodiment of the method of the present invention. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0171] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0172] Reference Figure 3 , an embodiment of the present invention further provides a computer device 3, comprising: a memory 302 and a processor 301 and a computer program 303 stored in the memory 302, when the computer program 303 is executed on the processor 301, implements the Android Service plug-in implementation method as described in any one of the above methods.

[0173] The computer device 3 may be a desktop computer, a notebook computer, a PDA, a cloud server or other computing devices. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that Figure 3 This is merely an example of the computer device 3 and does not constitute a limitation on the computer device 3 . The computer device 3 may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the computer device 3 may also include input and output devices, network access devices, etc.

[0174] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor.

[0175] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard drive or memory of the computer device 3. In other embodiments, the memory 302 may also be an external storage device of the computer device 3, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the computer device 3. Furthermore, the memory 302 may include both an internal storage unit of the computer device 3 and an external storage device. The memory 302 is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of the computer program. The memory 302 may also be used to temporarily store data that has been output or is about to be output.

[0176] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for implementing Android Service plug-in as described in any one of the above methods is implemented.

[0177] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by using a computer program to instruct the relevant hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a camera / terminal device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, removable hard drives, magnetic disks, or optical disks. In some jurisdictions, based on legislation and patent practice, computer-readable media cannot be electric carrier signals or telecommunication signals.

[0178] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0179] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0180] In the embodiments disclosed in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0181] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A method for implementing Android Service plug-in, characterized in that: The method specifically includes: Deploy the proxy service in the host application, create the standard interface IServiceInterface, and integrate the host and plug-in resources by overriding the context loading method of AndroidService; Based on the multi-device service behavior data collected during proxy service operation, a service lifecycle prediction model is constructed through a federated learning framework. The service lifecycle prediction model is used to output the crash probability and resource usage prediction value of the plug-in service; Generate dynamic scheduling strategies based on the output of the service lifecycle prediction model, combined with device power, network type, and CPU load; Based on the dynamic scheduling strategy, the plug-in metadata hash, federated model fingerprint, and device status snapshot are written into the blockchain smart contract. The plug-in integrity is verified by the on-chain light node to obtain the blockchain verification result. If the blockchain verification result is determined to be a failure, the incremental update process of the service lifecycle prediction model is triggered and the dynamic scheduling strategy is regenerated.

2. The method according to claim 1, characterized in that The proxy service is deployed in the host application, the standard interface IServiceInterface is created, and the host and plug-in resources are integrated by rewriting the context loading method of the Android Service. Specifically, it includes: Deploy the proxy service in the host application, inherit android.app.Service and rewrite the getClassLoader method and getResources method to achieve dynamic fusion of host and plug-in resources and obtain a hybrid loader; Based on the hybrid loader, a standard interface IServiceInterface is created in the proxy service. The standard interface IServiceInterface includes the resource injection method insertContext and the lifecycle methods onCreate and onStartCommand. A resource priority formula is constructed based on device power, network type, and historical resource usage frequency, and resource loading weights of the host and plug-ins are dynamically allocated based on the resource priority formula. In response to resource conflict events, based on resource loading weights, host or plug-in resources are selected for loading, and conflicting resources are merged through the MergedResources object.

3. The method according to claim 1, characterized in that The service lifecycle prediction model is constructed through a federated learning framework based on the multi-device service behavior data collected during the proxy service runtime, specifically including: Embed a data collection module in the proxy service to collect startup delays, memory peaks, abnormal termination frequencies, and thread occupancy rates through real-time monitoring of the plug-in service lifecycle to obtain time series data. Build a local LSTM prediction model based on time series data, and aggregate multi-device model parameters through a federated learning framework to generate a service lifecycle prediction model. Based on the service lifecycle prediction model, the crash probability and resource usage prediction value of the plug-in service are output. When the crash probability exceeds the preset crash probability threshold or the resource usage prediction value exceeds the available memory, the service startup is delayed or an isolated execution environment is allocated.

4. The method according to claim 3, characterized in that The method builds a local LSTM prediction model based on time series data and aggregates multi-device model parameters through a federated learning framework to generate a service lifecycle prediction model. Specifically, it includes: Input the time series data into the pre-trained initial LSTM prediction model, calculate the forget gate, input gate, candidate memory and hidden state through the gating mechanism, and output the crash probability and resource occupancy prediction value through the fully connected layer to form a local LSTM prediction model; Upload the model parameters and data volume of the local LSTM prediction models of multiple devices to the federated server, aggregate the model parameters and data volume of the local LSTM prediction models of multiple devices using a weighted average algorithm, and generate a service lifecycle prediction model; Download the service lifecycle prediction model on the device and replace the local LSTM prediction model.

5. The method according to claim 1, wherein The output of the service lifecycle prediction model is combined with the device power, network type, and CPU load to generate a dynamic scheduling strategy, specifically including: Calculate dynamic thresholds based on the crash probability and resource usage prediction values ​​of the plug-in service output by the service lifecycle prediction model, combined with the device's current power level, network type, and CPU load. Determine a scheduling strategy based on a dynamic threshold, a crash probability, and a resource occupancy prediction value, wherein the scheduling strategy is immediate start, delayed start, or sandbox isolation; When sandbox isolation is selected, a separate container is allocated and its memory and CPU resource limits are limited; If a plug-in service is delayed in starting, add the plug-in service to the priority queue and re-evaluate the scheduling policy after the device power or CPU load improves.

6. The method according to claim 1, characterized in that Based on the dynamic scheduling strategy, the plug-in metadata hash, federated model fingerprint, and device status snapshot are written into the blockchain smart contract, and the plug-in integrity is verified by the on-chain light node to obtain the blockchain verification result, which specifically includes: Based on the execution results of the dynamic scheduling strategy, the plugin metadata hash, federation model fingerprint and device status snapshot are generated, and the on-chain record hash is calculated through the cascade hash algorithm; Encapsulate the on-chain record hash and device digital signature into a transaction and write it into the blockchain smart contract; Before the host loads the plug-in, it obtains the hash of the chain record stored on the chain through the blockchain light node and calculates the hash of the local data; If the hash of the on-chain record is inconsistent with the hash of the local data or the signature verification fails, the plugin is marked as untrusted.

7. The method according to claim 1, characterized in that If the blockchain verification result is determined to be a failure, the incremental update process of the service lifecycle prediction model is triggered, and the dynamic scheduling strategy is regenerated, specifically including: If the blockchain verification result fails, the federated model difference and digital signature are downloaded from the decentralized storage network, and the legitimacy of the signature is verified using the server public key; When the signature verification passes, the federated model difference is merged into the local model weight based on the incremental learning rate to generate an updated service lifecycle prediction model; Based on the updated service lifecycle prediction model, the crash probability and resource usage prediction values ​​of the plug-in service are recalculated, and a new dynamic scheduling strategy is generated. If the new dynamic scheduling policy requires termination of the service, the current plug-in instance is destroyed and the exception log is sent back to the federated server.

8. An Android Service plug-in implementation system, characterized in that: The system specifically includes: The proxy service deployment module is used to deploy the proxy service in the host application, create the standard interface IServiceInterface, and integrate the host and plug-in resources by overriding the context loading method of Android Service; A prediction model building module is used to build a service lifecycle prediction model through a federated learning framework based on the multi-device service behavior data collected during the proxy service runtime. The service lifecycle prediction model is used to output the crash probability and resource usage prediction value of the plug-in service; The scheduling strategy generation module is used to generate dynamic scheduling strategies based on the output of the service lifecycle prediction model, combined with device power, network type, and CPU load; The blockchain verification module is used to write the plug-in metadata hash, federated model fingerprint, and device status snapshot into the blockchain smart contract based on the dynamic scheduling strategy, and verify the plug-in integrity through the on-chain light node to obtain the blockchain verification result; The model incremental update module is used to trigger the incremental update process of the service lifecycle prediction model and regenerate the dynamic scheduling strategy if the blockchain verification result is determined to be a failure.

9. A computer device, characterized in that: include: A memory, a processor, and a computer program stored in the memory, which, when executed on the processor, implements the Android Service plug-in implementation method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a processor, the method for implementing Android Service plug-in according to any one of claims 1 to 7 is implemented.

Images