CN107515780B - Method for determining call relation between applications, method and device for generating call rule - Google Patents

Method for determining call relation between applications, method and device for generating call rule Download PDF

Info

Publication number
CN107515780B
CN107515780B CN201610438790.0A CN201610438790A CN107515780B CN 107515780 B CN107515780 B CN 107515780B CN 201610438790 A CN201610438790 A CN 201610438790A CN 107515780 B CN107515780 B CN 107515780B
Authority
CN
China
Prior art keywords
application
calling
call
message
determining
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
Application number
CN201610438790.0A
Other languages
Chinese (zh)
Other versions
CN107515780A (en
Inventor
陈超
赵子鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banma Zhixing Network Hongkong Co Ltd
Original Assignee
Banma Zhixing Network Hongkong Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Banma Zhixing Network Hongkong Co Ltd filed Critical Banma Zhixing Network Hongkong Co Ltd
Priority to CN201610438790.0A priority Critical patent/CN107515780B/en
Publication of CN107515780A publication Critical patent/CN107515780A/en
Application granted granted Critical
Publication of CN107515780B publication Critical patent/CN107515780B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues

Abstract

The application discloses a method and a device for determining a call relation between applications, which are 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 method comprises the following steps: determining a first characteristic of a call message which can be responded by a first application in an installation package of the first application; determining a second characteristic of a call message sent by a second application for calling other applications; and determining the calling relationship between the second application and the first application according to the first characteristic and the second characteristic. The application also discloses a call rule generation method and a call rule generation device.

Description

Method for determining call relation between applications, method and device for generating call rule
Technical Field
The application relates to the technical field of computers, in particular to a method and a device for determining a call relation between applications and a method and a device for generating a call rule.
Background
With the increasing functions of smart phones, Applications (APPs) installed on the phones for implementing different functions are also increasing. During the usage of these APPs by the user, other APPs (called APPs) may be called by the APP (calling APP), for example, some functions of the APP may need to be assisted by calling other APPs.
The call between the applications may generally refer to that a certain application sends a specific message to the operating system, so that the operating system starts or wakes up other applications according to the received message. For example, a user clicks an icon of the application a to trigger the operating system to start the application a, when the application a is started, the application a sends a message for starting the application B to the operating system, so that the operating system starts the application B according to the message, and in this case, it indicates that a call relationship exists between the application a and the application B.
For example, when a user desires to take a picture through a "microblog APP" and send out the taken picture in the form of a microblog, the picture cannot be taken only through the microblog APP, so that the microblog APP is required to call the camera APP to take the picture at this time, which indicates that a call relationship exists between the microblog APP and the camera APP at this time. For example, the user searches for a video on the browser, the user desires to watch the video, at this time, the browser calls the video playing APP installed on the mobile phone to play the video through the video playing APP, and at this time, it is described that there is a call relationship between the browser and the video playing APP.
In the prior art, determining which applications on an intelligent terminal have a call relationship often requires monitoring events of applications installed on the intelligent terminal, and determining that a call relationship exists between two applications that have been called between the applications when monitoring the call between the applications.
Therefore, by adopting the prior art, only when the calling really occurs between the two applications installed on the intelligent terminal, whether the calling relation exists between the two applications can be determined. Due to the fact that real calling among applications is relied on, various applications of calling rules to be determined need to be installed on the intelligent terminal, the process is complex, and efficiency is low.
Disclosure of Invention
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 embodiment of the application further provides a device for determining the call relation between the applications, so as to solve the problem that whether the call relation between the applications is low in efficiency by adopting the prior art.
The embodiment of the application also provides a method and a device for generating the calling rule.
The embodiment of the application adopts the following technical scheme:
a method for determining call relations between applications comprises the following steps:
determining a first characteristic of a call message which can be responded by a first application in an installation package of the first application;
determining a second characteristic of a call message sent by a second application for calling other applications;
and determining the calling relationship between the second application and the first application according to the first characteristic and the second characteristic.
A call rule generation method based on the determination method of the call relation among the applications comprises the following steps:
and when the second application is determined to be capable of calling the first application, generating a calling rule containing the process name according to the process name corresponding to a calling message sent by the second application and used for calling the first application.
An apparatus for determining call relations between applications, comprising:
the first characteristic determining unit is used for determining first characteristics of calling messages which can be responded by the first application in the installation package of the first application;
a second feature determination unit, configured to determine a second feature of a call message sent by a second application and used for calling another application;
and the call relation determining unit is used for determining the call relation between the second application and the first application according to the first characteristic and the second characteristic.
A call rule generating device based on the determination device of call relation between the applications comprises:
and the rule generating unit is used for generating a calling rule containing the process name according to the process name of the operating system process corresponding to the calling message sent by the second application and used for calling the first application when the calling relation determining unit determines that the second application can call the first application.
The embodiment of the application adopts at least one technical scheme which can achieve the following beneficial effects:
in this case, the first application does not need to be installed on the intelligent terminal, and whether a calling relationship exists between the first application and the second application can be determined, so that the efficiency of determining the calling relationship between the applications is improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic specific flowchart of a method for determining a call relationship between applications according to an embodiment of the present application;
fig. 2 is a schematic specific flowchart illustrating a first feature of obtaining, from an installation package of an application, a call message to which the application can respond according to an embodiment of the present application;
fig. 3 is a specific flowchart illustrating a second feature of obtaining a call message sent by an application for calling another application according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of a device for determining a call relationship between applications according to an embodiment of the present application.
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.

Claims (16)

1. A method for determining a call relation between applications is characterized by comprising the following steps:
determining a first characteristic of a call message which can be responded by a first application in an installation package of the first application;
determining a second characteristic of a call message sent by a second application for calling other applications;
determining a calling relationship between the second application and the first application according to the first feature and the second feature, wherein,
when receiving a call message which is sent by the second application and used for calling the first application, determining a process name of an operating system process corresponding to the call message, comparing the determined process name with a process name in a saved unnecessary call rule, and determining that the second application is forbidden to call the first application when the determined process name is the same as the process name in the unnecessary call rule.
2. The method of claim 1, wherein determining a first characteristic of an invocation message in an installation package of a first application to which the first application is able to respond comprises:
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.
3. The method of claim 1 or 2, wherein determining a first characteristic of an invocation message in an installation package of the first application to which the first application is able to respond comprises:
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.
4. The method of claim 3, wherein determining the first characteristic of the invocation message to which the first application is able to respond based on the registration initiation condition set in the installation package of the first application comprises:
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.
5. The method of claim 1, wherein the call message issued by the second application to call the other application comprises at least one of:
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.
6. The method of claim 1, wherein determining a calling relationship between the second application and the first application based on the first feature and the second feature comprises:
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.
7. A call rule generation method based on the method of any claim 1 or 2 or 4 to 6, comprising:
and when the second application is determined to be capable of calling the first application, generating a calling rule containing the process name according to the process name corresponding to a calling message sent by the second application and used for calling the first application.
8. The method of claim 7, wherein generating the calling rule including the process name according to the process name corresponding to a calling message issued by a second application for calling the first application comprises:
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.
9. An apparatus for determining call relation between applications, comprising:
the first characteristic determining unit is used for determining first characteristics of calling messages which can be responded by the first application in the installation package of the first application;
a second feature determination unit, configured to determine a second feature of a call message sent by a second application and used for calling another application;
a call relation determining unit, configured to determine a call relation between the second application and the first application according to the first feature and the second feature, wherein,
when receiving a call message which is sent by the second application and used for calling the first application, determining a process name of an operating system process corresponding to the call message, comparing the determined process name with a process name in a saved unnecessary call rule, and determining that the second application is forbidden to call the first application when the determined process name is the same as the process name in the unnecessary call rule.
10. The apparatus of claim 9, wherein the first feature determination unit is 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.
11. The apparatus of claim 9 or 10, wherein the first feature determination unit 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.
12. The apparatus of claim 11, wherein the first feature determination unit is 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.
13. The apparatus of claim 9, wherein the call message issued by the second application to call the other application comprises at least one of:
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.
14. The apparatus of claim 9, wherein the call relation determination unit is 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.
15. An apparatus for generating call rules based on the apparatus of any claim 9, 10, 12-14, comprising:
and the rule generating unit is used for generating a calling rule containing the process name according to the process name corresponding to a calling message which is sent by the second application and used for calling the first application when the calling relation determining unit determines that the second application can call the first application.
16. The apparatus of claim 15, wherein the rule generation unit is to:
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.
CN201610438790.0A 2016-06-17 2016-06-17 Method for determining call relation between applications, method and device for generating call rule Active CN107515780B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610438790.0A CN107515780B (en) 2016-06-17 2016-06-17 Method for determining call relation between applications, method and device for generating call rule

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610438790.0A CN107515780B (en) 2016-06-17 2016-06-17 Method for determining call relation between applications, method and device for generating call rule

Publications (2)

Publication Number Publication Date
CN107515780A CN107515780A (en) 2017-12-26
CN107515780B true CN107515780B (en) 2021-03-16

Family

ID=60720143

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610438790.0A Active CN107515780B (en) 2016-06-17 2016-06-17 Method for determining call relation between applications, method and device for generating call rule

Country Status (1)

Country Link
CN (1) CN107515780B (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104267977A (en) * 2014-09-16 2015-01-07 小米科技有限责任公司 Application program running method and device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102945157B (en) * 2012-10-23 2016-01-06 北京奇虎科技有限公司 Software transfer method and apparatus
CN109063467A (en) * 2013-05-27 2018-12-21 华为终端(东莞)有限公司 The method, apparatus and terminal of system function call
CN104915224B (en) * 2015-04-24 2019-01-04 青岛海信电器股份有限公司 A kind of processing method and processing device of affiliate application

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104267977A (en) * 2014-09-16 2015-01-07 小米科技有限责任公司 Application program running method and device

Also Published As

Publication number Publication date
CN107515780A (en) 2017-12-26

Similar Documents

Publication Publication Date Title
TWI679573B (en) Method and device for operating background application
TWI622933B (en) Client update method and device
CN106227585B (en) Application program starting method, device and equipment
US20170124320A1 (en) Enabling resource access for secure application containers
CN110750315B (en) Class loading method, device, equipment and storage medium in Android system
CN110764894A (en) Timed task management method, device, equipment and storage medium
US20140181810A1 (en) Automatic discovery of externally added devices
CN106445514B (en) Method and device for managing Activity instance of Android platform
CN115374481B (en) Data desensitization processing method and device, storage medium and electronic equipment
WO2017096826A1 (en) Method and device for controlling mobile terminal
CN114547569A (en) Account login processing method and device
WO2019047677A1 (en) Application download source detection method and apparatus
CN111245814B (en) Data auditing method and device, electronic equipment and storage medium
CN110764930B (en) Request or response processing method and device based on message mode
CN107301097B (en) Method and device for storing calling java object and reference address information of java object
CN107515780B (en) Method for determining call relation between applications, method and device for generating call rule
CN111078435A (en) Service processing method and device and electronic equipment
CN110120963B (en) Data processing method, device, equipment and machine readable medium
CN105787359A (en) Course guarding method and device
CN111367577A (en) Method, device and terminal for loading plug-in of application
CN107608827B (en) Backup method and terminal for package configuration file and related medium product
CN106203087B (en) Injection protection method, system, terminal and storage medium
CN113448585A (en) Optimization method and device for thread pool, electronic equipment and storage medium
CN112416555B (en) Client restarting method, device and apparatus, and storage medium
CN111984341B (en) Project monitoring method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1248347

Country of ref document: HK

TA01 Transfer of patent application right

Effective date of registration: 20201217

Address after: Room 603, 6 / F, Roche Plaza, 788 Cheung Sha Wan Road, Kowloon, China

Applicant after: Zebra smart travel network (Hong Kong) Limited

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Applicant before: Alibaba Group Holding Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant