WO2020094027A1

WO2020094027A1 - Method and apparatus for processing invocation request for sensitive permission module in terminal

Info

Publication number: WO2020094027A1
Application number: PCT/CN2019/115828
Authority: WO
Inventors: 汪步庆
Original assignee: 中兴通讯股份有限公司
Priority date: 2018-11-05
Filing date: 2019-11-05
Publication date: 2020-05-14
Also published as: CN109711141A

Abstract

Provided are a method and apparatus for processing an invocation request for a sensitive permission module in a terminal. The method comprises: receiving an invocation request for invoking a sensitive permission module by an application in a terminal (S202); determining whether the invocation request meets pre-determined conditions, wherein the pre-determined conditions comprise at least one of the following: the application is in the background when initiating the invocation request, the screen of the terminal is in a turned-off state when the application initiates the invocation request, and the application is in the foreground when initiating the invocation request, but a touch operation is not received on an interface of the application within a pre-determined duration before the application initiates the invocation request (S204); and where the invocation request meets the pre-determined conditions, performing pre-determined processing on the invocation request, wherein the pre-determined processing comprises at least one of the following: rejecting the invocation request, issuing a reminder for the invocation request, and inquiring about whether the invocation request is allowed (S206).

Description

Method and device for processing call request of sensitive authority module in terminal

cross reference

This application refers to the Chinese patent application No. 201811307589.4 filed on November 05, 2018, entitled "Processing Method and Apparatus for Calling Requests of Sensitive Rights Modules in Terminals", which is fully incorporated by reference into this application.

Technical field

The present application relates to, but is not limited to, the communication field, and in particular, to a method and device for processing a call request of a sensitive authority module in a terminal.

Background technique

Data privacy has always been the focus of users' attention, but privacy breaches still occur from time to time. The terminal can collect a large amount of user privacy data through microphones, cameras, Global Positioning System (GPS) and other sensors, and can also read user privacy data through internal interfaces, such as contacts, SMS, call records, etc. Wait.

In order to protect user privacy data, the current system architecture of the terminal provides a mechanism for applications (APPs, including third-party APPs, system APPs, etc.) to call a microphone, camera, GPS, and other sensors or applications to perform permission checks when reading user privacy data. However, some software may use the permission to call the sensor to obtain outside information or read the user's private data at will without the user's knowledge after obtaining the user's relevant permission, resulting in the leakage of user privacy.

Summary of the invention

The embodiment of the present application provides a method and device for processing a call request of a sensitive authority module in a terminal, so as to at least solve the problem in the related art that the software arbitrarily calls the sensor to obtain outside information or reads the user's private data without the user's knowledge. The issue of leakage of user privacy.

According to an embodiment of the present application, a method for processing a call request of a sensitive permission module in a terminal is provided, including: receiving a call request of an application in a terminal to call a sensitive permission module; determining whether the call request meets a predetermined condition , Wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, the screen of the terminal is off when the application initiates the call request, and the application initiates the call When the request is in the foreground but the application does not receive a touch operation on the interface of the application within a predetermined period before the call request is initiated; if the call request meets the predetermined condition, the call request A predetermined process is performed, wherein the predetermined process includes at least one of the following: rejecting the call request, issuing a reminder for the call request, and asking whether to allow the call request.

According to another embodiment of the present application, there is provided an apparatus for processing a call request of a sensitive authority module in a terminal, including: a call request receiving module, configured to receive a call request of an application in the terminal to call a sensitive authority module; A module for determining whether the call request meets a predetermined condition, wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, and the terminal is when the application initiates the call request Of the screen is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request; the processing module is used to When the call request meets the predetermined condition, perform a predetermined process on the call request, wherein the predetermined process includes at least one of the following: reject the call request, issue a reminder for the call request, and ask whether The call request is allowed.

According to yet another embodiment of the present application, there is also provided a storage medium in which a computer program is stored, wherein the computer program is set to execute the steps in any one of the above method embodiments during runtime.

According to yet another embodiment of the present application, there is also provided an electronic device including a memory and a processor, the memory stores a computer program, the processor is configured to run the computer program to perform any of the above The steps in the method embodiment.

Through this application, after receiving the call request of the application in the terminal to call the sensitive permission module, an abnormal call judgment is made for the call request, and it can be monitored that the application is in the background, the screen is turned off, or the user's touch is not received in the foreground The call request initiated in the case of operation, and correspondingly perform one or more of rejection, reminder, query and other operations. Through this solution, it can solve the problem of software arbitrarily calling sensors to obtain external information or reading user privacy data without the user's knowledge, resulting in the leakage of user privacy, and an effective monitoring application for sensitive permission modules (for example, can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.

BRIEF DESCRIPTION

The drawings described herein are used to provide a further understanding of the present application and form a part of the present application. The schematic embodiments and descriptions of the present application are used to explain the present application and do not constitute an undue limitation on the present application. In the drawings:

1 is a block diagram of a hardware structure of a mobile terminal of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

2 is a flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

3 is a specific flowchart of step S204 in a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

4 is another specific flowchart of step S204 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

5 is a specific flowchart of step S206 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

6 is a specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

7 is another specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

8 is a structural block diagram of a device for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

9 is a detailed structural block diagram of a device for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;

10 is a schematic diagram of a system architecture according to an exemplary embodiment of the present application;

11 is an overall flowchart according to an exemplary embodiment of the present application;

12 is a flowchart of permission inspection, application, and abnormality judgment according to an exemplary embodiment of the present application;

13 is a statistical diagram of the use period of microphones and short messages according to an exemplary embodiment of the present application;

FIG. 14 is a schematic diagram of an interface for reminding a user after using a microphone in the background of an application according to an exemplary embodiment of the present application.

Specific examples

In the terminal system (for example, Android system, iOS system, etc.), when a third-party application needs to access sensitive information such as contacts, SMS, or call GPS, Camera, microphone, etc., the system's approach is to pop up a permission application dialog box. The user can choose to allow or deny. Some normal request users will choose to allow (for example, when users use WeChat to send pictures, WeChat requests permission to read photos). However, this may also cause privacy leakage, because the application for obtaining permissions can have permanent permissions after being authorized by the user (unless the user enters the settings to manually close its permissions). These applications may silently collect user's private data in the background without the user's knowledge.

In view of the above problems, the embodiments of the present application provide a processing solution for the call request of the sensitive authority module in the terminal. Hereinafter, the present application will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other if there is no conflict.

It should be noted that the terms “first” and “second” in the description and claims of the present application and the above drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence.

The method embodiments provided in this application may be executed in a terminal (including a mobile terminal, a computer terminal, or a similar computing device). Taking an example running on a mobile terminal, FIG. 1 is a block diagram of a hardware structure of a mobile terminal of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 1, the mobile terminal 10 may include one or more (only one is shown in FIG. 1) processor 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc. ) And a memory 104 for storing data. Optionally, the above mobile terminal may further include a transmission device 106 for communication functions and an input and output device 108. A person of ordinary skill in the art may understand that the structure shown in FIG. 1 is merely an illustration, which does not limit the structure of the mobile terminal described above. For example, the mobile terminal 10 may also include more or fewer components than those shown in FIG. 1, or have a different configuration from that shown in FIG.

The memory 104 may be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the processing method of the call request of the sensitive authority module in the terminal in the embodiment of the present application, and the processor 102 is stored in the memory 104 by running Within the computer program, to perform various functional applications and data processing, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may include memories remotely provided with respect to the processor 102, and these remote memories may be connected to the mobile terminal 10 through a network. Examples of the above network include but are not limited to the Internet, intranet, local area network, mobile communication network, and combinations thereof.

The transmission device 106 is used to receive or send data via a network. The specific example of the network described above may include a wireless network provided by a communication provider of the mobile terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC for short), which can be connected to other network devices through the base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is used to communicate with the Internet in a wireless manner.

In this embodiment, a method for processing a call request of a sensitive permission module running on a terminal is provided. FIG. 2 is a flowchart of a method for processing a call request of a sensitive permission module in a terminal according to an embodiment of the present application, as shown in FIG. 2 As shown, the process includes the following steps.

Step S202: Receive a call request for the application in the terminal to call the sensitive authority module.

The concept of the sensitive authority module is well known in the art, and it is a series of modules related to user privacy, which can directly or indirectly control the operation of the sensor of the terminal, or read the user data in the terminal, and call these modules Need to perform permission check or permission application. Such sensitive permission modules include but are not limited to: contact module, short message module, call record module, GPS module, Camera module, microphone module, etc.

Step S204, judging whether the call request meets a predetermined condition, wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, and the terminal ’s The screen is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request.

Step S206, when the call request meets the predetermined condition, perform a predetermined process on the call request, wherein the predetermined process includes at least one of the following: reject the call request, issue the call request Remind and ask if the call request is allowed.

In this step, the predetermined processing involved is intended to prevent abnormal calls, thereby preventing leakage of user privacy. Among them, by refusing the call request, you can directly block the application of the requested privacy permission module; by issuing a reminder for the call request, for example, if the screen is in the bright state, you can display reminder information on the screen, It can also be supplemented by sound, indicator light, vibration and other reminder methods. If the screen is off, you can use sound, indicator light or vibration to remind you, and various forms of notification will prompt the user to have an application with abnormal calling behavior. To alert the user; by asking whether to allow the call request, you can use the Dialog to let the user decide whether to approve the call and give control to the user. When the user agrees, the call request is allowed. The behavior of allowing the call request can be It is allowed for a long time. For security reasons, it may be allowed within a predetermined period of time, for example, to allow the application to call the sensitive permission module within 10 minutes, or only to authorize its use for more than 24 hours to re-authorize.

Optionally, the execution body of the above steps may be a terminal.

Through the above steps, after receiving the call request of the application in the terminal to call the sensitive permission module, an abnormal call judgment is made for the call request, and it can be monitored that the application is in the background, the screen is turned off, or the user's touch is not received in the foreground The call request initiated in the case of operation, and correspondingly perform one or more of rejection, reminder, query and other operations. Through this solution, it can solve the problem of software arbitrarily calling sensors to obtain external information or reading user privacy data without the user's knowledge, resulting in the leakage of user privacy, and an effective monitoring application for sensitive permission modules (for example, can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.

Applications in the terminal (including third-party applications and system applications) need to call sensors in the terminal (for example, GPS, microphone, camera, etc.) or read sensitive user information in the terminal (for example, read SMS, contact information, and call When recording, etc.), you can check or apply sensitive permissions to the framework layer in the terminal, which can generally be completed through two requests. Accordingly, in step S202, the framework layer in the terminal receives the call request initiated by the application to call the sensitive permission module, wherein the call request includes one of the following: a call permission check request checkSelfPermission, call permission request requestPermission.

As the basic framework at the system level, the frame layer in the terminal is generally versatile. In order to implement the method described in this application without changing the basic framework, a simple and convenient method is to add a middleware layer, the middleware layer is a piece of processing code, and the normal processing code of the framework layer can be called by the middle The middleware layer is called in the form of the interface corresponding to the middleware layer. The middleware layer can be used to implement customized processing functions based on the general processing of the framework layer. In at least one exemplary embodiment of the present application, the middleware layer may include an abnormal call judgment component for performing abnormal call judgment, and may further include information reading for reading information required for abnormal judgment Components, the combination of the two can realize the judgment of abnormal calls, so that by calling the middleware layer on the basis of the framework layer, you can use a very convenient way to achieve abnormal calls without changing the original business logic of the framework. Judgment. The middleware can communicate with the contact module, short message module, GPS module, Camera module, microphone module and so on. For the APP that has been authorized to start calling the privacy module, the middleware layer first makes abnormal call judgment.

Therefore, as an optional exemplary embodiment, as shown in the specific flowchart of step S204 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application in FIG. 3, in step S204, the determination is made Whether the call request meets the predetermined condition may include the following steps.

Step S2042: The framework layer sends the call information corresponding to the call request to the middleware layer in the terminal, wherein the call information corresponding to the call request may include: the application that initiated the call request , And the judgment result of the framework layer judging whether to allow the call request.

In step S2044, the middleware layer determines whether the call request meets the predetermined condition according to the call information.

As an exemplary embodiment, when an application needs to call a sensitive permission module, it will initiate a checkSelfPermission or requestPermission to the framework layer. Therefore, the framework layer may change the interface calling behavior of checkSelfPermission or requestPermission to the middle of the terminal The software layer sends the calling information corresponding to the calling request. That is to say, the calling information corresponding to the calling request can be transferred to the middleware layer through the calling interface set in the checkSelfPermission or the requestPermission.

Those skilled in the art should understand that the implementation of step S204 exemplified above is only an example, and this solution can implement the method in this embodiment relatively easily without changing the frame layer. However, those skilled in the art should be able to think that there are many ways to implement step S204, for example, directly modify the authorization check and application-related processing flow in the framework layer to add abnormal call judgment, for example, directly include a The abnormal call judgment component for judging abnormal calls and the information reading component for reading information required for abnormal judgment can also realize the judgment of abnormal calls. In addition, those skilled in the art can also understand that, optionally, other modules can also be used to implement abnormal call judgment, etc. The specific implementation form of the abnormal call judgment is not limited in this application.

FIG. 4 is another specific flowchart of step S204 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 4, the frame layer is directed to the middleware layer in the terminal. Before step S2042 of sending the calling information corresponding to the calling request, it also includes one of the following.

2040-1, in the case where the call request includes the checkSelfPermission, the framework layer judges whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and the judgment result is If permitted, continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.

2040-2. In the case that the call request includes the checkSelfPermission, the framework layer determines whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and the judgment result is If it is not allowed, the framework layer initiates a requestPermission to the sensitive permission module requested by the checkSelfPermission, and determines whether to automatically authorize the requestPermission according to the type of the sensitive permission module. In the case of, continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.

2040-3. In the case where the call request includes the requestPermission, the framework layer determines whether to automatically authorize the requestPermission according to the type of the sensitive permission module called by the requestPermission, and if the judgment result is automatic In the case of authorization, continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.

As an exemplary embodiment, FIG. 5 is a specific flowchart of step S206 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 5, step S206 is performed when the call request meets In the case of the predetermined condition, performing the predetermined processing on the call request may include the following steps.

Step S2062, the middleware layer returns a judgment result of judging whether the calling request satisfies the predetermined condition to the framework layer.

In step S2064, the framework layer performs a predetermined process on the call request when the judgment result is that the call request meets the predetermined condition.

6 is a specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 6, after performing predetermined processing on the call request in step S206, the method further includes: step S602, Storing a call record generated by the call request to a database, wherein the call record includes at least one of the following: an identification of the application that initiated the call request, a type of the sensitive authority module called, and a call start Time, the time to end the call, and the duration of the call.

As an exemplary embodiment, the call record generated by the call request may be stored in a database by the middleware layer, and the data that the middleware layer may obtain includes the time when the third-party APP accesses the contact module, the short message module, and the GPS module. Use Camera, microphone call duration, etc.

7 is another specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 7, after storing the call record generated by the call request in the database in step S602 And also includes the following steps.

Step S702: Receive a call record viewing request.

Step S704: Read the call record corresponding to the call record view request from the database according to the call record view request, and analyze and / or display the read call record.

As an exemplary embodiment, the following processing can be performed on the collected information: visual analysis of the obtained information (display of histograms, etc.), statistics of the number of visits of contacts, SMS, and GPS; statistics of camera, microphone call duration, user You can view this information at any time. In this way, users can easily know the details of their private data being accessed.

For different types of exception calls, it may be considered to set different predetermined processing methods, so as to implement a more flexible and diverse method for processing exception calls and improve the user experience. Therefore, there may be a correspondence between the predetermined condition and the predetermined process. In step S206, when the call request meets the predetermined condition, the process of performing the predetermined process on the call request may include: The predetermined condition satisfied by the call request determines predetermined processing corresponding to the predetermined condition, and performs the determined predetermined processing on the call request.

This correspondence relationship can be set according to requirements, for example, it can be preset before leaving the factory, or can be set by the user. As an exemplary embodiment, the correspondence between the predetermined condition and the predetermined process may be as follows.

When the predetermined condition includes that the screen of the terminal is turned off when the application initiates the call request, the predetermined processing includes at least rejecting the call request.

When the predetermined condition includes that the application is in the background when the call request is initiated, the predetermined process includes at least issuing a reminder or asking whether the call request is allowed for the call request.

When the predetermined condition includes that the application is in the foreground when the call request is initiated, but the touch operation is not received on the interface of the application within a predetermined time period before the application initiates the call request, the predetermined The processing includes at least issuing a reminder or asking whether the calling request is allowed for the calling request.

Those skilled in the art should understand that the above correspondence is only an example, and the solution in this embodiment is not limited to this. The correspondence should be arbitrarily set according to actual application scenarios or user requirements.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware, but in many cases the former is A better embodiment. Based on this understanding, the technical solutions of the present application can be embodied in the form of software products in essence or part of contributions to the existing technology, and the computer software products are stored in a storage medium (such as ROM / RAM, magnetic disk, The CD-ROM includes several instructions to enable a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the embodiments of the present application.

In this embodiment, an apparatus for processing a call request of a sensitive authority module in a terminal is also provided. The apparatus is used to implement the foregoing embodiment and the preferred embodiments, and descriptions that have already been described will not be repeated. As used below, the term "module" may implement a combination of software and / or hardware that performs predetermined functions. Although the devices described in the following embodiments are implemented in software, implementation of hardware or a combination of software and hardware is also possible and conceived.

8 is a structural block diagram of an apparatus for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 8, the apparatus includes:

The call request receiving module 81 is configured to receive a call request for an application in a terminal to call a sensitive authority module.

The determining module 82 is configured to determine whether the calling request meets a predetermined condition, where the predetermined condition includes at least one of the following: the application is in the background when the calling request is initiated, and the application is in the background when the calling request is initiated The screen of the terminal is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request.

The processing module 83 is configured to perform predetermined processing on the calling request when the calling request meets the predetermined condition, wherein the predetermined processing includes at least one of the following: rejecting the calling request, targeting the The call request issues a reminder, asking if the call request is allowed.

Applications in the terminal (including third-party applications and system applications) need to call sensors in the terminal (for example, GPS, microphone, camera, etc.) or read sensitive user information in the terminal (for example, read SMS, contact information, and call When recording, etc.), you can check or apply sensitive permissions to the framework layer in the terminal, which can generally be completed through two requests. The following describes the layered processing method of the call request processing device of the sensitive authority module in the terminal in the terminal system in conjunction with FIG. 9. It should be noted that this solution is only an optional implementation method and should not be understood as It is to limit the scope of protection of this application.

FIG. 9 is a detailed structural block diagram of a device for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 9, the call request receiving module 81 is located at a frame layer in the terminal for receiving The call request initiated by the application to call the sensitive permission module, wherein the call request includes one of the following: a call permission check request checkSelfPermission, a call permission application request requestPermission.

As the basic framework at the system level, the frame layer in the terminal is generally versatile. In order to implement the method described in this application without changing the basic framework, a simple and convenient method is to add a middleware layer and call the middleware layer on the basis of the framework layer to realize the judgment of abnormal call. The middleware layer can communicate with the contact module, short message module, GPS module, Camera module, microphone module, etc. For the APP that has been authorized to start calling the privacy module, the middleware layer first makes abnormal call judgment.

Therefore, as an optional exemplary embodiment, as shown in FIG. 9, the device further includes: an information delivery module 91 located at the frame layer, and used to send the data to the middleware layer located at the terminal. The judging module 82 sends the calling information corresponding to the calling request, the calling information corresponding to the calling request includes: the identification of the application that initiated the calling request, and the framework layer judging whether to allow the calling request critical result.

The judgment module 82 is used to judge whether the calling request meets the predetermined condition according to the calling information.

As an exemplary embodiment, when an application needs to call a sensitive permission module, it will initiate a checkSelfPermission or requestPermission to the framework layer. Therefore, the framework layer may change the interface calling behavior of checkSelfPermission or requestPermission to the middle of the terminal The software layer sends the calling information corresponding to the calling request. In other words, the information transfer module 91 is used to transfer the call information corresponding to the call request to the judgment module located at the middleware layer through the call interface set in the checkSelfPermission or the requestPermission 82.

Those skilled in the art should understand that the above-mentioned implementation method for monitoring abnormal calls is only an example, and this solution can implement the method in this embodiment relatively easily without changing the framework layer. However, those skilled in the art should be able to think of many ways to monitor abnormal calls, for example, directly modify the permission check and application-related processing flow in the framework layer to add abnormal call judgment, or use other modules to achieve Abnormal call judgment, etc., this application does not limit.

As shown in FIG. 9, the system may further include a permission control module 92, which is located at the frame layer in the terminal and used to perform one of the following.

When the call request includes the checkSelfPermission, determine whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is allowed, call the The information transfer module 91 sends the call information corresponding to the call request to the judgment module 82 located in the middleware layer in the terminal.

When the call request includes the checkSelfPermission, determine whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is not allowed, check The sensitive permission module called by checkSelfPermission initiates requestPermission, and judges whether to automatically authorize the requestPermission according to the type of the sensitive permission module. When the judgment result is automatic authorization, the information transfer module 91 is called to The judgment module 82 located in the middleware layer in the terminal sends call information corresponding to the call request.

When the call request includes the requestPermission, determine whether to automatically authorize the requestPermission according to the type of the sensitive permission module requested by the requestPermission, and call the request if the judgment result is automatic authorization The information transfer module 91 sends the call information corresponding to the call request to the judgment module 72 located in the middleware layer in the terminal.

As an exemplary embodiment, as shown in FIG. 9, the processing module 83 may be located at the frame layer of the terminal, and the judgment module 82 is used to judge whether the call request meets the predetermined condition The result is returned to the processing module 83; the processing module 83 is used to perform predetermined processing on the call request if the judgment result is that the call request meets the predetermined condition.

As shown in FIG. 9, the system may further include: a storage module 93, configured to store a call record generated by the call request to a database, wherein the call record includes at least one of the following: the call request is initiated The identification of the application, the type of the sensitive permission module called, the time to start the call, the time to end the call, and the duration of the call.

As an exemplary embodiment, the call record generated by the call request may be stored in a database by the middleware layer, and the data that the middleware layer may obtain includes the time when the third-party APP accesses the contact module, the SMS module, and the GPS module Use Camera, microphone call duration, etc. Therefore, the storage module may be located at the middleware layer in the terminal. However, those skilled in the art should understand that it can also be implemented in other ways, for example, a storage module is directly provided in the framework layer, or the function of the storage module is implemented in other modules, which is not limited in this embodiment.

As shown in FIG. 9, the system may further include: a viewing request receiving module 94 for receiving a call record viewing request; an analysis display module 95 for reading the call record viewing request according to the calling record viewing request Call record View the call record corresponding to the request, and analyze and / or display the read call record.

For different types of exception calls, it may be considered to set different predetermined processing methods, so as to implement a more flexible and diverse method for processing exception calls and improve the user experience. Therefore, there may be a correspondence between the predetermined condition and the predetermined processing, and the processing module 83 is configured to: according to the predetermined condition that the call request satisfies when the call request meets the predetermined condition The condition determines a predetermined process corresponding to the predetermined condition, and performs the determined predetermined process on the call request.

This correspondence relationship can be set according to requirements, for example, it can be preset before leaving the factory, or can be set by the user. As an exemplary embodiment, the correspondence between the predetermined condition and the predetermined processing may be as follows: when the predetermined condition includes that the screen of the terminal is off when the application initiates the call request, the The predetermined processing includes at least rejecting the call request; when the predetermined condition includes that the application is in the background when the call request is initiated, the predetermined processing includes at least issuing a reminder or asking whether the call request is allowed for the call request The call request; when the predetermined condition includes that the application is in the foreground when the call request is initiated but the touch operation is not received on the interface of the application within a predetermined time period before the application initiates the call request , The predetermined processing includes at least issuing a reminder or asking whether the calling request is allowed for the calling request.

It should be noted that the above modules can be implemented by software or hardware, and the latter can be implemented by the following methods, but not limited to this: the above modules are all located in the same processor; or, the above modules can be combined in any combination The forms are located in different processors.

An embodiment of the present application further provides a storage medium in which a computer program is stored, wherein the computer program is configured to execute any of the steps in the above method embodiments during runtime.

Optionally, in this embodiment, the above storage medium may include, but is not limited to: a USB flash drive, a read-only memory (Read-Only Memory, ROM for short), a random access memory (Random Access Memory, RAM for short), Various media that can store computer programs, such as removable hard disks, magnetic disks, or optical disks.

An embodiment of the present application further provides an electronic device, including a memory and a processor, where the computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any one of the foregoing method embodiments.

Optionally, the electronic device may further include a transmission device and an input-output device, wherein the transmission device is connected to the processor, and the input-output device is connected to the processor.

Optionally, for specific examples in this embodiment, reference may be made to the examples described in the foregoing embodiments and optional embodiments, and details are not repeated herein in this embodiment.

In the following exemplary embodiments, combined with some specific application scenarios, a detailed description will be given to the processing scheme of the call request of the sensitive authority module in the terminal of the embodiment of the present application. It should be noted that the following exemplary description is only used to help understanding The embodiment scheme should not constitute an undue limitation on it.

First, the implementation architecture on which the exemplary embodiment is based will be described. FIG. 10 is a schematic diagram of a system architecture according to an exemplary embodiment of the present application. As shown in FIG. 10, the system in the terminal includes the following layers: a framework layer 1001, which When it detects that a third-party application checks or requests sensitive permissions (such as access to contacts, SMS, Camera, GPS, microphone, etc.), it communicates with the middleware layer 1002 and passes data to the middleware layer 1002 for judgment. The middleware layer 1002 receives the data from the frame layer 1001, performs abnormal call judgment, and returns the result to the frame layer 1001, and at the same time transfers the corresponding third-party call data to the database layer 1003 for storage. The database layer 1003 receives and processes incoming data from the middleware layer 1002, performs insertion, update, and the like.

The data display module 1004 analyzes the data in the database layer 1003 and displays it to the user, which can be displayed in various forms.

The overall flow of this exemplary embodiment is described in detail below. FIG. 11 is an overall flowchart according to an exemplary embodiment of the present application, and each part involved in FIG. 11 is briefly described below.

APP1APP2APP3 refers to third-party applications or independent applications of the system.

The contact module, short message module, Camera module, GPS module, and microphone module refer to some sensitive information modules in the mobile phone, including frame layer processing and sensor services, etc., which corresponds to the frame layer 1001 in FIG. 10.

The middleware layer corresponds to the middleware layer 1002 in FIG. 10.

The database corresponds to the database layer 1003 in FIG.

The data display module corresponds to the data display module 1004 of FIG.

The parameter assumptions of the system in this exemplary embodiment are explained below.

Middleware.class--Middleware layer service

publicenumEnumTYPE {

SMSTYPE = 1, // indicates the type of SMS data obtained

CONTACTTYPE, // means get contact data type

CAMERATYPE, // means calling Camera data type

GPSTYPE, // indicates calling GPS data type

MICROPHONETYPE; // Indicating the microphone data type

}

Boolean isUseStart = true; // true--start to use; false--end to use

The basic actions in the overall flowchart in FIG. 11 are described in detail below.

The mobile phone comes with apps or apps downloaded from the third-party market. When these apps read contacts, SMS data, or open / release Camera, GPS, microphone, and other services, the behavior of these apps will be detected at the frame layer 1001.

The processing of the framework layer 1001 is as follows: a request for invoking privacy permission by a third-party application will call the checkSelfPermission method or the requestPermissions method (regardless of whether the APP has obtained permission). The framework layer passes the call information to the middleware layer 1002. For the checkSelfPermission method, the framework layer returns True or False (True indicates that the APP has obtained permission, False indicates that the APP has not obtained permission). For the requestPermissions method, the framework layer determines whether the user actively authorizes or the system automatically authorizes, and then the framework layer passes the result to the middleware layer 1002. For the specific address, the return value of the third-party application uid and checkSelfPermission or requestPermissions can be passed into the middleware layer 1002 by modifying the Android SDK SDK checkSelfPermission and requestPermissions interfaces.

The processing flow of the middleware layer 1002 is as follows: the middleware layer 1002 judges whether it is an abnormal call, thereby rejecting or approving the request. Here are some technical details. It should be noted that the processing methods described below belong to one of many feasible processing methods. The list here is only for example and should not be understood as the only processing method. .

I) How to obtain which APP is called: The third-party application uid can be obtained through the Android standard SDK interface (such as Binder.getCallingUid ()), so as to obtain the specific application package name.

II) How to distinguish between the foreground and background APP: first query all processes running on the current mobile phone through the standard SDK interface, and then iterate through the uid value and the incoming uid value in all process attributes, if they are equal, read whether the process is in the foreground or The properties of the background, and then determine the return result.

