Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.
Example 1
The embodiment of the application provides a method for determining a call relation between applications, which is used for solving the problem that the efficiency of determining whether the call relation exists between the applications is low by adopting the prior art.
The execution main body of the method for determining the call relationship between the applications provided by the embodiment of the present application may be, but is not limited to, at least one of a mobile phone, a tablet Computer, a Personal Computer (PC), a smart television, and any smart terminal capable of installing and running an application.
For convenience of description, the following description will be made of an embodiment of the method, taking the implementation subject of the method as a mobile phone as an example. It is understood that the implementation of the method in the form of a mobile phone is merely an exemplary illustration and should not be construed as a limitation of the method.
The specific implementation flow diagram of the method is shown in fig. 1, and mainly comprises the following steps:
step 11, determining a first characteristic of a call message which can be responded by the first application in an installation package of the first application;
the installation Package (Install Package) of the first application comprises all installation files of the application, and all the installation files of the application can be released to a hard disk by running the installation Package. Even if the installation package of a certain application is not installed on the mobile phone, the installation file in the installation package of the application can be scanned, and the information contained in the installation file can be determined.
With the method provided in step 11, since the first feature of the call message that can be responded by the first application is obtained from the installation package of the first application, the mobile phone only needs to store the installation package of the first application, and does not need to install the first application on the mobile phone, so that processing resources and storage space consumed by installing the application can be reduced.
The response mode of the first application to the call message may generally include starting the first application or waking up the first application, and certainly, the first application may also respond to the call message in other modes. Since the first application generally responds to the call message for the first application in a manner of starting or waking up, in an embodiment, a specific implementation manner of step 11 may include: a first characteristic of a call message in an installation package of a first application to which the first application can respond in a startup or wake-up manner is determined.
The call message that the first application can respond in a starting or waking mode means that the first application can respond, and the specific response mode includes a message that the first application is started or the first application is wakened. For example, the mobile phone operating system sends a call message to the application 2 according to a broadcast message sent by the application 1 for starting other applications, so that the application 2 is started in response to the call message sent by the mobile phone operating system, and then the call message is a call message to which the application 2 can respond in a starting manner.
The first feature of the call message generally refers to a feature indicating that "the call message can implement a function of" calling the first application ". For example, the first feature may be a specified character string included in the call message, and the first application may be started or awakened if receiving the specified character string, that is, the specified character string may implement a function of calling the first application, so that the specified character string may serve as the first feature of the call message to which the first application may respond.
The first feature may be a unique identifier, and the presence of the unique identifier enables the feature having the unique identifier to be determined from the installation package of the first application as the first feature, based on the unique identifier (the unique identifier may be stored in advance by the mobile phone). Alternatively, the first feature may be stored in a designated location in the installation package of the first application, and the feature stored in the designated location may be determined as the first feature by scanning the designated location.
In one embodiment, the specific implementation manner of step 11 may include: and determining a first characteristic of a call message which can be responded by the first application according to the registration starting condition of the installation package set in the first application.
The registration starting condition is a starting condition of a first application registered to an operating system when the installation package is installed; the starting condition comprises a first characteristic of a calling message which can be responded by the first application.
The registration start condition is often stored in an application-specific installation file, which may be a manifest. The file is an information description file of the whole application program, and the file describes some components of the application program, such as Activity (Activity), Service (Service), broadcast receiver (broadcastdetect) and Content provider (Content provider). In actual use, the starting or waking of an application by an operating system may refer to the starting or waking of at least one component included in the application by the operating system by sending a call message to the application. Since the registration start conditions of different components of the application are saved in the manifest.xml file of the application, the registration start conditions of the application can be obtained from the manifest.xml file in the installation package of the application.
For example, if it is assumed that a register start condition of a component B of an application a is defined in a manifest.xml file of the application a, and the register start condition includes a character string for defining a name of the component B (assuming that the character string is "< receiver android: name" < B > "), and a character string included in a call message for defining that the component B can respond in a start or wake manner (assuming that the character string is" < action android: name "< start. bootcomplete"/>), when the application a receives the call message sent by the operating system in a broadcast manner and carries the character string "start. And further awakening or starting the component B of the application A. For this example, the character string "startup. bootcomplete" included in the registration start condition of the definition component B in the manifest file of the application a is the first feature of the call message that the application a can respond in a start or wake-up manner.
For example, assume that a process name "abc" corresponding to a component D of an application C is defined in a manifest file of the application C, and a registration start condition of the component D is defined in a subclass of the process name "abc", and, for example, assume that a character string for defining the component D name is included in the registration start condition (assume that the character string is "< service identity: name:" com.a. Then, when the application C receives a call message sent by the operating system and carrying "com.a.applications" and the character string "abc" as the process name, according to the character string "abc" carried in the call message, the registration start condition of the component D may be searched in the subclass of the process name "abc", and since it can be determined according to the search result that the call message and the registration start condition of the component D of the application C both contain the same character string "com.a.applications", it can be determined that the component D of the application C can respond to the call message in a start or wake-up manner, and further wake up or start up the component D of the application C. For this example, the character string "com.a.applications" included in the registration start condition of the definition component D in the manifest.xml file of the application C is a first feature of a call message to which the application C can respond in a start or wake-up manner.
It should be noted that, for the same component of an application, a plurality of different registration start conditions may be defined in a manifest. Xml file of an application E, for example, defines a registration start condition for a component F of the application E to wake up or start up by an intent message issued by an operating system. The registration start condition includes a character string for defining the component name, and is assumed to be "< activity android: name ═ F >", in addition, the registration start condition may further include two character strings for defining that the component C can respond in a starting or waking manner, and it is assumed that the first character string includes: "< action android: name"/> and < category android: name "/>; the second string includes "< action android: name ═ com.x.x.x.mainactivity"/> and "< category android: name ═ android.
Then, when the application E receives the event message sent by the operating system and carries the character strings "android. When the call message carries the character strings "com.x.x.mainactivity" and "android.internal.category.default", since the call message and the registration start condition of the application E both contain the same character strings "com.x.mainactivity" and "android.internal.category.default", it can be determined that the component F of the application E can respond to the call message in a start or wake-up manner, and further wake up or start the component F of the application E. For this example, the character strings "address.action.main" and "address.identity.category.token" (or "com.x.x.main activity" and "address.identity.default") included in the registration start condition of the definition component F described in the manifest.xml file of the application E are the first features of the call message to which the application E can respond in a start or wake-up manner.
In order to determine the first feature of the call message to which the first application can respond according to the registration starting condition set in the installation package of the first application, in the embodiment of the application, the first feature of the call message may be determined from the registration starting condition of the first application in a static source code scanning manner. In one embodiment, the first feature of the invocation message to which the first application is able to respond may be determined by performing a static source code scan of the registration start condition in the installation package of the first application.
The static source code scanning may generally refer to that in software engineering, after a programmer writes a source code, the programmer directly scans the source code by using some scanning tools without compiling by a compiler, so as to find solutions of some semantic defects and security vulnerabilities existing in the source code. In the embodiment of the application, the purpose of determining the first characteristic of the call message which can be responded by the first application from the source code of the application can be achieved by performing static source code scanning on the source code of the application. Since static source code scanning is already a mature related technology, detailed description of specific implementation of static source code scanning is omitted.
In addition, the embodiment of the present application may also adopt other manners to obtain the first feature. For example, a first characteristic of a call message to which the first application can respond in a start-up or wake-up manner is determined by decompiling the first application. The embodiment of the present application does not limit the manner of obtaining the first feature of the call message to which the first application can respond.
It should be noted that, at present, the number of applications that can be installed on a mobile phone is very large, and in order to generate call rules between different applications as comprehensively as possible, it is often necessary to scan installation packages of all applications on the mobile phone to respectively obtain features of call messages that can be respectively responded by the applications. In this case, in order to subsequently distinguish from which application installation package the features of the call message to which the applications can respectively respond are respectively obtained, in one embodiment, the features of the call message to which the applications can respond and the unique identifier of the application (for example, the name of the application) may be stored in the form of "application unique identifier — features of the call message" -that is, in the form of key value pairs, the unique identifier of the application is used as a key, and the features of the call message to which the application can respond are stored in the form of values of the key.
In an embodiment, the step 11 may be implemented according to a flow shown in fig. 2, where the flow specifically includes: determining a first characteristic of a call message which can be responded by a first application in a mode of static source code scanning of Service and broadcasterever in a manifest file of the application, and saving the characteristic of the call message which can be responded by the first application in a key-value pair mode (taking a unique identifier of the first application as a key and the characteristic of the call message which can be responded by the application as the value of the key).
It should be noted that, considering that the operating system may also directly issue the call message to the first application without receiving call messages of other applications for calling the first application, the embodiment of the present application determines the first characteristic of the call message to which the first application can respond, mainly for subsequently determining which other application the first application can be called. Therefore, optionally, the call message to which the first application can respond may include a call message to which the first application can respond and which is issued by another application, and does not include the above-mentioned call message issued directly to the first application by the operating system.
Step 12, determining a second characteristic of a call message sent by a second application and used for calling other applications;
the second feature of the call message issued by the second application for calling the other application generally refers to a feature indicating that "the call message can implement a function of 'calling the other application'. For example, the second feature may be a specified character string included in the call message, and if at least one application other than the second application receives the specified character string, the specified character string may be started or awakened, that is, the specified character string may implement a function of calling another application, so that the specified character string may serve as the second feature of the call message sent by the second application and used for calling another application.
The second feature may have a unique identifier, and the presence of the unique identifier enables the feature having the unique identifier to be determined as the second feature from a call message sent by the second application and used for calling another application, according to the unique identifier (the unique identifier may be stored in advance by the mobile phone). Alternatively, the second feature may exist at a specified position in a call message issued by the second application for calling another application, and thus the feature existing at the specified position may be regarded as the second feature.
During the running of the second application, the second application may need to invoke other applications. The second application may send a message to the operating system to invoke the other application in order to invoke the other application.
The sending, by the second application, to the operating system, the call message for calling the other application may specifically include: the information of the called application, the information of the specified operation expected to be executed by the called application and the data required by the called application when the specified operation is completed, so that the operating system executes: and determining the called application according to the information of the called application contained in the received calling message, and sending the calling message to the called application to fulfill the aim of calling the called application to finish the specified operation.
The calling message sent by the second application for calling the other application may specifically include, but is not limited to, at least one of the following messages:
message 1, a broadcast message sent by the second application to the operating system for calling other applications;
message 2, an intention Intent message sent by the second application to the operating system for invoking other applications;
message 3, a deferred intent pending intent message issued by the second application to the operating system for invoking other applications.
It should be noted that, since the above-mentioned message sent by the application to the operating system each time is recorded and stored in the system log by the operating system, the second feature of the call message sent by the second application for calling the other application can be obtained by querying the system log.
In an embodiment, the step 12 may be implemented according to a flow shown in fig. 3, where the flow specifically includes: and acquiring a second characteristic of the call message sent by the second application for calling other applications through querying the system log, taking the unique identifier of the second application as a key, taking the second characteristic of the call message sent by the second application for calling other applications as the value of the key, and saving the second characteristic of the call message sent by the second application for calling other applications.
And step 13, determining the calling relationship between the second application and the first application according to the first characteristic and the second characteristic.
In one embodiment, the specific implementation manner of step 13 may include: judging whether the first feature is matched with the second feature; and when the judgment result is that the first characteristic is matched with the second characteristic, determining that the second application can call the first application.
As mentioned above, the first feature and the second feature may be stored in the form of a key-value pair such as "application unique identifier — feature of call message", so that the application corresponding to the feature may be determined according to the stored feature. And when the judgment result is that the first characteristic is matched with the second characteristic, determining that the second application corresponding to the second characteristic can call the first application corresponding to the first characteristic.
It should be noted that, when the first feature is the same as the second feature, it may generally be stated that a call message issued by the second application for calling another application is the same as a call message that the first application can respond to, thereby indicating that the second application may call the first application. Thus, when the first feature is the same as the second feature, the first feature may be considered to match the second feature.
In addition, the first feature is matched with the second feature, specifically, a relationship between the first feature and the second feature may conform to a stored preset mapping relationship, and the like. For the stored preset mapping relationship, two parties with the preset mapping relationship are provided, one party is: the calling message sent by the calling application contains a characteristic which indicates that the calling message can realize the function of calling some application, and the other side is as follows: the calling message to which the callee application can respond includes a feature indicating that "the calling message can realize the function of' calling the callee application".
It should be noted that, on one hand, it is considered that calls between applications often consume a large amount of processing resources of the intelligent terminal, and on the other hand, it is considered that calls occurring between some applications may be unnecessary, and therefore unnecessary calls may be prohibited to avoid wasting processing resources. For example, when a user desires to launch a game application to play a game, the game application may automatically invoke a game promotion application, and the user need not launch the game promotion application in the current scenario-in which case the call that occurs between the game application and the game promotion application may not be necessary. To reduce the cost of the terminal processing resources for the call, the call may be prohibited.
In order to disable unnecessary calls, in an embodiment, when it is determined that a call relationship exists between the application a and the application B according to the method, a call rule between the application a and the application B may be generated, and the generated inter-application call rule may be screened according to a feedback of a user to screen out a call rule corresponding to an unnecessary call between applications (hereinafter, referred to as an unnecessary call rule), and the unnecessary call rule may be stored in the intelligent terminal.
The generated inter-application invocation rule generally includes: and the process name of the operating system process corresponding to the calling message which is sent by the calling application and used for calling the called application. And the operating system process corresponding to the calling message is a process created by the operating system in response to the calling message sent to the operating system by the calling application. The operating system can send the calling message to the called application by creating the process, so that the purpose of calling the called application is achieved. The name of the process can be determined from the process names of various processes of the operating system stored in advance according to the mapping relation between the specified message content in different calling messages and the process name of the operating system process and the specified message content in the calling messages.
Subsequently, when the application A sends a call message for calling the application B to the operating system, the operating system determines a process name of an operating system process corresponding to the call message, compares the determined process name with a process name in a saved unnecessary call rule, and when the determined process name is the same as the process name in the unnecessary call rule, the operating system can determine that the call of the application A to the application B is unnecessary, and at the moment, the operating system cannot create the process of the process name, so that the call message cannot be sent to the application B, and the purpose of forbidding the application A to call the application B is achieved.
In an embodiment, when it is determined that the second application can invoke the first application, generating, according to a process name corresponding to a call message sent by the second application and used for invoking the first application, a call rule including the process name may specifically include: determining the process name of the operating system process corresponding to the calling message for calling the first application sent by the second application according to the mapping relation between the designated message content of the calling message for calling other applications sent by the second application and the process name of the operating system process and the designated message content of the calling message for calling the first application sent by the second application; and generating a calling rule containing the process name according to the determined process name.
It should be noted that, when it is determined that the first feature matches the second feature, the operating system may respectively determine, according to the features in the stored key-value pair form, the second application corresponding to the second feature and the first application corresponding to the first feature, and further may determine, from a call message sent by the second application and used for calling another application, a call message sent by the second application and used for calling the first application, and generate an inter-application call rule including the process name according to the process name of the operating system process corresponding to the call message sent by the second application and used for calling the first application.
After the application is installed on the terminal device, all installation files in the application installation package are stored on the terminal device, and the application installation file often stores a mapping relationship between specified message content of a message which can be sent to an operating system by the application and a process name of an operating system process which can be triggered and created by the message. When the message sent to the operating system is a call message for calling another application, the specified message content of the call message generally refers to the identifier of the calling application and the identifier of the called application.
When the operating system receives a call message sent by an application and used for calling other applications, the operating system may determine, according to the mapping relationship stored in the installation file of the application and the content of the specified message in the received call message, a process name of an operating system process corresponding to the content of the specified message in the call message, that is, a process name of an operating system process corresponding to the call message, and create a process having the same process name as the determined process name.
Based on the above, no matter whether the operating system creates the operating system process in response to the call message sent by the second application for calling other applications, the process name of the operating system process can be determined according to the mapping relationship and the specified message content in the call message. Therefore, in the embodiment of the present application, according to the process name of the operating system process corresponding to the call message sent by the second application for calling the other application, the generated inter-application call rule including the process name is the same as the inter-application call rule generated by using the inter-application call rule generation method in the prior art, and both the generated inter-application call rule and the generated inter-application call rule include the same process name of the operating system process.
In one embodiment, the generated inter-application call rules may be filtered in a computer manner or a manual manner according to the inter-application unnecessary calls fed back by the user, so as to filter out the inter-application call rules corresponding to the inter-application unnecessary calls.
When the inter-application call rule only includes the process name of the operating system process, it may not be possible to distinguish between which two applications the call rule belongs to by using a manual method, and further, the generated inter-application call rule cannot be screened.
To avoid the foregoing problem, in an embodiment, when it is determined that the first feature matches the second feature, the operating system may determine, according to the features in the form of the stored key value pairs, a unique identifier of the second application corresponding to the second feature and a unique identifier of the first application corresponding to the first feature, respectively, and generate an inter-application call rule between the second application and the first application, where the inter-application call rule includes a process name of an operating system process corresponding to a call message issued by the second application for calling the first application, the unique identifier of the first application, and the unique identifier of the second application. Therefore, the calling rule can be determined to be the inter-application calling rule between the first application and the second application according to the unique identifier of the first application and the unique identifier of the second application which are included in the inter-application calling rule, and the generated inter-application calling rule can be screened in a manual mode.
By adopting the method for determining the call relationship between the applications provided in embodiment 1 of the present application, because the first feature of the call message that can be responded by the first application is determined from the installation package of the first application, the second feature of the call message that can be sent by the second application and is used for calling other applications is determined, and the call relationship between the second application and the first application is determined according to the first feature and the second feature, in this case, the first application does not need to be installed on the smart terminal, and whether the call relationship exists between the first application and the second application can be determined, thereby improving the efficiency of determining the call relationship between the applications.
It should be noted that the execution subjects of the steps of the method provided in embodiment 1 may be the same device, or different devices may be used as the execution subjects of the method. For example, the execution subject of steps 11 and 12 may be device 1, and the execution subject of step 13 may be device 2; for another example, the execution subject of step 11 may be device 1, the execution subject of step 12 may be device 2, and the execution subject of step 13 may be device 3; for example, the execution subject of step 11 may be device 1, and the execution subjects of step 12 and step 13 may be device 2; and so on.
It should be noted that, the embodiment of the present application does not limit the execution order of the steps of the foregoing method. For example, step 11 may be performed synchronously with step 12, or step 11 may be performed after step 12. The number is set for each step in the embodiment of the present application to describe each step orderly, and the execution order of the steps is not limited, that is, the number set for each step in the embodiment of the present application is not to be considered as a feature that limits the execution order of the steps.
Example 2
The embodiment of the application provides a device for determining a call relation between applications, which is used for solving the problem that the efficiency of determining whether the call relation exists between the applications is low by adopting the prior art. The specific structural diagram of the device is shown in fig. 4, and the device comprises: a first feature determining unit 21, a second feature determining unit 22, and a call relation determining unit 23.
The first feature determining unit 21 is configured to determine a first feature of a call message that can be responded by a first application in an installation package of the first application;
a second feature determination unit 22, configured to determine a second feature of a call message issued by a second application and used for calling another application;
a call relation determining unit 23, configured to determine, according to the first feature and the second feature, a call relation between the second application and the first application.
In one embodiment, the first feature determination unit 21 is configured to: a first characteristic of a call message in an installation package of a first application to which the first application can respond in a startup or wake-up manner is determined.
In one embodiment, the first feature determination unit 21 is configured to: determining a first characteristic of a calling message which can be responded by a first application according to a registration starting condition of an installation package set in the first application; the registration starting condition is a starting condition of a first application which is registered to an operating system when the installation package is installed; the starting condition comprises a first characteristic of a calling message which can be responded by the first application.
In one embodiment, the first feature determination unit 21 is configured to: determining the registration starting condition by scanning a static source code of the installation file of the first application; and determining a first characteristic of a call message which can be responded by the first application according to the registration starting condition.
In one embodiment, the call message sent by the second application for calling the other application includes at least one of the following: the second application sends a broadcast message to the operating system for calling other applications; an intention Intent message sent by the second application to the operating system for invoking the other application; a deferred intent pending intent message issued by the second application to the operating system for invoking the other application.
In one embodiment, the call relation determining unit 23 is configured to: judging whether the first feature is matched with the second feature; when the judgment result is matching, determining that the second application can call the first application; and when the judgment result is not matched, determining that the second application cannot call the first application.
By using the apparatus for determining a call relationship between applications provided in embodiment 2 of the present application, because a first feature of a call message that can be responded by a first application is determined from an installation package of the first application, a second feature of a call message that can be sent by a second application and is used for calling another application is determined, and a call relationship between the second application and the first application is determined according to the first feature and the second feature, in this case, the first application does not need to be installed on an intelligent terminal, and it can be determined whether a call relationship exists between the first application and the second application, so that efficiency of determining a call relationship between applications is improved.
In an embodiment, an embodiment of the present application further provides an invoking rule generating device based on the foregoing determining device for determining an invoking relationship between applications, including: a rule generating unit, configured to generate, when the call relation determining unit 23 determines that the second application can call the first application, a call rule including a process name according to the process name corresponding to a call message sent by the second application and used for calling the first application.
In an embodiment, the rule generating unit is configured to determine, according to a mapping relationship between specified message content of a call message for calling another application and a process name of an operating system process, and specified message content of a call message for calling another application sent by the second application, a process name of an operating system process corresponding to the call message for calling another application sent by the second application; and generating an inter-application calling rule containing the process name according to the determined process name.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.