CN113835889A

CN113835889A - Method for acquiring input event and related device

Info

Publication number: CN113835889A
Application number: CN202111121915.4A
Authority: CN
Inventors: 王旭光; 王晓林
Original assignee: Hisense Mobile Communications Technology Co Ltd
Current assignee: Hisense Mobile Communications Technology Co Ltd
Priority date: 2021-09-24
Filing date: 2021-09-24
Publication date: 2021-12-24

Abstract

The application relates to the technical field of terminals, and discloses a method and a related device for acquiring an input event, which are used for solving the problem that the input event cannot be efficiently acquired for application in the prior art. In the method, in view of the security requirement, the application cannot directly access the input node, and two services are provided, one is a local service which is used for acquiring the user input event from the input node. The other is java system service for distributing user input events obtained by the local service to the application. In order to avoid that any application can obtain the user input event, the application in the application needs to perform permission check on the application by the java system service when the java system service is called. Therefore, in the whole framework, the application with the authority can acquire the user input event, and the acquisition path is as follows: local service- > java system service- > application, the path is shortened, and the scene requirement with high time delay requirement can be met.

Description

Method for acquiring input event and related device

Technical Field

The present application relates to the field of terminal technologies, and in particular, to an input event obtaining method and a related device.

Background

Many applications are installed in the android device, and the delay of part of the applications for acquiring the user input events is long. For example, the working architecture of the cloud mobile phone application can be summarized as that a client of the cloud mobile phone application is installed in a mobile phone, the mobile phone obtains an event input by a user, and then sends the event to a cloud application server through the client for execution, and then returns an execution result to the client. That is, the cloud mobile phone application is actually run in the remote server, and the client is only used for interface display.

Then for this type of application, the longer path it takes for the user input event results in a long processing delay. How to efficiently acquire user input events for this type of application becomes an urgent problem to be solved.

Disclosure of Invention

The application aims to provide an input event acquisition method and a related device, and the method and the related device are used for solving the problem of how to efficiently acquire an input event for an application in the prior art.

In a first aspect, the present application provides a method of acquiring an input event, the method comprising:

monitoring an input event driving node;

if the user input event is monitored, sending the user input event to java system service so that the java system service sends the user input event to a target application, wherein the target application is registered in the java system service after being checked for permission in advance.

Optionally, before listening to the input event-driven node, the method further includes:

responding to the calling request of the java system service, and verifying the security label of the java system service;

if the verification is passed, allowing the java system service to call the local service;

and if the verification is not passed, rejecting the calling of the java system service to the local service.

Optionally, the sending the user input event to a java system service includes:

and processing the user input event according to a specified format required by the target application, and then sending the processed user input event to the java system service.

Optionally, the specified format is a format agreed with the target application or a format corresponding to the target application in a plurality of preset formats.

Optionally, the method further includes:

and responding to a stop request sent by the java system service, and stopping monitoring the input event driving node.

In a second aspect, the present application provides a method for acquiring an input event, which is applied to a java system service, and the method includes:

receiving a user input event acquired by a local service from an input event driving node;

and sending the user input event to a target application, wherein the target application is registered in the java system service after being subjected to permission check in advance.

Optionally, registering the target application includes:

responding to the calling of the target application, and acquiring a listener object and permission check parameters of the target application;

performing permission check on the target application based on the permission check parameter;

and if the checking is passed, finishing the registration operation in the java system service based on the listener object.

Optionally, the permission check parameter at least includes at least one of the following parameters: the authority statement to be checked, the name of the application package and the application signature;

the permission check of the target application based on the permission check reference comprises:

if the permission checking parameter comprises the permission statement to be checked, determining whether the permission statement to be checked is a specified permission statement, if so, checking the permission statement to pass, otherwise, checking the permission to fail;

if the permission check parameter comprises the application package name, checking whether the application package name is in a white list, if so, checking the application package name to pass, otherwise, failing to check the permission;