FIG. 12 is a flowchart of permission inspection, application, and abnormality judgment according to an exemplary embodiment of the present application. The following provides a combination of the framework layer 1001 and the middleware layer 1002 in several scenarios in conjunction with FIG. Process of judgment.

1. For third-party applications to query SMS (GPS, contact process is similar) data will have the following four cases.

1.1) The return value of checkSelfPermission by the framework layer 1001 is True, then the middleware layer 1002 first determines whether the third-party application is in the foreground or background. If it is in the background, it obtains the application package name and sends a Notification to inform the user that the request has been rejected. In the notification, the user can click to enter the permission list interface of the three-party application; if it is the foreground, it will detect whether the user has a touch event within a few seconds before the request event time. If there is no touch screen event, a Dialog will pop up to prompt the user. Allow or deny buttons. For the foreground application, the package name of the application, the time of querying the data, and the data marked as fetching SMS type are transferred to the database. The detailed parameters are as follows: a) the package name of the third-party application; b) the data type of EnumTYPE.SMSTYPE GPS is GPSTYPE, and the contact is CONTACTTYPE; c) Whether the transfer is started is marked as true; d) The time when the transfer is started is transferred.

If the user allows the operation of the background application, the middleware layer 1002 also needs to store the usage data in the database.

1.2) The return value of checkSelfPermission by the framework layer 1001 is False, and then it is determined whether the result of requestPermissions is the user's active authorization or the system's automatic authorization, and then proceeds to step 1.3) or 1.4) according to the result.

