Disclosure of Invention
In view of the above, the present invention has been made to provide a method for using services in a plug-in and a corresponding device that overcome or at least partially solve the above problems.
According to an aspect of the present invention, there is provided a method of using a service in a plug-in, including:
defining a client class used for a user of the plug-in service to operate the plug-in service and defining a server class corresponding to a manager for managing the plug-in service;
when a user needs to use the target plug-in service, calling a first appointed class member in the client class, and acquiring an interface of a manager of the target plug-in service by the first appointed class member;
and realizing the server class by utilizing an interface of a manager of the target plug-in service, and further providing the target plug-in service for a user by the server class.
Optionally, the operation performed on the plug-in service comprises at least one of:
starting the plug-in service, stopping the plug-in service, binding the plug-in service and unbinding the plug-in service.
Optionally, before the obtaining, by the first specified class member, the interface of the manager of the target plug-in service, the method further comprises:
and calling a second appointed class member in the client class, and acquiring the target process of the target plug-in service by the second appointed class member.
Optionally, the obtaining, by the second specified class member, the target process where the target plug-in service is located includes:
acquiring a ServiceInfo object of the target plug-in service by the second specified class member;
acquiring a ProcessName attribute of the target plug-in service by utilizing the ServiceInfo object of the target plug-in service;
and acquiring a target process of the target plug-in service according to the ProcessName attribute of the target plug-in service.
Optionally, the acquiring the target process where the target plug-in service is located according to the ProcessName attribute of the target plug-in service includes:
acquiring a predefined process index, wherein the process index comprises an index value of a process and a corresponding process;
and searching the target process corresponding to the index value of the target process in the process index.
Optionally, the obtaining, by the first specified class member, an interface of a manager of the target plug-in service includes:
and acquiring an interface of a manager of the target plug-in service by the first appointed class member based on the target process of the target plug-in service.
Optionally, after a target process where the target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed and cached to a specified object;
the method for acquiring the interface of the manager of the target plug-in service by the first appointed class member based on the target process of the target plug-in service comprises the following steps:
calling the cached specified object by the first specified class member to acquire a target process of the target plug-in service;
and acquiring an interface of a manager of the target plug-in service from a target process where the target plug-in service is located.
Optionally, the obtaining, by the first specified class member, an interface of a manager of the target plug-in service based on the target process where the target plug-in service is located includes:
judging whether a target process where the target plug-in service is located exists or not;
if so, directly acquiring an interface of a manager of the target plug-in service from a target process where the target plug-in service is located;
if not, starting a target process of the target plug-in service, constructing an interface of a manager of the target plug-in service, and further acquiring the constructed interface of the manager of the target plug-in service.
Optionally, if the target process in which the target plug-in service is located is a resident process, acquiring an interface of a manager of the target plug-in service from the target process in which the target plug-in service is located includes:
calling a PluginProcessMain.getPluginHost () method to obtain an IPluginHost object;
invoking IPluginHost. fetchServiceServer () method to obtain the interface of the manager of the target plug-in service.
Optionally, the providing, by the server class, the target plug-in service to the user includes:
and the client process of the client class is communicated with the target process of the server class, and the target plug-in service is provided for a user.
Optionally, the step of communicating between the client process where the client class is located and the target process where the server class is located to provide the target plug-in service to the user includes:
the client process of the client class uses a BindProxy object to communicate with the BinderStub of the target process of the server class through the first appointed class member;
after receiving the message, the Binder Stub forwards the message to the Stub of the server class, and the Stub of the server class forwards the message to the server class;
the server class provides the target plug-in service to a user based on the message.
Optionally, the client class is a PluginServiceClient class, the server class is a PluginServiceServer class, and an interface of the manager of the target plug-in service is an IPluginServiceServer interface.
Optionally, the IPluginServiceServer interface is an android interface definition language aid l interface.
Optionally, after the target process where the target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed and cached to a specified object, and the method further includes:
detecting whether a target process in which the target plug-in service is positioned is terminated or not;
and if the target process of the target plug-in service is detected to be terminated, calling the cached specified object to clear the target process of the target plug-in service.
According to another aspect of the present invention, there is also provided an apparatus for using a service in a plug-in, including:
the system comprises a definition module and a service module, wherein the definition module is suitable for defining a client class used for a user of the plug-in service to operate the plug-in service and defining a server class corresponding to a manager for managing the plug-in service;
the acquisition module is suitable for calling a first appointed class member in the client class when a user needs to use the target plug-in service, and acquiring an interface of a manager of the target plug-in service by the first appointed class member;
and the providing module is suitable for realizing the server class by utilizing an interface of a manager of the target plug-in service, and further providing the target plug-in service to a user by the server class.
Optionally, the operation performed on the plug-in service comprises at least one of:
starting the plug-in service, stopping the plug-in service, binding the plug-in service and unbinding the plug-in service.
Optionally, the obtaining module is further adapted to:
and before the first appointed class member acquires the interface of the manager of the target plug-in service, calling a second appointed class member in the client class, and acquiring the target process of the target plug-in service by the second appointed class member.
Optionally, the obtaining module is further adapted to:
acquiring a ServiceInfo object of the target plug-in service by the second specified class member;
acquiring a ProcessName attribute of the target plug-in service by utilizing the ServiceInfo object of the target plug-in service;
and acquiring a target process of the target plug-in service according to the ProcessName attribute of the target plug-in service.
Optionally, the ProcessName attribute of the target plug-in service includes an index value of the target process, and the obtaining module is further adapted to:
acquiring a predefined process index, wherein the process index comprises an index value of a process and a corresponding process;
and searching the target process corresponding to the index value of the target process in the process index.
Optionally, the obtaining module is further adapted to:
and acquiring an interface of a manager of the target plug-in service by the first appointed class member based on the target process of the target plug-in service.
Optionally, after a target process where the target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed and cached to a specified object;
the acquisition module is further adapted to:
calling the cached specified object by the first specified class member to acquire a target process of the target plug-in service;
and acquiring an interface of a manager of the target plug-in service from a target process where the target plug-in service is located.
Optionally, the obtaining module is further adapted to:
judging whether a target process where the target plug-in service is located exists or not;
if so, directly acquiring an interface of a manager of the target plug-in service from a target process where the target plug-in service is located;
if not, starting a target process of the target plug-in service, constructing an interface of a manager of the target plug-in service, and further acquiring the constructed interface of the manager of the target plug-in service.
Optionally, if the target process in which the target plug-in service is located is a resident process, the obtaining module is further adapted to:
calling a PluginProcessMain.getPluginHost () method to obtain an IPluginHost object;
invoking IPluginHost. fetchServiceServer () method to obtain the interface of the manager of the target plug-in service.
Optionally, the providing module is further adapted to:
and the client process of the client class is communicated with the target process of the server class, and the target plug-in service is provided for a user.
Optionally, the providing module is further adapted to:
the client process of the client class uses a BindProxy object to communicate with the BinderStub of the target process of the server class through the first appointed class member;
after receiving the message, the Binder Stub forwards the message to the Stub of the server class, and the Stub of the server class forwards the message to the server class;
the server class provides the target plug-in service to a user based on the message.
Optionally, the client class is a PluginServiceClient class, the server class is a PluginServiceServer class, and an interface of the manager of the target plug-in service is an IPluginServiceServer interface.
Optionally, the IPluginServiceServer interface is an android interface definition language aid l interface.
Optionally, after the target process where the target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed and cached to a specified object, and the apparatus further includes:
the detection module is suitable for detecting whether a target process in which the target plug-in service is positioned is terminated;
and the clearing module is suitable for calling the cached specified object to clear the target process of the target plug-in service if the detection module detects that the target process of the target plug-in service is terminated.
The embodiment of the invention designs a similar C/S architecture, wherein a user of the plug-in service is a client, a provider of the plug-in service is a server, each server is provided with a manager for managing the plug-in service in a process, and the plug-in service is managed by using a server class corresponding to the manager. When the user needs to use the target plug-in service, a first specified class member in the client class is called, the first specified class member acquires an interface of the manager of the target plug-in service, the server class is realized by using the interface of the manager of the target plug-in service, and the server class provides the target plug-in service for the user. Therefore, the embodiment of the invention can effectively realize the management of the plug-in service without upgrading the host program or adding the pit position of the service in the configuration file android manifest.
The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.
The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments thereof, taken in conjunction with the accompanying drawings.
Detailed Description
Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
To solve the above technical problem, an embodiment of the present invention provides a method for using a service in a plug-in. Fig. 1 shows a flowchart of a method of using a service in a plug-in according to an embodiment of the present invention. As shown in fig. 1, the method may include at least the following steps S102 to S106.
Step S102, a client class used for a user of the plug-in service to operate the plug-in service is defined, and a server class corresponding to a manager for managing the plug-in service is defined.
And step S104, when the user needs to use the target plug-in service, calling a first appointed class member in the client class, and acquiring the interface of the manager of the target plug-in service by the first appointed class member.
And S106, realizing a server class by using an interface of a manager of the target plug-in service, and providing the target plug-in service to a user by the server class.
The embodiment of the invention designs a similar C/S architecture, wherein a user of the plug-in service is a client, a provider of the plug-in service is a server, each server is provided with a manager for managing the plug-in service in a process, and the plug-in service is managed by using a server class corresponding to the manager. When the user needs to use the target plug-in service, a first specified class member in the client class is called, the first specified class member acquires an interface of the manager of the target plug-in service, the server class is realized by using the interface of the manager of the target plug-in service, and the server class provides the target plug-in service for the user. Therefore, the embodiment of the invention can effectively realize the management of the plug-in service without upgrading the host program or adding the pit position of the service in the configuration file android manifest.
In the embodiment of the present invention, the user of the plug-in service may be any plug-in, and the plug-in service provided by the provider of the plug-in service may be backup data, harassment interception, searching, killing and repairing, computer cleaning, optimization and acceleration, broadband velometer, emergency box for network disconnection, free wifi, DNS (Domain Name System) optimization, traffic firewall, online game accelerator, game safe, file shredder, System emergency box, and the like, but the present invention is not limited thereto.
In the above step S102, the operation performed on the plug-in service may include starting the plug-in service, stopping the plug-in service, binding the plug-in service, unbinding the plug-in service, and the like, but the present invention is not limited thereto. For example, the defined client class is a plug service client class, and further, methods in the class may be startService (open plug-in service), stopService (stop plug-in service), bindService (bind plug-in service), unbind service (unbind plug-in service), stopsel (stop service in plug-in service, which should be called in plug-in service), getProcessByComponentName (internal method, which acquires plug-in information through ComponentName, and finally acquires process information of a service to be loaded), and so on. In an alternative embodiment of the present invention, the above method may be a static method, with the call syntax being "class name. static member name", i.e. accessed directly by the class name plus a ". -" number.
In addition, the server class defined in step S102 may be a plug service class, and further methods in the class may be startService (open plug-in service), stopService (stop plug-in service), bindService (bind plug-in service), unbind service (unbind plug-in service), and so on.
In step S104, when the user needs to use the target plug-in service, a first specified class member in the client class is called, where the first specified class member is a static variable in the client class and can be directly accessed by adding a ". lam" number to the class name. The static variables are declared in the client class, and the memory is defined and allocated outside the client class. For example, in the PluginServiceClient class of the client class, the first specified class member is PluginServiceServerFetcher, and the PluginServiceServerFetcher is used for acquiring an interface of a manager of the target plug-in service, namely an IPluginServiceServer interface. In an optional embodiment of the present invention, the IPluginServiceServer Interface may be an AIDL (Android Interface Definition Language) Interface.
In an optional embodiment of the present invention, before the interface of the manager of the target plug-in service is obtained by the first specified class member in step S104, a second specified class member in the client class is called, and the target process where the target plug-in service is located is obtained by the second specified class member. The second specified class member here may be the getProcessByComponentName method as mentioned earlier.
When the second appointed class member acquires the target process of the target plug-in service, the invention provides an optional scheme, namely, firstly, the second appointed class member acquires the ServiceInfo object of the target plug-in service; then, acquiring a ProcessName attribute of the target plug-in service by utilizing the ServiceInfo object of the target plug-in service; and further acquiring a target process where the target plug-in service is located according to the ProcessName attribute of the target plug-in service. The ServiceInfo object of the target plug-in Service required to be acquired here is self-contained in an Android (Android) system, and is used for describing information of Service in a configuration file Android manifest. The ServiceInfo object may be obtained in a variety of manners, for example, if the ComponentList includes a list of all components of the plug-in, the list of all components of the plug-in may be obtained by calling a factory. For another example, the PackageInfo in the plug-in may be parsed by itself, and the ServiceInfo object therein may be found.
In an optional embodiment of the present invention, the ProcessName attribute of the target plug-in service includes an index value of the target process, and then the target process where the target plug-in service is located is obtained according to the ProcessName attribute of the target plug-in service, an optional scheme is provided in an embodiment of the present invention, in the scheme, a predefined process index may be obtained, where the process index includes an index value of the process and a corresponding process; and then searching the target process corresponding to the index value of the target process in the process index. For example, to facilitate judgment, a process index may be defined with numbers such as 1, 2, 3, such as 1 for a UI process, 2 for a resident process, and so on.
After the target process where the target plug-in service is located is obtained, the embodiment of the present invention may obtain, by the first specified class member, an interface of the manager of the target plug-in service based on the target process where the target plug-in service is located. That is, in the exemplary PluginServiceClient class of the client class, the first specified class member is PluginServiceServerFetcher, and the PluginServiceServerFetcher is used to obtain the interface of the manager of the target plug-in service, i.e. the IPluginServiceServer interface. This may be done in a number of ways, such as fetching from a cache, creating or fetching an IPluginServiceServer object and caching, etc., as described in more detail below.
In the first mode, the data is acquired from the cache.
First, after a target process where a target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed and cached to a specified object, such as an mservicemanagebyprocessmap object. Therefore, the embodiment of the present invention attempts to acquire the IPluginServiceServer object from the cache, and as described above, each service Process has a corresponding PluginServiceServer object, and naturally, to acquire the object through IPC (Inter-Process Communication), it is necessary to acquire the interface of its AIDL, that is, the ipluginServiceServer interface object. Specifically, the first specified class member calls the cached specified object to obtain the target process of the target plug-in service, and further obtains the interface of the manager of the target plug-in service from the target process of the target plug-in service.
And secondly, creating or acquiring the IPluginServiceServer object and caching the IPluginServiceServer object.
If there is no object in the cache, it means that it needs to be created or fetched. The creation means that when the target process does not exist, the target process needs to be started, and the target process is required to construct an implementation object of the IPluginServiceServer. And the acquisition means that if the target process exists, the object can be directly acquired from the target process and cached in the mServiceManageByProcessMap object for future use. Specifically, whether a target process of the target plug-in service exists is judged, and if yes, an interface of a manager of the target plug-in service is directly obtained from the target process of the target plug-in service; if the target process does not exist, starting the target process of the target plug-in service, constructing an interface of a manager of the target plug-in service, and further acquiring the constructed interface of the manager of the target plug-in service.
In an optional embodiment of the present invention, if the target process where the target plug-in service is located is a resident process, the IPluginHost object (which is the most core interface object in communication between the resident process and other processes) can be obtained by calling the plug process main. And then the interface of the manager of the target plug-in service is obtained by calling the IPluginHost.
In the embodiment of the invention, no matter which way is adopted for obtaining, the target process is required to be awakened first, and then the interface object is obtained through the ContentProvider and the matrix adapter.
Once the calling process is established, the client can transmit the required information to the server, and the server can perform various processing. That is, in step S106, the server class provides the target plug-in service to the user, and the client process of the client class and the target process of the server class can communicate with each other to provide the target plug-in service to the user.
The embodiment of the invention provides an optional scheme, wherein the client process of the client class communicates with the target process of the server class through a first specified class member, and the first specified class member communicates with the Binderstub of the target process of the server class; after receiving the message, the Binderstub forwards the message to the Stub of the server class, and then the Stub of the server class forwards the message to the server class; the server class thus provides the target plug-in service to the user based on the message.
In an optional embodiment of the present invention, if the process in which the plug-in service is located is accidentally killed, if the process is not removed from the cache in time, the IPluginServiceServer object obtained from the cache again is unusable, and a DeadObjectException occurs when any method in the IPluginServiceServer object is called. Thus, embodiments of the present invention provide for the processing of a "plug-in lifecycle". Specifically, whether a target process in which a target plug-in service is located is terminated is detected; if the target process of the target plug-in service is detected to be terminated, calling the cached specified object to clear the target process of the target plug-in service; and if the target process where the target plug-in service is located is not detected to be terminated, continuing to detect. For example, binderded may be defined as a core method of the lifecycle of a plug-in, and once the target process is terminated, the target process will be called back to the user immediately, which is simple and only needs to clear the cache.
In the above, various embodiments of various links of the embodiment shown in fig. 1 are described, and the implementation process of the method for using a service in a plug-in according to the present invention is described in detail by using a specific embodiment.
The embodiment of the invention designs a similar C/S architecture, a user of a plug-in service is a client, a provider of the plug-in service is a server, a manager for managing the plug-in service is arranged in a process of each server, and the plug-in service is managed by using a server class corresponding to the manager, so that the plug-in service can be effectively used without occupying pits and extra processing, and the operation is performed like the Android system service.
First, differences between the embodiment of the present invention and the Android service are introduced, and the method can be specifically divided into the following three aspects.
1) General leader and branch leader
The general leader of the Android service is implemented by a name of "activityManageService". All services, whether creating, managing, releasing, registering, de-registering, or delivering AIDL, etc., must be handled by this service.
In the embodiment of the invention, in consideration of performance and design, a general system similar to the 'ActivityManageService' of the Android service is not designed, but a structure similar to the 'C/S' is designed, a user (i.e. a caller) of the service is a client, and a provider (i.e. an implementer) of the service is a server. Each process of the server has a 'leader' service 'PluginServiceServer' for managing the service of the process.
2) Process and load opportunity differentiation
The "general leader" of the Android service exists in the unique process "system _ server" of the system, and is loaded when a terminal (such as a mobile phone and the like) where the system is located is started.
The loading opportunity of the branch management leaders in the embodiment of the invention is loaded when the process where the current service is located is loaded, and if the current service is not loaded, the branch management leaders of the process can not appear any more, so that certain performance and memory consumption can be saved.
3) Responsibility and scope of influence of ActivityManagerService and PluginServiceServer
Android ActivintManagerService is extremely complex in logic, because it needs to manage the information of Activity, Service, ContentProvider, BroadcastAcceiver, Application, Instrumentation, Process, etc. in the entire Android system. Once the service is out of order, the entire handset will be restarted (which is also one of the reasons many handsets are notoriously auto-restart).
The responsibility of the PluginServiceServer is relatively simple, only Service and Process information of 'current Service Process' is managed, and the logic is clear. If the service has problems, only the current service process and the process using the current service process are influenced, other services are not influenced, and loss is reduced to the maximum extent.
Next, for convenience of explanation, the following terms may be defined.
(1) Plug-in service
The Service representing a plug-in is used for representing a 'background Service' on the Android platform, and the corresponding Java class of the Service is the Service.
(2) Using plug-in services
Indicating that this Service is to be used. At present, common Android using methods include: a start Service (StartService), a Stop Service (Stop Service), a Bind Service (Bind Service), and a unbind Service (unbinded Service).
(3) Process of plug-in service
Indicating which process the plug-in service to use should exist in. Is typically represented in process in the < Service > tag in the Android system profile Android manifest.
(4) Process index (optional)
For ease of judgment, a "process index" may be defined, and may have numbers such as 1, 2, 3. For example, in the case of a cell phone guard, 1 represents a UI process, 2 represents a resident process, and so on. In practical applications, the embodiments of the present invention may also be implemented without "process indexing". Where "process index" is not required, it can be directly replaced with "process name" or "process PID (identifier)".
(5) Client of plug-in service
The party using the plug-in may be referred to as the "client" at the plug-in service. For example, if the clean-up plug-in calls the backup service in the backup plug-in to do the "backup before clean-up" function, the "clean-up plug-in" party is referred to herein as the "client".
(6) Server terminal of plug-in service
The party being scheduled may be referred to as the "server" at the plug-in service. For example, if the cleaning plug-in calls the backup service in the backup plug-in to perform the function of "backup before cleaning", one side of the "backup service" is called the "server side" here.
(7) Manager of plug-in service
In the embodiment of the present invention, the process of each scheduled party may have a "plug-in service manager", that is, the "management leader" described above, and may be customized as a "plug service" class, and further, the method in this class may be defined as startService (open plug service), stopService (stop plug service), bindService (bind plug service), unbind service (unbind plug service), and so on.
Next, a client class for a user of the plug-in service to operate on the plug-in service may be defined as a plugin serviceclient class. The class is a core class to be used by a client of the plug-in service, and is a class capable of starting, stopping, binding, unbinding and other functions of the service of the plug-in. All operations on plug-in commands begin from this class.
startService, which starts the service of the specified plug-in, and is similar to a context startService method in terms of usage;
stopService, stopping the service of a specified plug-in, which is similar to context in usage;
bind service, bind the plug-in service, obtain its AIDL, similar to context.
unbindedservice, unbinded to the plugin service, similar to context.
stopband, which stops service in the plugin service, is similar to service.stopband in usage, which should be called in the plugin service;
getProcessByComponentName, the internal method, obtains the plug-in information through ComponentName, and then finally obtains the process index of the service to be loaded.
In the PluginServiceClient class of the client class, a first specified class member is also defined as PluginServiceServerFetcher, and the first specified class member is a static variable in the client class and can be directly accessed by adding a ". multidot.. The static variables are declared in the client class, defined outside the client class, and memory is allocated.
The PluginServiceServer type is used for acquiring the corresponding realization PluginServiceServer type of the IPluginServiceServer interface. In this class, the fetchByProcess method obtains the specified IPluginServiceServer object by "process index" (which may be replaced by process PID, etc., see above).
The IPluginServiceServer is a core interface of a 'plug-in service manager'. The PluginServiceServer and the corresponding PluginServiceServer are jointly responsible for the work of service scheduling, service providing and the like of the Server end, and are service providers. Each process has a respective IPluginServiceServer object, and thus, these processes will have the ability to use plug-in services. The IPluginServiceServer is a standard AIDL interface, which means that the interface can be used across processes. The code defined by IPluginServiceServer is as follows:
the following describes classes and procedures to illustrate the relationship between IPluginServiceServer and PluginServiceClient. As shown in fig. 2, the PluginServiceClient runs on the Process1 Process, and the PluginServiceServer runs on the Process2 Process (allowing Process1 to be Process 2). The PluginServiceClient may then communicate with the BinderStub of the Process2 through the custom PluginServiceServerFetcher using the BinderProxy.
After receiving the message, the bididerstub forwards the message to the Stub of the PluginServiceServer (this step can be completed by the system), and the Stub forwards the message to the PluginServiceServer, thereby realizing the communication between the PluginServiceclient and the PluginServiceServer.
In addition, in fig. 2, the Android system is marked at the upper right corner, because the management process of the whole service is performed, the embodiment of the present invention does not contact activiymanagergservice, and does not make Hook for it, which is equal to a completely independent set of solution.
When the process of the service is searched, steps 301 and 302 can be included, and the specific code is as follows:
301: acquiring a ServiceInfo object of a plug-in service;
in this step, the ServiceInfo object is self-contained in the Android system, and is used to describe information of Service in the configuration file Android manifest. The ServiceInfo object may be obtained in a variety of manners, for example, if the ComponentList includes a list of all components of the plug-in, the list of all components of the plug-in may be obtained by calling a factory. For another example, the PackageInfo in the plug-in may be parsed by itself, and the ServiceInfo object therein may be found.
302: get to ProcessName and finally decide the "process index" to use.
After getting the information of the plugin service, the ProcessName attribute needs to be acquired, and the process name to which the plugin service should be executed is taken. In the mobile phone guard, a mode of 'process index' is adopted, so that judgment is made here, if the name conforms to 'guardervice', the service is executed in a 'resident process', otherwise, the service is executed in a UI process.
When acquiring the interface IPluginServiceServer of the manager of the plug-in service, steps 401, 402, and 403 may be included, and the specific code is as follows:
401: obtaining from a cache;
in this step, it will try to acquire the IPluginServiceServer object from the cache first, as mentioned above, each service process has a corresponding PluginServiceServer object, and naturally, to acquire this object by IPC, it is necessary to acquire its AIDL interface, that is, the IPluginServiceServer interface object.
402: creating or acquiring an IPluginServiceServer object and caching;
if there is no object in the cache, it means that it needs to be created or fetched. The creation means that when the target process does not exist, the target process needs to be started, and the target process is required to construct an implementation object of the IPluginServiceServer. And the acquisition means that if the target process exists, the object can be directly acquired from the target process and cached in the mServiceManageByProcessMap object for future use. In the above code, firstly, a judgment is made, if the target process is a resident process, the IPluginHost object (which is the most core interface object in the communication between the resident process and other processes) can be obtained by calling the Plugin ProcessMain.getPluginHost () method; and then the interface of the manager of the target plug-in service is obtained by calling the IPluginHost.
Of course, this is the practice of the cell phone guard, and other applications may also directly acquire the IPluginServiceServer object of the target process if the patent is implemented. However, it is necessary to note that no matter what method is used for obtaining the interface object, the target process must be waken up first, and then the interface object is obtained through ContentProvider and matrix adapter.
403: hang "plug-in lifecycle detection".
This step is also critical. If the process in which the plug-in service is located is accidentally killed, if the process is not removed from the cache in time, the IPluginServiceServer object obtained from the cache in the next time cannot be used, and any method called by the IPluginServiceServer object cannot be used, so that the DeadobjectException exception occurs. Thus, embodiments of the present invention provide for the processing of a "plug-in lifecycle". Information about the lifecycle of the plug-in, here mainly the following are shown:
the binderDied is a core method of the lifecycle of the plug-in, and once the target process is terminated, the binderDied can be immediately called back to a user.
Based on the method for using the service in the plug-in based on the above embodiments, based on the same inventive concept, the embodiment of the present invention further provides a device for using the service in the plug-in.
Fig. 3 shows a schematic configuration diagram of an apparatus for using a service in a plug-in according to an embodiment of the present invention. As shown in fig. 3, the apparatus may include at least a defining module 310, an obtaining module 320, and a providing module 330.
The functions of the components or devices of the apparatus using services in a plug-in and the connection relationship between the components of the apparatus using services in the plug-in according to the embodiment of the present invention will now be described:
the definition module 310 is suitable for defining a client class used for a user of the plug-in service to operate the plug-in service and defining a server class corresponding to a manager for managing the plug-in service;
an obtaining module 320, coupled to the defining module 310, and adapted to, when a user needs to use a target plug-in service, invoke a first specified class member in the client class, and obtain, by the first specified class member, an interface of a manager of the target plug-in service;
the providing module 330, coupled to the obtaining module 320, is adapted to implement the server class by using an interface of the manager of the target plug-in service, so that the server class provides the target plug-in service to a user.
In an embodiment of the invention, the operation performed on the plug-in service includes at least one of:
starting the plug-in service, stopping the plug-in service, binding the plug-in service and unbinding the plug-in service.
In an embodiment of the present invention, the obtaining module 320 is further adapted to:
and before the first appointed class member acquires the interface of the manager of the target plug-in service, calling a second appointed class member in the client class, and acquiring the target process of the target plug-in service by the second appointed class member.
In an embodiment of the present invention, the obtaining module 320 is further adapted to:
acquiring a ServiceInfo object of the target plug-in service by the second specified class member;
acquiring a ProcessName attribute of the target plug-in service by utilizing the ServiceInfo object of the target plug-in service;
and acquiring a target process of the target plug-in service according to the ProcessName attribute of the target plug-in service.
In an embodiment of the present invention, the ProcessName attribute of the target plug-in service includes an index value of the target process, and the obtaining module 320 is further adapted to:
acquiring a predefined process index, wherein the process index comprises an index value of a process and a corresponding process;
and searching the target process corresponding to the index value of the target process in the process index.
In an embodiment of the present invention, the obtaining module 320 is further adapted to:
and acquiring an interface of a manager of the target plug-in service by the first appointed class member based on the target process of the target plug-in service.
In an embodiment of the present invention, after a target process where the target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed and cached to a specified object;
the obtaining module 320 is further adapted to:
calling the cached specified object by the first specified class member to acquire a target process of the target plug-in service;
and acquiring an interface of a manager of the target plug-in service from a target process where the target plug-in service is located.
In an embodiment of the present invention, the obtaining module 320 is further adapted to:
judging whether a target process where the target plug-in service is located exists or not;
if so, directly acquiring an interface of a manager of the target plug-in service from a target process where the target plug-in service is located;
if not, starting a target process of the target plug-in service, constructing an interface of a manager of the target plug-in service, and further acquiring the constructed interface of the manager of the target plug-in service.
In an embodiment of the present invention, if the target process in which the target plug-in service is located is a resident process, the obtaining module 320 is further adapted to:
calling a PluginProcessMain.getPluginHost () method to obtain an IPluginHost object;
invoking IPluginHost. fetchServiceServer () method to obtain the interface of the manager of the target plug-in service.
In an embodiment of the present invention, the providing module 330 is further adapted to:
and the client process of the client class is communicated with the target process of the server class, and the target plug-in service is provided for a user.
In an embodiment of the present invention, the providing module 330 is further adapted to:
the client process of the client class uses a BindProxy object to communicate with the BinderStub of the target process of the server class through the first appointed class member;
after receiving the message, the Binder Stub forwards the message to the Stub of the server class, and the Stub of the server class forwards the message to the server class;
the server class provides the target plug-in service to a user based on the message.
In an embodiment of the present invention, the client class is a plugin service client class, the server class is a plugin service server class, and an interface of a manager of the target plug-in service is an IPluginServiceServer interface.
In an embodiment of the present invention, the IPluginServiceServer interface is an android interface definition language aid l interface.
In an embodiment of the present invention, as shown in fig. 4, after a target process where the target plug-in service is located is started, an interface of a manager of the target plug-in service is constructed, and is cached to a specified object, where the apparatus may further include:
a detecting module 340, coupled to the providing module 330, adapted to detect whether a target process in which the target plug-in service is located is terminated;
a clearing module 350, coupled to the detecting module 340, adapted to call the cached specified object to clear the target process of the target plug-in service if the detecting module 340 detects that the target process of the target plug-in service is terminated.
According to any one or a combination of the above preferred embodiments, the following advantages can be achieved by the embodiments of the present invention:
the embodiment of the invention designs a similar C/S architecture, wherein a user of the plug-in service is a client, a provider of the plug-in service is a server, each server is provided with a manager for managing the plug-in service in a process, and the plug-in service is managed by using a server class corresponding to the manager. When the user needs to use the target plug-in service, a first specified class member in the client class is called, the first specified class member acquires an interface of the manager of the target plug-in service, the server class is realized by using the interface of the manager of the target plug-in service, and the server class provides the target plug-in service for the user.
The technical scheme of the invention solves the problems of the prior art I and the prior art II, and the scheme of the prior art I is adopted on the mobile phone guard, although the implementation is quick, the biggest defect is that the host (namely the mobile phone guard) needs to be upgraded before the Service is increased. For example, if backup service2 is to be added in the future, then similarly, backup service2 needs to be written in android manifest. The scheme of the second prior art is adopted on the mobile phone guard, and the method is realized by pre-burying some Service pit positions in a host (namely the mobile phone guard), however, the pit positions are limited, and the starting speed is influenced due to too many pit positions. According to the technical scheme provided by the embodiment of the invention, the processing logic of the manager for managing the plug-in service is arranged in the process of each server, so that the management of the plug-in service can be effectively realized without upgrading a host program and increasing a pit position of the service in the configuration file android manifest.
Further, the method of onCreate, onStartCommand, onBind, etc. in the plugin Service, which needs to be implemented in the embodiment of the present invention, is completely consistent with the system Service, and no special modification is required. Furthermore, the embodiment of the invention can directly use the plug-in Service through the plug-in Service client.xxxservice (xxx can be four basic operations of Service: start/stop/bind/unbound). In addition, in the embodiment of the present invention, the server side determines which process the plug-in service should execute on, and the client cannot determine the execution process, and the process can be specified when defining the < service > tag in android manifest.
In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.
Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the claims, any of the claimed embodiments may be used in any combination.
The various component embodiments of the invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that a microprocessor or Digital Signal Processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components of an apparatus for using services in a plug-in according to embodiments of the present invention. The present invention may also be embodied as apparatus or device programs (e.g., computer programs and computer program products) for performing a portion or all of the methods described herein. Such programs implementing the present invention may be stored on computer-readable media or may be in the form of one or more signals. Such a signal may be downloaded from an internet website or provided on a carrier signal or in any other form.
It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.
Thus, it should be appreciated by those skilled in the art that while a number of exemplary embodiments of the invention have been illustrated and described in detail herein, many other variations or modifications consistent with the principles of the invention may be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Accordingly, the scope of the invention should be understood and interpreted to cover all such other variations or modifications.