if the application signature is included, checking whether the application signature is in a white list, if so, checking the application signature to pass, otherwise, checking the authority to fail;

and if all the parameters in the permission check parameters pass the authentication, the permission check is successful.

Optionally, the method further includes:

and if at least one target application is registered and each target application exits, sending a stop request to the local service, wherein the stop request is used for stopping obtaining the user input event, and for each target application, determining that the target application exits if the stop request of the target application is received, or determining that the target application exits if abnormal exit indication information of the target application is received.

In a third aspect, the present application provides a method for acquiring an input event, which is applied to an installed target application, and the method includes:

receiving a user input event sent by java system service; the target application is registered in the java system service after permission check in advance;

and executing corresponding operation based on the user input event.

Optionally, registering in the java system service includes:

acquiring a service object of the java system service based on the binding service request;

and generating a listener object, and calling the java system service based on the service object to register the listener object into the java system service.

Optionally, the permission check parameter at least includes at least one of the following parameters: the authority statement to be checked, the name of the application package and the application signature; wherein:

the statement to be verified is used for comparing with an appointed authority statement, and the application package name and the application signature are used for verifying whether the application package name and the application signature are contained in a white list.

Optionally, the method further includes:

and when the java system is normally quitted, calling a stopping interface to send a stopping request to the java system service.

In a fourth aspect, the present application provides a terminal device, comprising:

a display, a processor, and a memory;

the display is used for displaying information;

the memory to store the processor-executable instructions;

the processor is configured to execute the instructions to implement the method of acquiring an input event as described in any of the first to third aspects above.

In a fifth aspect, the present application provides a computer-readable storage medium, wherein instructions, when executed by a terminal device, enable the terminal device to perform the method of acquiring an input event as described in any one of the first to third aspects.

In a sixth aspect, the present application provides a computer program product comprising a computer program which, when executed by a processor, implements a method of acquiring an input event as described in any one of the first to third aspects above.

The technical scheme provided by the embodiment of the application at least has the following beneficial effects:

in the embodiment of the application, a method for acquiring a user input event with low time delay, which can ensure system safety, is provided. In the method provided by the embodiment of the application, in view of the fact that the application cannot directly access the input node due to the security requirement, and the application cannot interact with the local service, the application provides two services, namely the local service, for acquiring the user input event from the input node. The other is java system service for distributing user input events obtained by the local service to the application. In order to avoid that any application can obtain the user input event, the application in the application needs to be subjected to authority check by java system service, so that the resource safety is ensured. Therefore, in the whole framework, the application with the authority can acquire the user input event, and the whole path for acquiring the user input event is as follows: the local service, namely the java system service, is applied, so that the path is shortened, the time delay of the application for acquiring the user input event can be reduced, and the requirements of cloud mobile phone application or other scenes with high time delay requirements are met.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments of the present application will be briefly described below, and it is obvious that the drawings described below are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a diagram illustrating a transmission path of a user input event in the related art;

fig. 2 is a schematic structural diagram of a terminal device according to an embodiment of the present application;

fig. 3 is a block diagram of a software structure of a terminal device according to an embodiment of the present disclosure;

fig. 4 is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 5 is a flowchart illustrating a method for acquiring an input event according to an embodiment of the present application;

FIG. 6 is a block diagram illustrating an architecture for obtaining input events according to an embodiment of the present disclosure;

fig. 7 is a second flowchart illustrating a method for acquiring an input event according to an embodiment of the present application;

fig. 8 is a third schematic flowchart illustrating a method for acquiring an input event according to an embodiment of the present application;

fig. 9 is a fourth flowchart illustrating a method for acquiring an input event according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. The embodiments described are some, but not all embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Also, in the description of the embodiments of the present application, "/" indicates or means, for example, a/B may indicate a or B; "and/or" in the text is only an association relationship describing an associated object, and means that three relationships may exist, for example, a and/or B may mean: three cases of a alone, a and B both, and B alone exist, and in addition, "a plurality" means two or more than two in the description of the embodiments of the present application.

The terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as implying or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first," "second," or "second" may explicitly or implicitly include one or more of that feature, and in the description of embodiments of the application, "a plurality" means two or more unless otherwise indicated.

Taking a cloud mobile phone application as an example, the application acquires the user input event through a callback interface of an Android standard. However, this process is time consuming. As shown in fig. 1, the path for acquiring the user input event is: an input node (input event driven node) - - > input dispatcher (local event distribution service) - - > system _ server (system service) - - > preprocessing and interception judgment- > cloud mobile phone application. And then the cloud mobile phone application transmits the user input event to a remote cloud application server for execution.

Therefore, the way of acquiring the user input event through the callback interface of the Android standard is long in path and time consumption, and the scene requirement on high real-time performance is difficult to meet.

In view of this, in the embodiments of the present application, a method for acquiring a user input event with low delay is provided, which can ensure system security. In the method provided by the embodiment of the application, in view of the fact that the application cannot directly access the input node due to the safety requirement, and the application cannot interact with the local service, the application provides two services, one is the local service, the local service belongs to the bottom layer service, the access of the local service to the input node is allowed in the android architecture, and therefore the local service is used for acquiring the user input event from the input node. Due to security requirements, the application cannot directly access the local service, so the application also provides java system service for distributing the user input event acquired by the local service to the application. In order to avoid that any application can obtain the user input event, the application needs to be subjected to authority check by java system service in the application. Therefore, in the whole framework, the application with the authority can acquire the user input event, and the whole path for acquiring the user input event is as follows: local service- > java system service- > application. The visible path is shortened, the delay of the application for acquiring the user input event can be reduced, and the requirements of cloud mobile phone application or other scenes with high requirements on the delay are met.

After the inventive concept of the present application is introduced, the terminal device provided in the present application will be described below. Fig. 2 shows a schematic structural diagram of a terminal device 200. It should be understood that the terminal apparatus 200 shown in fig. 2 is only an example, and the terminal apparatus 200 may have more or less components than those shown in fig. 2, may combine two or more components, or may have a different component configuration. The various components shown in fig. 2 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

A block diagram of a hardware configuration of a terminal device 200 according to an exemplary embodiment is exemplarily shown in fig. 2. As shown in fig. 2, the terminal device 200 includes: a Radio Frequency (RF) circuit 210, a memory 220, a display unit 230, a camera 240, a sensor 250, an audio circuit 260, a Wireless Fidelity (Wi-Fi) module 270, a processor 280, a bluetooth module 281, and a power supply 290.

The RF circuit 210 may be used for receiving and transmitting signals during information transmission and reception or during a call, and may receive downlink data of a base station and then send the downlink data to the processor 280 for processing; the uplink data may be transmitted to the base station. Typically, the RF circuitry includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like.

Memory 220 may be used to store software programs and data. The processor 280 performs various functions of the terminal device 200 and data processing by executing software programs or data stored in the memory 220. The memory 220 may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. The memory 220 stores an operating system that enables the terminal device 200 to operate. The memory 220 may store an operating system and various application programs, and may also store program codes for performing the methods described in the embodiments of the present application.

The display unit 230 may be used to receive input numeric or character information, generate signal input related to user settings and function control of the terminal apparatus 200, and particularly, the display unit 230 may include a touch screen 231 disposed on the front surface of the terminal apparatus 200, and may collect touch operations of a user thereon or nearby, such as clicking a button, dragging a scroll box, and the like.

The display unit 230 may also be used to display information input by the user or information provided to the user and a Graphical User Interface (GUI) of various menus of the terminal apparatus 200. Specifically, the display unit 230 may include a display screen 232 disposed on the front surface of the terminal device 200. The display screen 232 may be configured in the form of a liquid crystal display, a light emitting diode, or the like.