1.3) The result returned by requestPermissions is the user's active authorization. At this time, the application is in the foreground and the user actively authorizes the SMS access permission. The application can access the SMS normally. Then the middleware layer 1002 writes the short message access time into the database.

1.4) The result returned by requestPermissions is automatic authorization by the system, and then step 1.1) is entered.

2. For third-party applications using microphone (Camera situation is similar) data will have the following four cases.

2.1) The return value of checkSelfPermission by the framework layer 1001 is True, then the middleware layer 1002 first determines whether the third-party application is in the foreground or background. If it is in the background, it obtains the application package name and sends a Notification to inform the user that the request has been rejected. In the notification, the user can click to enter the permission list interface of the three-party application; if it is the foreground, it will detect whether the user has a touch event within a few seconds before the request event time. If there is no touch screen event, a Dialog will pop up to remind the user that the user can click Allow or deny buttons. For the foreground application, the package name of the application and the time of querying the data and the data marked as fetching SMS type are transferred to the database. The detailed parameters are as follows: a) the package name of the third-party application; b) the data type is EnumTYPE.MICROPHONETYPE, Camera is of CAMERATYPE type; c) whether the transfer start flag is true; d) the transfer start time; e) the transfer end time.

2.2) The return value of checkSelfPermission by the framework layer 1001 is False, and then it is determined whether the result of requestPermissions is the user's active authorization or the system's automatic authorization, and then proceeds to step 2.3) or 2.4) according to the result.

