CN106598642B - Method and device for using service in plug-in - Google Patents
Method and device for using service in plug-in Download PDFInfo
- Publication number
- CN106598642B CN106598642B CN201610976361.9A CN201610976361A CN106598642B CN 106598642 B CN106598642 B CN 106598642B CN 201610976361 A CN201610976361 A CN 201610976361A CN 106598642 B CN106598642 B CN 106598642B
- Authority
- CN
- China
- Prior art keywords
- service
- plug
- target
- class
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
Abstract
The invention provides a method and a device for using services in a plug-in. The method comprises the following steps: 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. The technical scheme provided by the embodiment of the invention can effectively realize the management of the plug-in service without upgrading the host program and increasing the pit position of the service in the configuration file of the host.
Description
Technical Field
The present invention relates to the field of plug-in technologies, and in particular, to a method and an apparatus for using a service in a plug-in.
Background
In software development, in order to facilitate the function extension of software, a plug-in mode can be adopted for development, one function to be realized by the software is packaged in the plug-in, and finally, all the plug-ins are integrated in a software main program package and are issued together. In actual development, a situation of using a plug-in service is often encountered, for example, a Backup service using a Backup plug-in is needed on a mobile phone guard.
In the prior art, the first method is implemented by writing a "Service broker" in the main program (host). This Service intermediary can do this directly by calling the plug-in through reflection. The specific method comprises the following steps: firstly, pre-burying the Service in android manifest.xml of a host (for example, writing < Service android: name: "Backup Service"), and secondly, writing Backup Service in the host, but all methods such as onCreate and onstartCommand call the implementation inside the plug-in through Java reflection (for example, there are a Backup Service ImPLE class and an onCreate method in the Backup plug-in, and at this time, a Backup Service ImPLE. onCreate is called in the Backup Service. However, although the prior art is fast to implement, the biggest disadvantage is that the host must be upgraded before Service can be added. For example, if backup service2 is to be added in the future, then similarly, backup service2 needs to be written in android manifest.
In the second prior art, the second method is implemented by pre-burying some Service pit bits in the host. The second prior art effectively solves the problem of the first prior art, so that the plug-in service can be deleted and modified at will under the condition of not upgrading the host. However, the second prior art also has a relatively obvious defect that the pit is limited. Activity's lifecycle is much shorter than Service, in other words, even if only 3 pit bits are left for Activity of each different schema, the pages can be fully used as long as they are properly arranged. However, Service is to reside in the background, the life cycle is very long, if only a small number of pit bits are left, the pit bits will be full quickly, but the start speed is affected due to too many (for example, 20 reserved) pit bits, and when a third party or himself acquires information of a host application through a Binder, the abnormality of transactionTooLarge may occur due to too many information, and therefore, the scheme is not perfect.
In view of the foregoing, the inventors have found that it is desirable to provide a scheme for efficiently using services in a plug-in.
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.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 shows a flow diagram of a method of using services in a plug-in according to an embodiment of the invention;
FIG. 2 illustrates a relationship diagram of classes and processes according to an embodiment of the invention;
FIG. 3 shows a schematic block diagram of an apparatus for using services in a plug-in according to an embodiment of the present invention; and
fig. 4 is a schematic structural diagram illustrating an apparatus for using a service in a plug-in according to another embodiment of the present invention.
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.
Claims (28)
1. A method of using services in a plug-in, comprising:
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;
the server class is realized by utilizing an interface of a manager of the target plug-in service, and the target plug-in service is further provided to a user by the server class;
wherein the first designated class member is a static variable in the client class.
2. The method of claim 1, wherein the operation 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.
3. The method of claim 1 or 2, wherein prior to obtaining, by the first specified class member, the interface of the manager of the target plug-in service, the method further comprises:
calling a second appointed class member in the client class, and acquiring a target process of the target plug-in service by the second appointed class member
Wherein the second specified class member is a getProcessByComponentName method.
4. The method of claim 3, wherein obtaining, by the second specified class member, the target process in which the target plug-in service is located comprises:
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.
5. The method of claim 4, wherein the ProcessName attribute of the target plug-in service includes an index value of a target process, and obtaining 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.
6. The method of claim 4 or 5, wherein obtaining, by the first specified class member, an interface of a manager of the target plug-in service comprises:
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.
7. The method according to claim 6, wherein 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;
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.
8. The method of claim 6, wherein obtaining, by the first specified class member, an interface of a manager of the target plug-in service based on a target process in which the target plug-in service is located comprises:
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.
9. The method of claim 8, wherein if the target process of the target plug-in service is a resident process, acquiring the interface of the manager of the target plug-in service from the target process of the target plug-in service comprises:
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.
10. The method of claim 1 or 2, wherein providing, by the server class, the target plug-in service to a user comprises:
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.
11. The method of claim 10, wherein the client process of the client class communicates with the target process of the server class to provide the target plug-in service to the user, and the method comprises:
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.
12. The method according to claim 1 or 2, wherein the client class is a PluginServiceClient class, the server class is a PluginServiceServer class, and the interface of the manager of the target plug-in service is an IPluginServiceServer interface.
13. The method according to claim 12, wherein the IPluginServiceServer interface is an android interface definition language, AIDL, interface.
14. The method according to any one of claims 7-9, wherein the target process where the target plug-in service is located builds an interface of a manager of the target plug-in service after being started, and caches to a specified object, the method further comprising:
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.
15. An apparatus for using a service in a plug-in, comprising:
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;
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;
wherein the first designated class member is a static variable in the client class.
16. The apparatus of claim 15, wherein the operation 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.
17. The apparatus of claim 15 or 16, wherein the acquisition module is further adapted to:
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 a target process of the target plug-in service by the second appointed class member;
wherein the second specified class member is a getProcessByComponentName method.
18. The apparatus of claim 17, wherein the acquisition 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.
19. The apparatus of claim 18, wherein the ProcessName attribute of the target plug-in service comprises an index value of the target process, the obtaining module 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.
20. The apparatus of claim 18 or 19, wherein the acquisition 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.
21. The device of claim 20, wherein 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;
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.
22. The apparatus of claim 20, wherein the acquisition 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.
23. The apparatus of claim 22, wherein 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.
24. The apparatus of claim 15 or 16, wherein the providing means 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.
25. The apparatus of claim 24, wherein the providing means 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.
26. The apparatus according to claim 15 or 16, wherein the client class is a PluginServiceClient class, the server class is a PluginServiceServer class, and the interface of the manager of the target plug-in service is an IPluginServiceServer interface.
27. The apparatus according to claim 26, wherein the IPluginServiceServer interface is an android interface definition language, AIDL, interface.
28. The apparatus according to any one of claims 21-23, wherein a target process in which the target plug-in service is located constructs an interface of a manager of the target plug-in service after being started, and caches to a specified object, the apparatus further comprising:
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.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610976361.9A CN106598642B (en) | 2016-11-07 | 2016-11-07 | Method and device for using service in plug-in |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610976361.9A CN106598642B (en) | 2016-11-07 | 2016-11-07 | Method and device for using service in plug-in |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106598642A CN106598642A (en) | 2017-04-26 |
| CN106598642B true CN106598642B (en) | 2020-05-15 |
Family
ID=58590674
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610976361.9A Active CN106598642B (en) | 2016-11-07 | 2016-11-07 | Method and device for using service in plug-in |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106598642B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110413259B (en) * | 2018-04-28 | 2022-07-29 | 中兴通讯股份有限公司 | Android service framework, method and device for realizing extended service |
| CN109213582A (en) * | 2018-07-16 | 2019-01-15 | 北京奇虎科技有限公司 | A kind of method, apparatus and terminal of operation service component |
| CN111766992B (en) * | 2020-05-29 | 2022-04-22 | 维沃移动通信有限公司 | Information display method and device, electronic equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103618699A (en) * | 2013-11-12 | 2014-03-05 | 吴晓军 | Method and device for calling component |
| CN104717301A (en) * | 2015-03-27 | 2015-06-17 | 北京奇虎科技有限公司 | Plug-in download method and device |
| CN104731625A (en) * | 2015-03-27 | 2015-06-24 | 北京奇虎科技有限公司 | Method, device and mobile terminal for loading plugin |
| CN105959302A (en) * | 2016-06-28 | 2016-09-21 | 中科创达软件股份有限公司 | Terminal management framework and method |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101378400B (en) * | 2007-08-30 | 2013-01-30 | 国际商业机器公司 | Method, server and system for polymerizing desktop application and Web application |
-
2016
- 2016-11-07 CN CN201610976361.9A patent/CN106598642B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103618699A (en) * | 2013-11-12 | 2014-03-05 | 吴晓军 | Method and device for calling component |
| CN104717301A (en) * | 2015-03-27 | 2015-06-17 | 北京奇虎科技有限公司 | Plug-in download method and device |
| CN104731625A (en) * | 2015-03-27 | 2015-06-24 | 北京奇虎科技有限公司 | Method, device and mobile terminal for loading plugin |
| CN105959302A (en) * | 2016-06-28 | 2016-09-21 | 中科创达软件股份有限公司 | Terminal management framework and method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106598642A (en) | 2017-04-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103942225A (en) | Method and system for invoking resources of Hybrid App client and client | |
| CN104750487B (en) | A kind of development approach and starting method of mobile terminal APP | |
| CN106598642B (en) | Method and device for using service in plug-in | |
| CN102087615A (en) | Automated merger of logically associated messages in a message queue | |
| WO2016000544A1 (en) | Method of processing application cpu usage rate anomaly, and device and mobile terminal | |
| CN106874089B (en) | A kind of processing method, device and the mobile terminal of application program self-starting | |
| WO2016033966A1 (en) | Protection method and device for application data | |
| US9628939B2 (en) | Data calling method and device | |
| CN103400268A (en) | Device and method for realizing safety payment of browser | |
| CN109086065A (en) | A kind of method for upgrading software, system and terminal device | |
| CN108563472B (en) | Service plug-in loading method and device based on multi-open application | |
| CN104461663A (en) | Method and device for loading other mobile terminal applications and mobile terminal | |
| CN106934272B (en) | Application information verification method and device | |
| CN106598662B (en) | Android-based application loading method and device | |
| CN107977243A (en) | A kind of third party's interface call method and device | |
| CN105354081B (en) | The method and device of synchronous binding service | |
| CN109388770B (en) | Web page generation method and device | |
| CN107861807B (en) | Optimization method and device for program call | |
| CN106874088B (en) | A kind of processing method, device and the mobile terminal of application program self-starting | |
| CN106951236B (en) | Plug-in development method and device | |
| CN116009984A (en) | Security arrangement and automatic response processing method and device and electronic equipment | |
| CN106445595B (en) | Method and device for constructing Application object of plug-in | |
| CN105630889B (en) | Universal caching method and device | |
| CN111427603B (en) | Application program upgrading method and device | |
| CN103176915B (en) | A kind of method of managing internal memory and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20211202 Address after: 300450 No. 9-3-401, No. 39, Gaoxin 6th Road, Binhai Science Park, high tech Zone, Binhai New Area, Tianjin Patentee after: 3600 Technology Group Co.,Ltd. Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park) Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd. Patentee before: Qizhi software (Beijing) Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230714 Address after: 1765, floor 17, floor 15, building 3, No. 10 Jiuxianqiao Road, Chaoyang District, Beijing 100015 Patentee after: Beijing Hongxiang Technical Service Co.,Ltd. Address before: 300450 No. 9-3-401, No. 39, Gaoxin 6th Road, Binhai Science Park, high tech Zone, Binhai New Area, Tianjin Patentee before: 3600 Technology Group Co.,Ltd. |
|
| TR01 | Transfer of patent right |