The touch screen 231 may be covered on the display screen 232, or the touch screen 231 and the display screen 232 may be integrated to implement the input and output functions of the terminal device 200, and after the integration, the touch screen may be referred to as a touch display screen for short. The display unit 230 in this application can display the application programs and the corresponding operation steps.

The camera 240 may be used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing elements convert the light signals into electrical signals which are then passed to a processor 280 for conversion into digital image signals.

The terminal device 200 may further comprise at least one sensor 250, such as an acceleration sensor 251, a distance sensor 252, a fingerprint sensor 253, a temperature sensor 254. The terminal device 200 may also be configured with other sensors such as a gyroscope, barometer, hygrometer, thermometer, infrared sensor, light sensor, motion sensor, and the like.

The audio circuitry 260, speaker 261, and microphone 262 may provide an audio interface between the user and the terminal device 200. The audio circuit 260 may transmit the electrical signal converted from the received audio data to the speaker 261, and convert the electrical signal into a sound signal by the speaker 261 and output the sound signal. The terminal device 200 may be further provided with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 262 converts the collected sound signal into an electrical signal, converts the electrical signal into audio data after being received by the audio circuit 260, and then outputs the audio data to the RF circuit 210 to be transmitted to, for example, another terminal device, or outputs the audio data to the memory 220 for further processing.

Wi-Fi belongs to a short-distance wireless transmission technology, and the terminal device 200 can help a user to send and receive e-mails, browse webpages, access streaming media and the like through the Wi-Fi module 270, and provides wireless broadband internet access for the user.

The processor 280 is a control center of the terminal device 200, connects various parts of the entire terminal device using various interfaces and lines, and performs various functions of the terminal device 200 and processes data by running or executing software programs stored in the memory 220 and calling data stored in the memory 220. In some embodiments, processor 280 may include one or more processing units; the processor 280 may also integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a baseband processor, which primarily handles wireless communications. It will be appreciated that the baseband processor described above may not be integrated into the processor 280. The processor 280 may run an operating system, an application program, a user interface display, a touch response, and a method for acquiring an input event according to the embodiments of the present application. Further, the processor 280 is coupled with the display unit 230.

And the bluetooth module 281 is used for performing information interaction with other bluetooth devices having the bluetooth module through a bluetooth protocol. For example, the terminal device 200 may establish a bluetooth connection with a wearable electronic device (e.g., a smart watch) having a bluetooth module through the bluetooth module 281, so as to perform data interaction.

Terminal device 200 also includes a power supply 290 (such as a battery) for powering the various components. The power supply may be logically coupled to the processor 280 through a power management system to manage charging, discharging, and power consumption through the power management system. The terminal device 200 may further be configured with a power button for powering on and off the terminal device, and locking the screen.

Fig. 3 is a block diagram of a software configuration of the terminal device 200 according to the embodiment of the present application.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system may be divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer, from top to bottom, respectively.

The application layer may include a series of application packages.

As shown in fig. 3, the application package may include applications such as camera, gallery, calendar, phone call, map, navigation, WLAN, bluetooth, music, video, short message, etc. In the embodiment of the application, the cloud mobile phone application runs on an application program layer.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 3, the application framework layers may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, dialed and answered calls, browsing history and bookmarks, phone books, short messages, etc.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying a picture.

The phone manager is used to provide a communication function of the terminal apparatus 200. Such as management of call status (including on, off, etc.).

The resource manager provides various resources, such as localized strings, icons, pictures, layout files, video files, etc., to the application.

The notification manager allows the application to display notification information (e.g., message digest of short message, message content) in the status bar, can be used to convey notification-type messages, and can automatically disappear after a short dwell without user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, text information is prompted in the status bar, a prompt tone is given, the terminal device vibrates, an indicator light flickers, and the like.

