Hardware access permission control method and system, storage medium and electronic device
By introducing a hardware access permission verification module into the hardware driver, obtaining user authorization and then sending hardware data, the problem of incomplete hardware data access permission control process is solved, and the security and user experience of hardware data are improved.
Patent Information
- Application Number
- CN202311774064.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-20
- Publication Date
- 2025-06-20
AI Technical Summary
In the prior art, the hardware data access permission control process is incomplete, resulting in poor security of hardware data information.
The hardware driver sends a prompt message to the hardware access permission verification module through the hardware driver. Only after obtaining the permission information can the hardware driver send the hardware data to the target application.
The hardware data access permission control process has been improved, the hardware data security has been improved, and the user experience has been improved.
Smart Images
Figure CN120180459A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of data security, and more specifically, to a method and system for controlling hardware access permissions, a storage medium, and an electronic device. Background Art
[0002] Currently, terminals integrate more and more hardware devices that can obtain user information, such as microphones, cameras, gyroscopes, and so on. These hardware devices can obtain personal information related to users. As Figure 1 shown, it is a schematic diagram of the process for an application to obtain hardware data in the prior art. When obtaining hardware data, the Android application layer has an authorization mechanism for hardware access. Users can set the permissions for applications to obtain hardware data at the application layer. If a user authorizes an application to obtain hardware data, then the application can access the hardware data at any time in the future; if the user does not authorize the application to obtain hardware data, then the application cannot access the hardware data, and the process of the application accessing the hardware data terminates. Further, after an application obtains user authorization, if the application obtains hardware data in the background, then the user cannot perceive it, and thus there is a risk of data leakage. In addition, low data information security will also cause user panic, and thus cannot bring a better experience to users.
[0003] In view of the problem in the related art that the control process of hardware data access permissions is imperfect, resulting in poor security of hardware data information, no effective solution has been proposed yet. Summary of the Invention
[0004] The embodiments of the present application provide a method and system for controlling hardware access permissions, a storage medium, and an electronic device, so as to at least solve the problem in the related art that the control process of hardware data access permissions is imperfect, resulting in poor security of hardware data information.
[0005] According to an embodiment of the present application, a method for controlling hardware access permissions is provided, including: instructing a hardware driver to send a prompt message to a hardware access permission verification module when a target request sent by a target application is obtained, where the target request is used to request to obtain hardware data of a target hardware, and the prompt message is used to prompt the hardware access permission verification module that the target application requests to obtain the hardware data of the target hardware; instructing the hardware access permission verification module to display an authorization page when the prompt message is obtained, and to send the response information to the hardware driver when response information determined by a target object according to the authorization page is obtained, where the authorization page is used to instruct the target object to determine whether to allow the target application to obtain the hardware data of the target hardware; instructing the hardware driver to send the hardware data of the target hardware to the target application when it is determined that the response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware.
[0006] According to another embodiment of the present application, a control system for hardware access permissions is provided, including: a hardware driver, configured to send a prompt message to a hardware access permission verification module when a target request sent by a target application is obtained, where the target request is used to request to obtain hardware data of a target hardware, and the prompt message is used to prompt the hardware access permission verification module that the target application requests to obtain the hardware data of the target hardware; the hardware access permission verification module, configured to display an authorization page when the prompt message is obtained, and to send the response information to the hardware driver when response information determined by a target object according to the authorization page is obtained, where the authorization page is used to instruct the target object to determine whether to allow the target application to obtain the hardware data of the target hardware; wherein, the hardware driver is further configured to send the hardware data of the target hardware to the target application when it is determined that the response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware.
[0007] According to still another embodiment of the present application, a computer-readable storage medium is further provided, where a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the steps in any one of the above method embodiments when running.
[0008] According to still another embodiment of the present application, an electronic device is further provided, including a memory and a processor, where a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
[0009] Through this application, in one of the above technical solutions, after the hardware driver obtains the target request for obtaining hardware data sent by the target application, it will obtain the permission information through the hardware access permission verification module (that is, whether the target object (such as a user) allows the target application to obtain hardware data). Furthermore, the hardware driver will send the hardware data to the target application only when it determines that the target object allows the target application to obtain hardware data. Since the terminal device controls the hardware access permission at the hardware driver layer, it provides users with a more detailed and secure (security control in the kernel driver) hardware access permission control function, improves the hardware data access permission control process, solves the problem of poor security of hardware data information caused by the imperfect hardware data access permission control process, and achieves the technical effect of improving the security of hardware data and the user experience. Description of the Drawings
[0010] Figure 1 is a schematic flowchart of the process for an application program to obtain hardware data in the prior art;
[0011] Figure 2 is a hardware structure block diagram of a computer terminal for a method of controlling hardware access permissions according to an embodiment of the present application;
[0012] Figure 3 is a flowchart of a method of controlling hardware access permissions according to an embodiment of the present application;
[0013] Figure 4 is a schematic flowchart of the process for an application program to obtain hardware data according to an embodiment of the present application;
[0014] Figure 5 is a flowchart of generating and loading parameters of an access hardware control module according to an embodiment of the present application;
[0015] Figure 6 is a schematic diagram of the main interface of an access hardware control function according to an embodiment of the present application;
[0016] Figure 7 is a schematic diagram of an access hardware control process according to an embodiment of the present application;
[0017] Figure 8 is a schematic diagram of an interface for setting an application whitelist of an access hardware control function according to an embodiment of the present application;
[0018] Figure 9 is a schematic diagram of a user authorization interface of an access hardware control function according to an embodiment of the present application;
[0019] Figure 10 is a schematic diagram of an interface for setting device management and control of an access hardware control function according to an embodiment of the present application;
[0020] Figure 11 is a schematic diagram of an alarm interface for setting access to hardware control functions according to an embodiment of the present application;
[0021] Figure 12 is a schematic flowchart (I) of an embodiment of a method for controlling hardware access permissions according to an embodiment of the present application;
[0022] Figure 13 is a schematic flowchart (II) of an embodiment of a method for controlling hardware access permissions according to an embodiment of the present application;
[0023] Figure 14 is a block diagram of the structure of a control system for hardware access permissions according to an embodiment of the present application. Detailed implementation manners
[0024] Embodiments of the present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.
[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence.
[0026] The method embodiments provided in the embodiments of the present application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 2 is a hardware block diagram of a mobile terminal of a method for controlling hardware access permissions according to an embodiment of the present application. As Figure 2 shown, the mobile terminal may include one or more ( Figure 2 only one is shown in the figure) processors 202 (the processors 202 may include, but are not limited to, processing devices such as a microprocessor (Central Processing Unit, MCU) or a field programmable gate array (Field Programmable Gate Array, FPGA)) and a memory 204 for storing data. Among them, the above-mentioned mobile terminal may further include a transmission device 206 for communication functions and an input / output device 208. Those of ordinary skill in the art can understand that Figure 2 the structure shown is only schematic and does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal may further include more or fewer components than Figure 2 shown in the figure, or have a different configuration from Figure 2 shown in the figure.
[0027] The memory 204 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the hardware access permission control method in the embodiments of the present application. The processor 202 executes various functional applications and data processing by running the computer program stored in the memory 204, that is, implements the above method. The memory 204 can include high-speed random access memory, and can also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 204 can further include a memory remotely set relative to the processor 202, and these remote memories can be connected to the mobile terminal through a network. Examples of the above network include but are not limited to the Internet, enterprise intranet, local area network, mobile communication network, and combinations thereof.
[0028] The transmission device 206 is used to receive or send data via a network. Specific examples of the above network can include the wireless network provided by the communication provider of the mobile terminal. In one instance, the transmission device 206 includes a network adapter (abbreviated as NIC), which can be connected to other network devices through a base station and thus can communicate with the Internet. In one instance, the transmission device 206 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0029] Figure 3 is a flowchart of the hardware access permission control method according to the embodiments of the present application, as Figure 3 shown, the method includes the following steps S302 - S306:
[0030] Step S302: Instruct the hardware driver to send a prompt message to the hardware access permission verification module when it obtains a target request sent by a target application, where the target request is used to request to obtain the hardware data of a target hardware, and the prompt message is used to prompt the hardware access permission verification module that the target application requests to obtain the hardware data of the target hardware;
[0031] As an optional embodiment, the target hardware includes but is not limited to hardware such as cameras and microphones; the target application can be all applications currently on the market that need to obtain hardware data, and the embodiments of the present application do not further limit this.
[0032] As an optional embodiment, the hardware access permission verification module is a service program, which can be set in terminal products such as mobile phones, watches, bracelets, and wearable electronic products, and is used to provide the control function of hardware access permission.
[0033] As an alternative embodiment, taking the case where the hardware access permission verification module is set on a mobile phone as an example, after the mobile phone runs, the hardware access permission verification module can be automatically started in the background. Then, the hardware access permission verification module determines whether the control function of the hardware access permission is turned on by the user. If it has been turned on, it can directly load the access hardware control configuration table saved on the mobile phone. If it is the first boot, a default access hardware control configuration table is generated. It should be noted that if the user has already turned on the control function of the hardware access permission on the mobile phone, there is already a corresponding access hardware control configuration table on the mobile phone. Further, after the hardware access permission verification module loads the access hardware control configuration table, it will send the information corresponding to the access hardware control configuration table to the corresponding hardware driver.
[0034] It should be noted that the access hardware control configuration table can be used to configure the hardware driver, so that the hardware driver can send a prompt message to the hardware access permission verification module when it obtains a target request sent by a target application.
[0035] That is, this application can add a hardware access control interface in the hardware driver. When the hardware driver runs to each driver interface, it will run to the added hardware access control interface, and then the hardware access control interface will notify the hardware access permission verification module.
[0036] As an alternative example, the hardware driver communicates with the hardware access permission verification module through the hardware access control interface.
[0037] As an alternative embodiment, the terminal to which this application is applied includes an application layer, a hardware driver layer, and a hardware layer. The hardware access permission verification module can be set on the application layer. The hardware driver is located in the hardware driver layer, and the target hardware is located in the hardware layer.
[0038] In an exemplary embodiment, sending a prompt message to the hardware access permission verification module includes the following steps S11 - S12:
[0039] Step S11: Determine whether a first response message has been received within a preset duration before the current moment, where the first response message is used to indicate that the target application is allowed to obtain the hardware data of the target hardware;
[0040] As an alternative embodiment, the preset duration can be flexibly set by the target object, such as 1 minute, and the embodiments of this application do not make further limitations on this.
[0041] Step S12: In the case where the first response message has not been received within the preset duration before the current moment, send a prompt message to the hardware access permission verification module;
[0042] It should be noted that if the first response message has been received within a preset duration before the current moment, there is no need to repeatedly send a prompt message to the hardware access permission verification module. The hardware driver can directly determine to allow the target application to obtain the hardware data of the target hardware, and then directly send the hardware data of the target hardware to the target application.
[0043] As an optional example, when the hardware driver obtains the target request sent by the target application, it can directly send a prompt message to the hardware access permission verification module. Then, the hardware access permission verification module determines whether it has sent a first response message to the hardware driver within a preset duration before the current moment. If it determines that a first response message has been sent, it does not display the authorization interface and directly sends the first response message to the target application.
[0044] In the example of this application, through the above method, it is possible to avoid disturbing the user multiple times when the target application continuously obtains the hardware data of the target hardware, improving the user experience.
[0045] In an exemplary embodiment, sending a prompt message to the hardware access permission verification module further includes the following step S21:
[0046] Step S21: Send a prompt message to the hardware access permission verification module in the target stage;
[0047] Wherein, the target stage includes at least one of the following: the power-on stage of the hardware driver for the target hardware, the initialization stage of the hardware driver for the target hardware, and the stage of data interaction between the hardware driver and the target hardware.
[0048] It should be noted that the power-on stage means that the hardware driver turns on the power supply of the hardware chip; the initialization stage means that the hardware driver initializes the hardware, including sending initialization parameters to the hardware, downloading firmware, and making the hardware reach a working state; the data interaction stage means that the hardware driver provides hardware data to the upper-layer target application according to the request of the target application.
[0049] It should be noted that when the hardware driver sends a prompt message to the hardware access permission verification module in the target stage, the hardware driver will pause the process operation of the target stage and, when obtaining the response message from the hardware access permission verification module, determine whether to resume the process operation of the target stage according to the response message.
[0050] Step S304: Instruct the hardware access permission verification module to display an authorization page when the prompt message is obtained, and send the response information to the hardware driver when the response information determined by the target object according to the authorization page is obtained, where the authorization page is used to instruct the target object to determine whether to allow the target application to obtain the hardware data of the target hardware;
[0051] As an optional example, the authorization interface can be the interface shown on the right. Before displaying the authorization page, a prompt clause as shown on the left will also be displayed. Figure 9 On the right side as shown, and before displaying the authorization page, a prompt clause as shown on the left will also be displayed. Figure 9 On the left side as shown.
[0052] It should be noted that the response information includes a first response information and a second response information. The first response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware, and the second response information is used to indicate that the target application is not allowed to obtain the hardware data of the target hardware.
[0053] In an exemplary embodiment, before instructing the hardware access permission verification module to display the authorization page, the following steps S31 - S32 are further included:
[0054] Step S31: Instruct the hardware access permission verification module to determine whether the target terminal is in a sleep state when the prompt message is obtained, where the target application is an application in the target terminal, and the target hardware is hardware in the target terminal;
[0055] As an optional embodiment, the target terminal includes but is not limited to a mobile phone, a tablet computer, etc.
[0056] Step S32: Instruct the hardware access permission verification module to control the target terminal to enter an alarm mode when it is determined that the target terminal is in a sleep state, where the target terminal performs at least one of the following in the alarm mode: vibrate, play a specified voice.
[0057] As an optional embodiment, as shown in Figure 11 it is possible to set the alarm method by accessing the settings alarm interface of the hardware control function, including but not limited to vibration alarm, speaker alarm, floating box prompt, and voice prompt, etc. The alarm method can be flexibly set by the target object, and the embodiments of the present application do not make further limitations in this regard. Further, the user can customize the frequency and content of the alarm mode.
[0058] In an exemplary embodiment, after instructing the hardware access permission verification module to display the authorization page when the prompt message is obtained, the following step S41 is further included:
[0059] Step S41: Instruct the hardware access permission verification module to send a second response message to the hardware driver when it determines that the response information determined by the target object according to the authorization page has not been obtained within the preset time, where the second response information is used to indicate that the target application is not allowed to obtain the hardware data of the target hardware.
[0060] As an alternative embodiment, when the hardware driver does not obtain the response information sent by the hardware access permission verification module within the preset time, it does not send the hardware data of the target hardware to the target application.
[0061] As an alternative embodiment, assuming that the preset time is three minutes, when the hardware access permission verification module does not receive the response information within three minutes, it directly sends the second response information to the hardware driver.
[0062] Step S306: Instruct the hardware driver to send the hardware data of the target hardware to the target application when it determines that the response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware.
[0063] Through the above steps S302 - S306, after the hardware driver obtains the target request for obtaining hardware data sent by the target application, it will obtain the permission information through the hardware access permission verification module (that is, whether the target object (such as the user) allows the target application to obtain hardware data). Furthermore, when the hardware driver determines that the target object allows the target application to obtain hardware data, it will send the hardware data to the target application. Since the terminal device performs hardware access permission control at the hardware driver layer, it provides a more detailed and secure (security control in the kernel driver) hardware access permission control function for users, improves the hardware data access permission control process, solves the problem of poor security of hardware data information caused by the imperfect hardware data access permission control process, and achieves the technical effect of improving the security of hardware data and the user experience.
[0064] As an alternative example, the execution subject of the above steps S302 - S306 is the above target terminal.
[0065] In an exemplary embodiment, the above method further includes the following step S51:
[0066] Step S51: Instruct the hardware access permission verification module to send a first response message to the hardware driver when it obtains the prompt information and determines that the application identifier of the target application is in the target list, where the target list has the identifiers of applications that are allowed to directly obtain the hardware information of the target hardware, and the first response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware;
[0067] The foregoing instructing the hardware access permission verification module to display the authorization page when the prompt information is obtained includes: instructing the hardware access permission verification module to display the authorization page when the prompt information is obtained and it is determined that the target application is not in the target list.
[0068] As an optional embodiment, Figure 8 As shown, the whitelist (i.e., the target list mentioned above) can be flexibly set by the target object on the whitelist setting page of the hardware access permission verification module, including but not limited to adding new applications to the whitelist and deleting existing applications in the whitelist. The user assumes that there are application identifiers corresponding to the three applications, Application 1, Application 2, and Application 3, in the whitelist. When Application 1 wants to obtain hardware data, the hardware access permission verification module determines that Application 1 is in the whitelist, and then can directly send the first response information to the hardware driver without displaying the authorization page. When Application 4 wants to obtain hardware data, the hardware access permission verification module determines that Application 4 is not in the whitelist, and the hardware access permission verification module needs to display the authorization page.
[0069] In an exemplary embodiment, the method further comprises the following steps S61:
[0070] Step S61: instructing the hardware access permission verification module to send a second response message to the hardware driver when the prompt message is obtained and the target application is determined to be a background application, wherein the second response message is used to indicate that the target application is not allowed to obtain the hardware data of the target hardware;
[0071] The foregoing instructing the hardware access permission verification module to display the authorization page when the prompt information is obtained includes: instructing the hardware access permission verification module to display the authorization page when the prompt information is obtained and it is determined that the target application is a foreground application.
[0072] As an optional embodiment, assuming that the prompt information is that the target application wants to obtain the hardware data corresponding to the camera, when the hardware access permission verification module obtains this prompt information and determines that the target application that initiates the prompt information is a background application, it indicates that there may be illegal access at present, and then instructs the hardware driver not to send the hardware data corresponding to the camera to the target application.
[0073] As an alternative example, Figure 10 As described above, the hardware that needs to undergo hardware access permission verification can be determined by the hardware access permission verification module.
[0074] Obviously, the embodiments described above are only a part of the embodiments of this application, rather than all the embodiments. To better understand the above method, the following will describe the above process in conjunction with embodiments, but it is not used to limit the technical solutions of the embodiments of this application. Specifically:
[0075] This application provides a user with a method for controlling secondary hardware access permissions with a higher security level. Generally speaking, in the Linux kernel mode, hardware access control interfaces are added to the driver program interfaces such as the opening, initialization, operation, and closing processes of the hardware device driver. When the hardware driver program runs to each driver program interface, it will run to the added hardware access control interface of this application. At this time, the hardware access control interface will notify the upper-layer hardware access control service (i.e., the above-mentioned hardware access permission verification module). After receiving the notification, the upper-layer hardware access control service notifies the user to perform an authorization operation on the confirmation authorization interface. After the user authorizes, the authorization result is sent to the hardware driver program, and the hardware driver process continues to execute normally; otherwise, the hardware driver program terminates. The application program fails to open the hardware device, and the application program fails to access the hardware data.
[0076] A scenario applicable to this application can be that when a user is using a mobile phone and an application program accesses the hardware device on the mobile phone, the software process correspondingly opens the hardware device, initializes the hardware device, obtains hardware data, and closes the hardware device. For the application interface, the hardware driver program correspondingly has power-on, initialization, data acquisition, and closing interfaces for the application to call.
[0077] Figure 4 It is a flowchart of the process for an application program to obtain hardware data according to an embodiment of this application. As Figure 4 shown, after the application program 1 obtains the user's authorization to access the hardware data, when the application accesses the hardware, the hardware driver program will initiate an access hardware control permission verification process. At this time, an access hardware control user confirmation interface (equivalent to the above-mentioned authorization page) will pop up on the mobile phone. After the user confirms, the user authorization confirmation instruction is sent down. After receiving the authorization confirmation instruction, the hardware driver program parses it and continues to run after passing the verification. Otherwise, the process of the application program 1 accessing the hardware driver program terminates. The application program 1 fails to obtain the hardware data.
[0078] Figure 5 It is a flowchart of the generation and loading of the parameters of the access hardware control module according to an embodiment of this application. As Figure 5 shown, the parameter generation and loading process includes the following S501-S504:
[0079] S501: The terminal boots and runs: After the terminal boots and runs, the access hardware control module (i.e., the hardware access permission verification module in the above embodiment) will be automatically started in the background and enter S502;
[0080] S502: Verify whether the function is enabled: Determine whether the access hardware control module is enabled (as shown in the relevant interface diagram Figure 6 ). If it is enabled, proceed to S503. If it is not enabled, proceed to S501. This step can be implemented to detect in a loop at regular intervals or can be immediately executed by an interface called by other functions;
[0081] S503: Generate and load the configuration file: Load the access hardware control configuration table saved on the terminal. If it is the first boot, generate the default access hardware control configuration table first. If the access hardware control function has been opened before, there is already a corresponding access hardware control configuration table on the terminal;
[0082] S504: Issue and update the system configuration: After the access hardware control module loads the access hardware control configuration table, send the corresponding information to the corresponding hardware driver program.
[0083] Figure 7 is a schematic diagram of an access hardware control process according to an embodiment of the present application. As Figure 7 shown, the process includes S701: The application accesses the hardware; S702: Access hardware control; S703: Power on; S704: Initialize; S705: Data interaction. The specific process is as follows:
[0084] S701: The application accesses the hardware: When a certain application on the terminal accesses the hardware data on the terminal, first proceed to S703; When the power-on process in S703 returns normally, proceed to S704. If S703 returns an exception, the application process terminates; When the initialization process in S704 returns normally, proceed to S705. If S704 returns an exception, the application process terminates; If the data interaction process in S705 returns an exception, the application process terminates.
[0085] S702: Access hardware control:
[0086] Initial configuration: After the terminal boots and runs, the access hardware control module loads the corresponding configuration parameters of this function on the terminal into the system, including sending the user-preset hardware permission control configuration to the hardware driver program.
[0087] The access hardware control module can detect the applications in the current system of the terminal, add the applications to the whitelist, or remove the relevant applications from the whitelist. Figure 8 Schematically shows a schematic diagram of the access hardware control function setting the application whitelist interface.
[0088] Process the authorization reported by the driver:
[0089] S703, S704, and S705 report authorization applications. According to the rules configured by the user:
[0090] 1. If the application being used is in the configured whitelist, directly return authorization success.
[0091] 2. If the user enables the authorization option for the access hardware control function UI interface and the system is in the awakened state, pop up the user authorization interface for the access hardware control function. The user authorization interface for the access hardware control function is as Figure 9 shown. After the user selects the authorization option, send the corresponding authorization result and enter the corresponding S703, S704, S705. As an optional embodiment, the user can select the device to be controlled in the device management and control interface for the access hardware control function. The schematic diagram of the device management and control interface for the access hardware control function is as Figure 10 shown.
[0092] If the system is in the sleep state, enter the alarm mode preset by the user. As an optional embodiment, the user can select the alarm mode in the alarm setting interface for the access hardware control function as Figure 11 shown, and at the same time pop up the user authorization interface. After the user selects the authorization option, send the corresponding authorization result and enter the corresponding S703, S704, S705. After the timeout of the non-selection of the authorization status by the user, send an abnormal authorization result and enter the corresponding S703, S704, S705.
[0093] 3. When the application applying for authorization for the first time runs in the background, directly return authorization failure.
[0094] S703: Power-on: The driver powers on the hardware, that is, turns on the power supply of the hardware chip. During the power-on stage, the driver will return the state after the hardware is powered on, normal or abnormal state.
[0095] When the access hardware control function is turned off, after the driver power-on software process is completed, enter S701.
[0096] When the access hardware control function is turned on, the driver power-on software process is interrupted, and report the information on which application program calls this driver power-on process. Wait for the authorization confirmation information from the access hardware control module. If the user authorizes successfully, the driver power-on software process continues to execute. After execution is completed, return the corresponding state and enter S701. If the user does not authorize, the driver power-on software process terminates, returns an abnormal state, and enters S701.
[0097] S704: Initialization: The hardware driver initializes the hardware, including sending initialization parameters to the hardware, downloading firmware, and making the hardware reach a working state.
[0098] When the access hardware control function is turned off, after the hardware driver initialization software process is completed, it enters S701.
[0099] When the access hardware control function is turned on, the hardware driver initialization software process is interrupted, and information about which application called the hardware driver initialization process is reported. Wait for the authorization confirmation information from the access hardware control module. If the user authorizes successfully, the hardware driver initialization software process continues to execute. After execution is completed, the corresponding status is returned and it enters S701. If the user does not authorize, the hardware driver initialization software process terminates, returns an abnormal status, and enters S701.
[0100] S705: Data interaction:
[0101] The hardware driver receives the instructions sent by the application program, provides the result data after operation to the upper-layer application program, and at the same time returns the hardware execution status.
[0102] When the access hardware control function is turned off, after the hardware driver data interaction process is completed, it enters S701.
[0103] When the access hardware control function is turned on, the hardware driver data interaction process is interrupted, and it is judged whether the application program that obtains the hardware data has obtained authorization from the access hardware control module. If not authorized, information about which application called the hardware driver data interaction process is reported. Wait for the authorization confirmation information from the access hardware control module. If the user authorizes successfully, the hardware driver data interaction software process continues to execute. After execution is completed, the corresponding status is returned and it enters S701. If the user does not authorize, the hardware driver data interaction software process terminates, returns an abnormal status, and enters S701.
[0104] For application programs that the user has authorized successfully, when accessing hardware data for the second, third, and Nth times. The hardware driver re-reports the authorization application according to the time interval between two adjacent accesses if it exceeds the time interval threshold.
[0105] If already authorized, the hardware driver initialization software process is not interrupted. After the hardware driver data interaction process is completed, it enters S701.
[0106] S706: Shutdown and power-off: The hardware driver powers off the hardware, that is, turns off the power supply of the hardware chip. When powering off the hardware chip, in order to ensure that all scenarios can be powered off normally, the power-off needs to meet the hardware chip power-off timing. Such as sending an additional sleep instruction for delay.
[0107] The hardware driver receives the shutdown instruction sent by the application and runs the hardware shutdown and power-down processes in the hardware driver. Then, it returns the operation results of the shutdown and power-down processes to the upper-layer application.
[0108] To better understand the hardware access permission control method in this application, Examples 1 and 2 are used for further illustration:
[0109] Example 1: The first application accesses the hardware data of the camera:
[0110] As Figure 12 shown, it is a schematic flowchart (1) of an embodiment of a hardware access permission control method according to an embodiment of this application. The process includes the following steps:
[0111] S1201: The user opens the access hardware control function in the settings interface.
[0112] S1202: On the interface of the first application, log in to the provident fund information account. When using face login, if it is the first time the first application uses the camera, the user needs to authorize. After the user selects the corresponding permission, an access hardware authorization interface pops up on the current interface of the terminal. The access hardware authorization interface prompts the user that the first application wants to obtain the data in the camera driver. After the user authorizes on the UI prompt interface, the user successfully logs in using the camera face.
[0113] S1203: After that, during the user's use of the terminal, whether in the wake-up or sleep state, the first application can initiate the process of obtaining camera data at any time. Since the Android permission has been authorized just now, it can directly access the hardware driver at this time.
[0114] S1204: For the camera driver, if it determines that the time between the first application obtaining camera data this time and the last time is greater than 1 second, it reports the access hardware permission application process.
[0115] S1205: At this time, if the terminal is in the sleep state, it enters S1206; if it is in the wake-up state, it enters S1207.
[0116] S1206 (alarm): The access hardware control service calls the Android interface, vibrates the terminal, turns on the speaker, and broadcasts the voice "The first application has accessed the camera".
[0117] S1207 (Prompt the user to block): The access to the hardware control service initiates user UI authorization. If the user discovers that the interface is not for the camera usage scenario, the user can reject the authorization, and the camera driver process returns an exception. The first application fails to obtain camera data. The access to the hardware control service detects that the application for which authorization is requested is not the foreground application (i.e., the background application), and directly sends an authorization failure message to the camera driver program, terminating the process for the first application to obtain camera data.
[0118] Embodiment 2, the second application accesses the hardware data of the microphone:
[0119] Figure 13 It is a flowchart (two) of an embodiment of a method for controlling hardware access permissions according to an embodiment of the present application. The process includes the following steps:
[0120] S1301: The user turns on the access to the hardware control function in the settings interface;
[0121] S1302: Whether it is a voice call or initiating a voice, after the user grants the second application android permissions, the software process for the second application to access the microphone enters the next step S1303;
[0122] S1303: The second application starts the process of obtaining microphone data. The process for the second application to access microphone data runs to the microphone driver and enters S1304;
[0123] S1304: The hardware driver program combines the time difference between this application and the previous application to determine whether to report this authorization application. If the time interval between this authorization application and the previous authorization application is greater than 1 second, it reports and enters S1305. Otherwise, it does not report and directly enters S1306. Only the application time is updated, aiming to avoid reporting application permissions frequently and having the user confirm authorization frequently;
[0124] S1305: The microphone driver program reports that "the microphone driver is called by the second application for data, and the user needs to authorize the second application to access the microphone this time". After the user authorizes on the second application interface, it enters S1306;
[0125] S1306: The second application continues to run the process of accessing the microphone, and the voice call is okay. During the continuous call process, the UI interface only displays one authorization application. During the continuous voice call of the authorized user, S1303 ----> S1304 ----> S1306 ----> S1303 loops continuously;
[0126] One minute after the user ends the call, the user initiates a new voice call using the second application, and the android permission no longer reminds the user to authorize. From S1302 ----> S1303 ----> S1304, at this time, S1304 discovers that the time interval between this authorization application and the previous authorization application is greater than 1 second, and enters S1305.
[0127] 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. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as Read-Only Memory / Random Access Memory, ROM / RAM, magnetic disk, optical disk), and includes several instructions for causing a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present application.
[0128] The embodiment of the present application also provides a control system for hardware access permissions. Figure 14 It is a structural block diagram of a control system for hardware access permissions according to an embodiment of the present application. The control system for hardware access permissions includes:
[0129] The hardware driver 1402 is used to send a prompt message to the hardware access permission verification module 1404 when obtaining a target request sent by a target application. Wherein, the target request is used to request to obtain hardware data of a target hardware, and the prompt message is used to prompt the hardware access permission verification module 1404 that the target application requests to obtain the hardware data of the target hardware;
[0130] The hardware access permission verification module 1404 is used to display an authorization page when obtaining the prompt message, and send the response information to the hardware driver 1402 when obtaining response information determined by a target object according to the authorization page. Wherein, the authorization page is used to instruct the target object to determine whether to allow the target application to obtain the hardware data of the target hardware;
[0131] Wherein, the hardware driver 1402 is further used to send the hardware data of the target hardware to the target application when determining that the response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware.
[0132] Through the above system, after the hardware driver 1402 obtains the target request for obtaining hardware data sent by the target application, it will obtain permission information through the hardware access permission verification module 1404 (that is, whether the target object (such as a user) allows the target application to obtain hardware data). Furthermore, the hardware driver 1402 will send the hardware data to the target application only when it is determined that the target object allows the target application to obtain hardware data. Since the terminal device controls the hardware access permission at the hardware driver layer, it provides users with a more detailed and secure (security control in the kernel driver) hardware access permission control function, improves the hardware data access permission control process, and solves the problem of poor security of hardware data information caused by the imperfect hardware data access permission control process, achieving the technical effect of improving the security of hardware data and the user experience.
[0133] In an exemplary embodiment, the hardware driver 1402 is further configured to determine whether a first response message is received within a preset duration before the current moment, where the first response message is used to indicate that the target application is allowed to obtain the hardware data of the target hardware; in the case that the first response message is not received within the preset duration before the current moment, a prompt message is sent to the hardware access permission verification module 1404; where, in the case that the first response message is received within the preset duration before the current moment, the hardware driver 1402 is instructed to obtain the hardware data of the target hardware and send the hardware data to the target application.
[0134] In an exemplary embodiment, the hardware driver 1402 is further configured to send a prompt message to the hardware access permission verification module 1404 at a target stage; where the target stage includes at least one of the following: the power-on stage of the hardware driver 1402 for the target hardware, the initialization stage of the hardware driver 1402 for the target hardware, and the stage where the hardware driver 1402 performs data interaction with the target hardware.
[0135] In an exemplary embodiment, the hardware access permission verification module 1404 is further configured to send a first response message to the hardware driver 1402 when the prompt message is obtained and it is determined that the application identifier of the target application is in the target list, where the target list has the identifiers of applications that are allowed to directly obtain the hardware information of the target hardware, and the first response message is used to indicate that the target application is allowed to obtain the hardware data of the target hardware; the hardware access permission verification module 1404 is further configured to display an authorization page in the following manner: when the prompt message is obtained and it is determined that the target application is not in the target list, the authorization page is displayed.
[0136] In an exemplary embodiment, the hardware access permission verification module 1404 is further configured to, when obtaining the prompt message and determining that the target application is a background application, send a second response message to the hardware driver 1402, where the second response message is used to indicate that the target application is not allowed to obtain the hardware data of the target hardware; the hardware access permission verification module 1404 is further configured to display an authorization page in the following manner: when obtaining the prompt message and determining that the target application is a foreground application, display the authorization page.
[0137] In an exemplary embodiment, the hardware access permission verification module 1404 is further configured to, when obtaining the prompt message, determine whether the target terminal is in a sleep state, where the target application is an application in the target terminal, and the target hardware is hardware in the target terminal; when determining that the target terminal is in a sleep state, control the target terminal to enter an alarm mode, where the target terminal at least performs one of the following in the alarm mode: vibrate, play a specified voice.
[0138] In an exemplary embodiment, the hardware access permission verification module 1404 is further configured to, when determining that the response message determined by the target object according to the authorization page is not obtained within a preset time, send a second response message to the hardware driver 1402, where the second response message is used to indicate that the target application is not allowed to obtain the hardware data of the target hardware.
[0139] It should be noted that the above-mentioned various modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited thereto: the above-mentioned modules are all located in the same processor; or, the above-mentioned various modules are respectively located in different processors in any combination form.
[0140] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, where the computer program is set to execute the steps in any one of the above method embodiments when running.
[0141] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: a USB flash drive, a read-only memory (ROM for short), a random access memory (RAM for short), a mobile hard disk, a magnetic disk, or an optical disc and other various media that can store a computer program.
[0142] An embodiment of the present application further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.
[0143] In an exemplary embodiment, the above electronic device may further include a transmission device and an input / output device. The transmission device is connected to the processor, and the input / output device is connected to the processor.
[0144] Specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be repeated here.
[0145] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order from here, or they can be separately made into individual integrated circuit modules, or multiple modules or steps among them can be made into a single integrated circuit module to implement. In this way, the present application is not limited to any specific combination of hardware and software.
[0146] The above are only the preferred embodiments of the present application and are not used to limit the present application. For those skilled in the art, the present application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the principle of the present application shall be included in the protection scope of the present application.
Claims
1. A method for controlling hardware access rights, characterized in that, including: instructing a hardware driver to send a prompt message to a hardware access permission verification module when the hardware driver obtains a target request sent by a target application, where the target request is used to request to obtain hardware data of a target hardware, and the prompt message is used to prompt the hardware access permission verification module that the target application requests to obtain the hardware data of the target hardware; instructing the hardware access permission verification module to display an authorization page when the hardware access permission verification module obtains the prompt message, and to send the response message to the hardware driver when the hardware access permission verification module obtains response information determined by a target object according to the authorization page, where the authorization page is used to instruct the target object to determine whether to allow the target application to obtain the hardware data of the target hardware; instructing the hardware driver to send the hardware data of the target hardware to the target application when it is determined that the response information is used to indicate that the target application is allowed to obtain the hardware data of the target hardware.
2. The method according to claim 1, characterized in that, Sending a prompt message to the hardware access permission verification module includes: determining whether a first response message is received within a preset duration before the current moment, where the first response message is used to indicate that the target application is allowed to obtain the hardware data of the target hardware; sending a prompt message to the hardware access permission verification module when the first response message is not received within the preset duration before the current moment; where, when the first response message is received within the preset duration before the current moment, instructing the hardware driver to obtain the hardware data of the target hardware and send the hardware data to the target application.
3. The method according to claim 1, characterized in that, Sending a prompt message to the hardware access permission verification module includes: sending a prompt message to the hardware access permission verification module in a target stage; where the target stage includes at least one of the following: a power-on stage of the hardware driver for the target hardware, an initialization stage of the hardware driver for the target hardware, and a stage where the hardware driver performs data interaction with the target hardware.
4. The method according to claim 1, characterized in that, The method further includes: instructing the hardware access permission verification module to send a first response message to the hardware driver when the hardware access permission verification module obtains the prompt message and determines that the application identifier of the target application is in a target list, where the target list has identifiers of applications that are allowed to directly obtain the hardware information of the target hardware, and the first response message is used to indicate that the target application is allowed to obtain the hardware data of the target hardware; instructing the hardware access permission verification module to display an authorization page when the hardware access permission verification module obtains the prompt message includes: instructing the hardware access permission verification module to display the authorization page when the hardware access permission verification module obtains the prompt message and determines that the target application is not in the target list.
5. The method according to claim 1, characterized in that, The method further includes: Instruct the hardware access permission verification module to send a second response message to the hardware driver when it obtains the prompt message and determines that the target application is a background application, where the second response message is used to instruct that the target application is not allowed to obtain the hardware data of the target hardware; Instruct the hardware access permission verification module to display an authorization page when it obtains the prompt message, including: instruct the hardware access permission verification module to display the authorization page when it obtains the prompt message and determines that the target application is a foreground application.
6. The method according to claim 1, characterized in that, Before instructing the hardware access permission verification module to display the authorization page, the method further includes: Instruct the hardware access permission verification module to determine whether the target terminal is in a sleep state when it obtains the prompt message, where the target application is an application in the target terminal, and the target hardware is hardware in the target terminal; Instruct the hardware access permission verification module to control the target terminal to enter an alarm mode when it determines that the target terminal is in a sleep state, where the target terminal performs at least one of the following in the alarm mode: vibrate, play a specified voice.
7. The method according to claim 1, characterized in that, After instructing the hardware access permission verification module to display the authorization page when it obtains the prompt message, the method further includes: Instruct the hardware access permission verification module to send a second response message to the hardware driver when it determines that the response message determined by the target object according to the authorization page is not obtained within a preset time, where the second response message is used to instruct that the target application is not allowed to obtain the hardware data of the target hardware.
8. A control system for hardware access rights, characterized in that, Include: A hardware driver, configured to send a prompt message to the hardware access permission verification module when it obtains a target request sent by a target application, where the target request is used to request to obtain the hardware data of a target hardware, and the prompt message is used to prompt the hardware access permission verification module that the target application requests to obtain the hardware data of the target hardware; The hardware access permission verification module is configured to display an authorization page when it obtains the prompt message, and send the response message to the hardware driver when it obtains the response message determined by the target object according to the authorization page, where the authorization page is used to instruct the target object to determine whether to allow the target application to obtain the hardware data of the target hardware; Wherein, the hardware driver is further configured to send the hardware data of the target hardware to the target application when it determines that the response message is used to instruct that the target application is allowed to obtain the hardware data of the target hardware.
9. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, where the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.
10. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor, when executing the computer program, implements the steps of the method according to any one of claims 1 to 7.