2.3) The result returned by requestPermissions is the user's active authorization. At this time, the application is in the foreground and the user actively authorized the microphone access permission. The application can access the microphone normally. Then the middleware layer 1002 writes the microphone access time into the database.

2.4) The result returned by requestPermissions is automatic authorization by the system, and then step 1) is entered.

3. In the case of screen extinguishment call, when the middleware layer 1002 detects the mobile phone screen extinguishing broadcast event, the current mobile phone screen is marked as off, at this time the middleware layer 1002 can directly refuse permission; the background application authorization can also Use a more flexible approach, such as authorizing only 24 hours (free access within 24 hours, re-authorization is required after 24 hours). When the middleware layer 1002 detects a bright screen event, the marked screen is modified to be in use state, and the processing flow at this time is the same as the processing flow in 1 and 2.

The processing of the database layer 1003 is as follows: after processing the incoming data of the middle layer, after checking the validity, it is inserted into the database and saved. Receive a query request from the data display layer and feed back the corresponding data to display.

The processing of the data display module 1004 is as follows: through various combinations of queries, the data in the database is displayed in the UI in different dimensions, which is convenient for users to analyze and judge, such as: the number of times the APP accesses contacts, SMS, GPS, call Camera, microphone Duration; analysis of an application ’s use of private data in the most recent period; which applications of a certain privacy data or sensor have been used in the most recent period; can set a fixed weekly or monthly push notification bar for analysis data to remind users to view; or discover Which applications frequently use private data to remind users, etc. for a certain period of time. The specific display methods are not listed here one by one.