In the embodiment of the application, java system service runs in an application framework layer.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), Media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

A 2D (an animation mode) graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

In the embodiment of the application, the local service runs in HAL (Hardware abstraction Layer). The HAL layer is a hardware interface layer abstracted from a concrete hardware platform, and the interface layer is responsible for realizing the functions and control of the concrete hardware platform and providing a uniform API interface for other software modules. The HAL layer is created to abstract the commonality of hardware operation and control, and to provide a unified control interface to upper layer software to isolate other software modules from the underlying hardware.

The terminal device 200 in the embodiment of the present application may be an electronic device including, but not limited to, a mobile phone, a mobile terminal, a desktop computer, a mobile computer, a tablet computer, a household sign data acquisition device (such as a blood pressure monitor), a television, and the like, which is equipped with an android system.

Some brief descriptions are given below to application scenarios to which the technical solution of the embodiment of the present application can be applied, and it should be noted that the application scenarios described below are only used for describing the embodiment of the present application and are not limited. In specific implementation, the technical scheme provided by the embodiment of the application can be flexibly applied according to actual needs.

Fig. 4 is a schematic diagram illustrating an application scenario provided by an embodiment of the present application. The application scene graph comprises the following steps: a user, a cloud handset application 401, and a server 402. Wherein:

the user clicks a first button input node of the cloud mobile phone application to capture a user input event aiming at the button, the user input event is sequentially notified to the cloud mobile phone application 401 through the local service A, java system service B, then the cloud mobile phone application 401 sends the user input event to the remote server 402 to execute corresponding operation, and an operation result is returned to the cloud mobile phone application 401 through the network.

Of course, the method provided by the embodiment of the present application is not limited to the application scenario shown in fig. 4, and may also be used in other possible application scenarios, for example, an application scenario with a high requirement on the delay of the user input event.

To further illustrate the technical solutions provided by the embodiments of the present application, the following detailed description is made with reference to the accompanying drawings and the detailed description. The method comprises the following steps: 1. configuring system operation authority for the local service A and the java system service B; 2. registering the target application to java system service; 3. acquiring a user input event for a target application; 4. and (5) processing after the target application exits.

1. Configuring system operation authority for local service A and java system service B

In the embodiment of the application, in order to ensure system safety and ensure that the local service a and the java system service B can distribute the user input event to the target application, the target application a needs to have an access right to an input node, and the target application a and the java system service B are ensured to perform corresponding operations on the system within a certain authority range, which can ensure system safety.

If the system resources are read and changed through processes, in order to ensure the security of the system resources, the traditional Linux limits the access of the resources through the concepts of users and file permissions. The security of system resources is ensured by comparing the initiating user of the process with the file authority. This is a free Access Control (DAC); however, as the security requirements of system resources increase, a security enforcement mechanism (SELinux) under Linux appears, which adds more restrictions besides rights to processes and files to enhance access conditions, such as Mandatory Access Control (MAC). The most intuitive comparison between the two methods is that by using the traditional DAC, the root (flash) can access any file, and under the MAC, the root can only access the file which is set to be allowed.

The security mechanism of the operating system is actually to limit two things: processes and system resources (e.g., files, network sockets, system calls, etc.). The Linux operating system limits system resources through the concept of users and groups, and each process needs one user to execute. Two basic concepts are defined for process and system resources among SELinux: domain (domin) and context (context). In SELinux, which domains can access which contexts are controlled by defining policies. The policy limits the operation that the security domain can perform on the context, and the access operation not defined in the policy is rejected. Therefore, the local service A and the java system service B can be respectively endowed with the authority to the system resources under the MAC based on actual conditions.

In the embodiment of the present application, the local service a may be given a specific security domain according to a specific rule. The operations that the local service a is able to perform are thus confined to the policies defined in the security domain. For example, as shown in table 1, it should be noted that the security tag can be customized, and the application is not limited thereto:

TABLE 1