With reference to the above solution, effective monitoring of abnormal calls can be achieved. From the user's perspective, statistical information can also be viewed to understand the status of application calls and find abnormal applications. An example of displaying call statistics through the user interface is given below.

FIG. 13 is a statistical diagram of usage periods of microphones and short messages according to an exemplary embodiment of the present application.

Taking the microphone as an example, the horizontal axis is the time coordinate, indicating 0-24 hours of the day. If the bar is filled with a specific pattern, it indicates that the microphone is used during this time. By using different patterns or colors to distinguish different apps, click to display the specific data used (duration and start and end time). By pinching two fingers together, you can display a week of usage charts. The use of the camera can be displayed in a similar manner to the use of the microphone in FIG. 13.

Taking SMS as an example, the horizontal axis is the time coordinate, representing 0-24 hours of a day. The rectangular bar shows the number of times the SMS was accessed in a certain period of time. By using different patterns to distinguish different APPs, click to display the specific use. Data (detailed to each time of use). By pinching two fingers together, you can display a week of usage charts. The use of contacts and GPS can be displayed using a diagram similar to the use of SMS in FIG. 13.

The above is just a display example, and the specific display methods and reminder methods can be various. For example, it can periodically remind the statistics, remind the abnormal behavior data in a certain period of time, etc.

FIG. 14 is a schematic diagram of an interface for reminding a user after using a microphone in the background of an application according to an exemplary embodiment of the present application. As shown in FIG. 14, when the background application (for example, APP1) is called or the application calls the sensitive permission module when the screen is turned off, the terminal can directly refuse the call and use notification to remind the user.

In summary, through this application, after receiving the call request of the application in the terminal to call the sensitive permission module, an abnormal call judgment is made for the call request, and it can be monitored that the application is in the background, the screen is turned off, or the foreground is not received The call request initiated in the case of the user's touch operation, and correspondingly perform one or more of the rejection, reminder, query and other operations. Through this solution, it can solve the problem of software arbitrarily calling sensors to obtain external information or reading user privacy data without the user's knowledge, resulting in the leakage of user privacy, and an effective monitoring application for sensitive permission modules (for example, can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.

Obviously, those skilled in the art should understand that the above-mentioned modules or steps of this application can be implemented by a general-purpose computing device, and they can be concentrated on a single computing device or distributed in a network composed of multiple computing devices Above, optionally, they can be implemented with program code executable by the computing device, so that they can be stored in the storage device to be executed by the computing device, and in some cases, can be in a different order than here The steps shown or described are performed, or they are made into individual integrated circuit modules respectively, or multiple modules or steps among them are made into a single integrated circuit module to achieve. In this way, this application is not limited to any specific combination of hardware and software.

The above are only preferred embodiments of the present application, and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the principles of this application shall be included in the scope of protection of this application.

Claims

A method for processing a call request of a sensitive authority module in a terminal, including:

Receive the call request of the application in the terminal to call the sensitive permission module;

Judging whether the calling request meets a predetermined condition, wherein the predetermined condition includes at least one of the following: the application is in the background when the calling request is initiated, and the screen of the terminal is off when the application initiates the calling request Status, the application is in the foreground when the call request is initiated, but the touch operation is not received on the interface of the application within a predetermined time period before the application initiates the call request;

When the call request satisfies the predetermined condition, a predetermined process is performed on the call request, wherein the predetermined process includes at least one of the following: rejecting the call request, issuing a reminder for the call request, and asking Whether to allow the call request.
The method according to claim 1, wherein the receiving the call request of the application in the terminal to call the sensitive authority module comprises:

The framework layer in the terminal receives the call request initiated by the application to call the sensitive permission module, where the call request includes one of the following: a call permission check request checkSelfPermission, a call permission application request requestPermission.
The method according to claim 2, wherein determining whether the call request satisfies a predetermined condition includes:

The framework layer sends the calling information corresponding to the calling request to the middleware layer in the terminal;

The middleware layer determines whether the call request meets the predetermined condition according to the call information.
The method according to claim 3, wherein the frame layer sending the call information corresponding to the call request to the middleware layer in the terminal includes:

The calling information corresponding to the calling request is transferred to the middleware layer through the calling interface set in the checkSelfPermission or the requestPermission.
The method according to claim 3 or 4, wherein the invoking information corresponding to the invoking request includes: an identification of the application that initiated the invoking request, and the framework layer determining whether to allow the invoking request critical result.
The method according to claim 3, wherein, in the case where the call request satisfies the predetermined condition, performing predetermined processing on the call request includes:

The middleware layer returns a judgment result to determine whether the call request meets the predetermined condition to the framework layer;

The framework layer performs predetermined processing on the call request when the result of the judgment is that the call request meets the predetermined condition.
The method according to any one of claims 3-6, wherein before the framework layer sends the call information corresponding to the call request to the middleware layer in the terminal, it further includes one of the following:

In the case where the call request includes the checkSelfPermission, the framework layer judges whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is allowed , Continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal;

In the case where the call request includes the checkSelfPermission, the framework layer judges whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is not allowed Next, the framework layer initiates a requestPermission to the sensitive permission module called by the checkSelfPermission, and determines whether to automatically authorize the requestPermission according to the type of the sensitive permission module. Continuing the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal;

In the case where the invocation request includes the requestPermission, the framework layer determines whether to automatically authorize the requestPermission according to the type of the sensitive permission module requested by the requestPermission, and when the judgment result is the automatic authorization , Continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.
The method according to claim 1, wherein after performing predetermined processing on the call request, further comprising:

Storing a call record generated by the call request to a database, wherein the call record includes at least one of the following: an identification of the application that initiated the call request, a type of the sensitive authority module called, and a call start Time, the time to end the call, and the duration of the call.
The method according to claim 8, wherein after storing the call record generated by the call request in a database, the method further comprises:

Receive call record viewing request;

According to the call record viewing request, read the call record corresponding to the call record viewing request from the database, and analyze and / or display the read call record.
The method according to claim 1, wherein there is a correspondence between the predetermined condition and the predetermined processing, and when the call request meets the predetermined condition, performing the predetermined processing on the call request includes:

According to the predetermined condition satisfied by the calling request, predetermined processing corresponding to the predetermined condition is determined, and the determined predetermined processing is performed on the calling request.
The method according to claim 10, wherein the correspondence between the predetermined condition and the predetermined processing includes:

When the predetermined condition includes that the screen of the terminal is turned off when the application initiates the call request, the predetermined processing includes at least rejecting the call request;

When the predetermined condition includes that the application is in the background when the calling request is initiated, the predetermined processing includes at least issuing a reminder or asking whether the calling request is allowed for the calling request;

When the predetermined condition includes that the application is in the foreground when the call request is initiated, but the touch operation is not received on the interface of the application within a predetermined time period before the application initiates the call request, the predetermined The processing includes at least issuing a reminder or asking whether the calling request is allowed for the calling request.
A processing device for a call request of a sensitive authority module in a terminal, including:

The call request receiving module is used to receive the call request of the application in the terminal to call the sensitive authority module;

The judgment module is used to judge whether the call request meets a predetermined condition, wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, and the application is initiated when the call request is initiated The screen of the terminal is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request;

A processing module, configured to perform predetermined processing on the calling request when the calling request meets the predetermined condition, wherein the predetermined processing includes at least one of the following: rejecting the calling request, targeting the calling A reminder is requested to ask whether the call request is allowed.
The apparatus according to claim 12, wherein the call request receiving module is located at a frame layer in the terminal, and is configured to receive the call request initiated by the application to call the sensitive permission module, wherein, The call request includes one of the following: a call permission check request checkSelfPermission, and a call permission application request requestPermission.
The apparatus according to claim 13, wherein the apparatus further comprises: an information delivery module, located at the frame layer, for sending the call request corresponding to the judgment module located at the middleware layer in the terminal 'S calling information;

The judgment module is used to judge whether the calling request meets the predetermined condition according to the calling information.
The apparatus according to claim 14, wherein the information transfer module is used to transfer the call information corresponding to the call request to the middleware through the call interface set in the checkSelfPermission or the requestPermission The judgment module of the layer.
The apparatus according to claim 14 or 15, wherein the invocation information corresponding to the invocation request includes: an identification of the application that initiated the invocation request, and the framework layer determining whether to allow the invocation request critical result.
The apparatus according to claim 14, wherein the processing module is located at the frame layer of the terminal,

The judgment module is used to return a judgment result of judging whether the call request meets the predetermined condition to the processing module;

The processing module is configured to perform predetermined processing on the call request when the judgment result is that the call request meets the predetermined condition.
The device according to any one of claims 14-17, further comprising a permission control module, located at a frame layer in the terminal, for performing one of the following:

When the call request includes the checkSelfPermission, determine whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is allowed, call the The information transfer module sends the call information corresponding to the call request to the judgment module located at the middleware layer in the terminal;

When the call request includes the checkSelfPermission, determine whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is not allowed, check The sensitive permission module called by checkSelfPermission initiates requestPermission, and judges whether to automatically authorize the requestPermission according to the type of the sensitive permission module. When the judgment result is automatic authorization, the information transfer module is called to locate The judgment module of the middleware layer in the terminal sends call information corresponding to the call request;

When the call request includes the requestPermission, determine whether to automatically authorize the requestPermission according to the type of the sensitive permission module requested by the requestPermission, and call the request if the judgment result is automatic authorization The information transfer module sends the call information corresponding to the call request to the judgment module located at the middleware layer in the terminal.
The apparatus of claim 12, further comprising:

A storage module, configured to store a call record generated by the call request in a database, wherein the call record includes at least one of the following: an identification of the application that initiated the call request, and the sensitive permission module called Type, time to start the call, time to end the call, and the duration of the call.
The apparatus of claim 19, further comprising:

View request receiving module, used to receive call record viewing request;

The analysis and display module is configured to read the call record corresponding to the call record viewing request from the database according to the call record viewing request, and analyze and / or display the read call record.
The apparatus according to claim 12, wherein there is a correspondence between the predetermined condition and the predetermined processing, and the processing module is configured to: in the case that the call request meets the predetermined condition, according to the The predetermined condition satisfied by the call request determines predetermined processing corresponding to the predetermined condition, and performs the determined predetermined processing on the call request.
A storage medium in which a computer program is stored, wherein the computer program is configured to execute the method described in any one of claims 1 to 11 when it is run.
An electronic device includes a memory and a processor, a computer program is stored in the memory, and the processor is configured to run the computer program to perform the method described in any one of claims 1 to 11.