Service	Security tag
		Java system service	u:object_r:inputcapture_service:s0
Local service	u:r:hal_inputcapture_default:s0

In Table 1, it is illustrated that the security label of the local service A is configured as u: r: hal _ input security _ default: s0, wherein the security indicates the user role (u: r:), the security domain name (hal _ input security _ default), and the security level (s 0).

Similarly, the security tag of the java system service is configured as u: object _ r: input _ service _ s 0. Wherein the security also indicates the user role (u: object _ r), security domain name (inputsecurity _ service), and security level (s 0).

2. Registering a target application with a java system service

To protect system resources, the target application is registered with the java system service to be distributed to the user input events. In one possible implementation, a standard aidl interface and manner of application binding services may be provided. The target application binds the java system service and registers the listener, and the input event can be continuously received. As shown in fig. 5, the registration process may be implemented as:

in step 501, the target application acquires a service object of java system service based on the binding service request.

When the method is implemented, the system provides a binding service interface, the target application can send a binding server request to the system through the binding service interface, and the request is used for acquiring a service object of java system service so as to bind the target application and the java system service and enable the target application and the java system service to communicate.

After the target application acquires the service object of the java system service, a start function can be adopted to transfer the listener object of the target application as a parameter of the start function to the java system service, so that the java system service returns a user input event through the listener object.

In implementation, in order to protect system resources, permission check can be performed on the target application to prevent the application from illegally calling java system service B. The permission check is passed before the user can register with the java system service so as to acquire the user input event.

It may be implemented in step 502 that the target application generates a listener object and invokes the java system service based on the service object.

To capture user input events, the target application needs to implement a listener interface in order to receive the user input events through the listener. The target application, when implemented, may pass the listener object to the java system service by calling a start function to facilitate registration of the listener object into the java system service.

In step 503, the java system service obtains the listener object and the permission check parameter of the target application for permission check in response to the invocation of the target application.

For example, the permission check parameter may include at least one of the following parameters: the authority statement to be checked, the application package name and the application signature. If all the parameters in the permission check parameters pass the authentication during the permission check, the permission check is successful, and the following schemes 1) to 3) can be implemented for each permission check parameter:

1) if the permission checking parameters comprise the permission statement to be checked, the java system service determines whether the permission statement to be checked is the specified permission statement, if so, the permission statement check is passed, otherwise, the permission check is failed.

For example, in one possible embodiment, the developer can write the rights statement to be checked into the running program of the target application. In an exemplary embodiment, the right declaration to be verified may be:

″＊＊＊＊.intent.action.INPUT_CAPTURE″。

of course, in specific implementation, the right declaration to be verified can be set according to actual requirements, and both are applicable to the embodiment of the present application.

2) If the permission check parameter comprises the application package name, the java system service checks whether the application package name is in the white list, if so, the application package name check is passed, otherwise, the permission check is failed.

3) If the permission check parameter comprises the application signature, the java system service verifies whether the application signature is in the white list, if so, the application signature check passes, otherwise, the permission check fails.

In implementation, the white list for verifying the application package name and the application signature may be the same white list table, for example, the white list table includes two contents of the application package name and the application signature, or both the two white list tables are applicable to the embodiment of the present application. The white list is a file, contains a plurality of hash value character strings of application signatures and/or application package names, can be manually generated by a developer, and is built in a read-only partition of a system of the terminal device.

In step 504, the java system service returns the permission check result to the target application, and when the permission check passes, the listener object of the target application is saved, and the registration is completed.

For example, if the permission check passes, a message that the check passes is returned to the target application, and if the check fails, a message that the check fails is returned to the target application.

In step 505, the target application receives the registration result of the java system service, and waits to acquire the user input event if the registration is successful.

After the registration is completed, if the java system service B does not request the local service a to obtain the user input event for itself, in step 506, the java system service sends a call request to the local service a through an interface with the local service.

In step 507, the local service creates a user input event acquisition thread to listen to the input node based on the call request.

It should be noted that, when there are multiple applications registered in the java system service, if an input node is already created, there is no need to repeatedly send a call request to the local service, and as shown in fig. 6, multiple registered applications may share one input event obtaining thread.

In some embodiments, in order to protect system resources from illegally invoking the local service, the local service may verify the java system service based on the invocation request, and allow the invocation of the local service by the java system service if the verification is passed, otherwise prohibit the invocation.

In some possible embodiments, the invocation request may also include a security label of the java system service (u: object _ r: input _ service: s0, as described above). The local service checks the java system service based on the security label in the invocation request. The local service ensures that the calling is allowed only when the security label of the java system service is u: object _ r: inputflowchart _ service: s0, otherwise, the java system service may be illegal and is prohibited from calling the local service.

3. Obtaining user input events for a target application

The local service is configured with the right to access the input node, and can acquire the user input event by monitoring the input node and then distribute the user input event to the java system service, and distribute the user input event to the registered target application through the java system service. In implementation, the local service is automatically started at the time of starting up, then waits to be called by the java system service, and once called, as shown in fig. 7, the following steps can be implemented:

in step 701, the local service listens to the input node.

After the local service is called by the java system service, a user input event capturing thread is started, the state of an input node is monitored in the thread, and when the input node generates a user input event, the user input event is immediately read.

In implementation, the input nodes may include two types of nodes, one type is an input node corresponding to a touch operation, and the other type is an input node corresponding to a mechanical key operation.

In step 702, if the local service monitors the user input event, the local service sends the user input event to the java system service.

In some embodiments, the local service may further process, according to the requirement of the target application, the user input event according to a specified format corresponding to the target application, and then send the processed user input event to the java system service. Therefore, the target application receives the user input event in the format required by the target application, and the target application can analyze and process the user input event conveniently.

In practice, at least one format may be preset for the local service and then the desired format may be specified by the target application. In one possible embodiment, when the target application is registered with the java system service, the required format identification is notified to the local service via the java system service, so that the local service knows the format required by the target application. When there are multiple target applications, the format required by each target application may be the same or different. The local service can process the user input event into an event with a format required by the target application according to the requirements of different target applications, and distributes the event to the java local service, and then the java local service distributes the user input event to the corresponding target application.

In the embodiment of the application, the formatting operation can also be completed by the java system service. In contrast, the local service can complete the formatting operation to reduce the access operation of the Java system service, and the local service can format the Java system service to reduce the time delay.

In another possible embodiment, the local service may not preset a format conversion method for the user input event. But by the target application negotiating the required format requirements via the java system service and the local service contract. Thus, after an appointment, the local service may process the user input event according to the agreed format.

Therefore, in any way, after the local service analyzes and converts the format of the user event, the format conversion is performed according to the requirement of the target application, so that the user input event after the format conversion can meet the secondary analysis requirement of the target application.

In implementation, the local service can distribute the user input event to the java system service in a callback mode.

In step 703, the java system service sends the user input event to the target application.

In implementation, the java system service may distribute user input events to the target application based on the listener object registered by the target application.

That is, the java system service may send the user input event to the target application through the callback listener object.

In step 704, after the target application receives the user input event, a corresponding operation is performed based on the user input event.

For example, the cloud mobile phone application sends the user input event to a remote server for processing and obtains a processing result returned by the server.

In summary, the embodiment provides a set of architecture for acquiring and distributing input events, which not only meets the requirement of system security, but also shortens the transmission path of the input events of the user to reduce the time delay.

4. And (5) processing after the target application exits.

The target application exit may include both a normal exit and an abnormal exit.

In any case, the message that the target application exits is sensed by the java system service so as to execute the corresponding operation to save the processing resource. As shown in fig. 8:

in step 801, after the target application exits normally, the java system service may be notified. As one possible implementation, the java system service may provide a stop interface. The target application can send a stop request to the java system service by calling the stop interface so that the java system service can obtain that the target application exits. When the exception is caused by the target application, the target application cannot inform the java system service. In this embodiment of the present application, the system may feed back the abnormal exit indication information corresponding to the target to the java system service.

In one possible implementation, the java system service may register the exception callback interface of the target application with the system when the registration of the target application is completed. For example, when the target application crashes abnormally, the process of the target application is destroyed, and the system will process information related to the process. For example, the system notifies the java system service of the death message of the listener object of the target application through the exception callback interface. Based on the message, the java system service can know that the target application exits abnormally.

In order to save system resources, in step 802, after the java system service knows that the target application exits, the registration information of the target application may be cancelled, such as deleting the listener object registered by the target application.

In other embodiments, if multiple target applications are registered, then after all target applications are logged off, a stop request may be sent by the java system service to the local service in step 803.

In implementation, the local service may provide a stop interface to the java system service, and the java system service may notify the local service to stop acquiring the user input event by calling the stop interface.

In step 804, the local service stops capturing user input events based on the stop request of the java system service to save processing resources. For example, the local service may release a memory resource for storing the user input event acquired by the local service.

To facilitate systematic understanding of the embodiments of the present application, an architecture of the embodiments of the present application is summarized below with reference to fig. 9 by taking a cloud mobile application as an example. As shown in fig. 9:

in step 901, the cloud mobile phone application sends a binding request for java system services to the system.

In step 902, the Android system returns a service object of the java system service.

In step 903, the cloud mobile phone application calls a start function to call java system service, and after the java system service performs permission check on the cloud mobile phone application, if the permission check passes, registration of a listener object of the cloud mobile phone application is completed.

In step 904, the java system service calls the initiation function to notify the local service to capture the user input event.

In step 905, after the local service authenticates the java system service, the user input event capture thread is started in response to the invocation request.

In step 906, the local service facilitates obtaining the user input event by listening to the input node.

In step 907, after the user input event is generated, the local service reads the original data of the user input event from the input node.

In step 908, the native service formats raw data for the user input event as required by the target application.

The local service then passes to the java system service via the callback user input event in step 909.

In step 910, the java system service distributes the user input event to the target application via a callback.

In summary, in the embodiment of the application, the input node is accessed through the local service, the requirement on system security is met, the user input event is distributed to the registered target application through the java system service as a medium, system resources can be further protected, the transmission path of the user input event is shortened, the delay of the user input event is reduced, and application scenarios such as cloud mobile phone application and the like with high requirements on the delay of the user input event can be met.

The embodiments provided in the present application are only a few examples of the general concept of the present application, and do not limit the scope of the present application. Any other embodiments extended according to the scheme of the present application without inventive efforts will be within the scope of protection of the present application for a person skilled in the art.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. A method for obtaining an input event, applied to a local service, the method comprising:

monitoring an input event driving node;

2. The method of claim 1, wherein prior to listening for an input event driven node, the method further comprises:

3. The method of claim 1 or 2, wherein sending the user input event to a java system service comprises:

4. A method for acquiring an input event, which is applied to java system service, the method comprises the following steps:

5. The method of claim 4, wherein registering the target application comprises:

6. The method of claim 5, wherein the permission check parameters include at least one of the following parameters: the authority statement to be checked, the name of the application package and the application signature;

the permission check of the target application based on the permission check parameter comprises:

7. The method according to any one of claims 4-6, further comprising:

8. A method of obtaining an input event, applied to an installed target application, the method comprising:

and executing corresponding operation based on the user input event.

9. The method as claimed in claim 8, wherein registering with the java system service comprises:

10. A terminal device, comprising:

a display, a processor, and a memory;

the display is used for displaying information;

the memory to store the processor-executable instructions;

the processor is configured to execute the instructions to implement the method of acquiring an input event of any of claims 1-9.