Proxy method of system service, terminal device and computer readable medium

Abstract

The application relates to the computer technical field, in particular to a proxy method of system service, a terminal device and a computer readable medium. When it is detected that part of functions in the on-demand start-stop system service meets a loading condition, the method can proxy and execute the part of functions through a system service manager in the case that it is determined that the part of functions meets a proxy execution condition, so as to respond to a listening event corresponding to the detected part of functions which triggers the loading of the part of functions. In this way, the system service manager in the system can be used to proxy and execute some frequently called functions in the on-demand start-stop system service, thereby avoiding the problem that the on-demand start-stop system service is frequently triggered to load / unload the corresponding process.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a system service proxy method, terminal device, and computer-readable medium. Background Technology

[0002] A terminal device can only be used by a user if an operating system is installed. Taking a mobile phone as an example, a mobile phone's operating system could be, for instance, Apple's. TM Operating systems (iPhone operating system, iOS), Android TM (Android) operating system, open-source HarmonyOS TM (Open Harmony, OH) system and HarmonyOS TM Operating system (Harmony) TM Operating systems (OS), etc. The operating systems in the examples above all have a large number of system abilities (SAs), resulting in a large number of system service processes or threads running within them. The execution of these processes or threads consumes varying degrees of the operating system's memory resources.

[0003] System services in current operating systems can be divided into resident services and on-demand start / stop services. Resident services can run permanently in the operating system, while on-demand start / stop services start or stop when certain triggering conditions are met.

[0004] However, some on-demand start / stop services are easily triggered by conditions that allow them to start or stop, leading to frequent loading / unloading by the operating system. This results in wasted memory resources and increased power consumption on the terminal device. Summary of the Invention

[0005] This application provides a system service proxy method, terminal device, and computer-readable medium, which can utilize resident processes in the system to proxy the execution of some frequently called functions in the corresponding system service process, thereby avoiding the problem of frequently triggering the loading / unloading of corresponding processes for some system services that are started and stopped on demand.

[0006] Specifically, in a first aspect, the present application provides a method for proxying a system service, applied to a terminal device, the method comprising: detecting a listening event, determining that a first loading condition of a first function of a first system service is satisfied; determining that the first function of the first system service satisfies a proxy execution condition; wherein the proxy execution condition comprises that the first system service registers a proxy execution service with a system service manager; determining, by the system service manager, a first loadable file corresponding to the first function; wherein the first loadable file is different from a second loadable file corresponding to the first system service; proxying, by the system service manager, the first function; wherein the system service manager is configured to manage system services.

[0007] For example, the first system service described above is an on-demand start-stop system service, and the first function described above can be a partial function of the on-demand start-stop system service. The method for proxying a system service provided by the first aspect described above, i.e., when detecting that a partial function of an on-demand start-stop system service satisfies a loading condition, the proxy execution of the partial function by the system service manager can be performed in response to the listening event corresponding to the detected partial function triggering the loading of the partial function. It can be understood that the first function of the first system service described above can be a frequently called function in the service, such as a query function provided by an upgrade service. The loadable file corresponding to the first function can be different from the loadable file corresponding to the upgrade service, such as a shared library (so) file corresponding to the program code in the loadable file of the upgrade service for describing the query function, which is compiled during the system development stage. The proxy execution condition corresponding to the first function described above, i.e., the first system service providing the first function, is pre-registered in the system service manager as a proxy execution service.

[0008] In addition, the proxy execution condition corresponding to the first function described above, i.e., the first system service providing the first function, is pre-registered in the system service manager as a proxy execution service, such as an upgrade proxy service pre-registered in the system service manager by the upgrade service. Therefore, the process of proxying the first function by the system service manager described above, such as the process of loading the first loadable file and proxying the loadable file to proxy the query function of the upgrade service by the upgrade proxy service pre-registered in the system service manager by the upgrade service. The terminal device described above can be an electronic device such as a mobile phone, without limitation.

[0009] In some implementations of the first aspect, the first loadable file and the second loadable file can be files in the same format, but the contents of the two loadable files are different. For example, the first loadable file can be smaller than the second loadable file. The second loadable file can further include the first loadable file.

[0010] In some implementations of the first aspect, the first loadable file and the second loadable file can be in different formats. For the first loadable file of the system service, the format can be an apk format of Android, or a hap format of Harmony, or an exe format of Windows, or an so format, etc. For the second loadable file of the first function, the format can also be one of the above-mentioned formats or other formats.

[0011] In a possible implementation of the above-mentioned first aspect, the above-mentioned detecting the listening event, determining that the first loading condition of the first function of the first system service is satisfied, comprises: obtaining, based on a first configuration file of the first system service, a first loading condition corresponding to the first function of the first system service; the first configuration file comprises loading condition configuration information corresponding to the first system service. Setting a first listener corresponding to the first loading condition, the first listener is used to listen to the listening event capable of making the first loading condition satisfied; detecting the listening event reported by the first listener, determining that the first loading condition of the first function of the first system service is satisfied.

[0012] The above-mentioned first configuration file can be, for example, a system service configuration file, referred to as an SA configuration file. The SA configuration file can preset loading condition configuration information corresponding to different functions of one or more system services. For example, the SA configuration file can include loading condition configuration information preset for a query function in an upgrade service. The configuration information can configure, for example, a loading condition of the query function as a timing trigger condition. Correspondingly, the terminal device can set, based on the configuration information, a listener for listening to a corresponding trigger event when the corresponding timing trigger condition is satisfied. Further, the terminal device can trigger, when the trigger event is listened to, i.e., the listening event is detected, a corresponding process of executing the query function of the upgrade service through the system service manager agent. Details are not described herein.

[0013] In a possible implementation of the above-mentioned first aspect, the listening event comprises any one of the following: a system attribute change event, a timer event, a device networking event, a public event, and a client query event of a second system service; wherein the second system service is a service running on the terminal device or a service running on a peer device in communication connection with the terminal device.

[0014] For example, the above-mentioned client query event can include a query event initiated by a local client and a remote client. The local client can include a client of another system service running on the terminal device itself. The remote client can include a system service client running in an operating system of another terminal device, i.e., a client of a system service running on a peer device in communication connection with the terminal device.

[0015] In a possible implementation of the first aspect, the proxy execution service is a service registered by the first system service to the system service manager for proxy execution of the first function of the first system service, and the determining that the first function of the first system service meets the proxy execution condition comprises: detecting that the second configuration file of the system service manager includes configuration information corresponding to the proxy execution service, and determining that the first function of the first system service meets the proxy execution condition.

[0016] For example, the second configuration file is a preset service proxy configuration file in the system service manager, which can be used to record system service information about decoupling some functions to the system service manager for proxy execution. The system service manager can create a proxy execution service for a corresponding system service based on the system service information recorded in the configuration file, for example, create an upgrade proxy service for an upgrade service.

[0017] In a possible implementation of the first aspect, the determining, by the system service manager, the first loadable file corresponding to the first function comprises: obtaining, by the proxy execution service, an access path of the first loadable file corresponding to the first function provided by the first system service; and determining the first loadable file corresponding to the first function based on the access path.

[0018] In a possible implementation of the first aspect, the proxy execution, by the system service manager, of the first function comprises: loading the first loadable file to a first process in which the system service manager or the proxy execution service is located based on the access path, and proxy executing the first function.

[0019] In a possible implementation of the first aspect, the first loadable file is loaded in the form of a dynamic link library file, and the loading, based on the access path, of the first loadable file to the first process in which the system service manager or the proxy execution service is located comprises: accessing, based on the access path, a dynamic link library of the system to load the first loadable file to an address space corresponding to the first process.

[0020] It can be understood that the first process can be a process in which a system service manager is located, for example, and the process can be a resident process running in the system, and the process can load the first loadable file corresponding to the first function and proxy execution in the process of running the proxy execution service. At this time, the proxy execution service can run in a sub-process or thread of the process in which the system service manager is located, and can be resident or can be started and stopped on demand. In some other embodiments, the sub-process in which the proxy execution service runs can be a resident process, and the first process is, for example, a process in which the proxy execution service runs. The process can load the first loadable file and proxy execution in the running process. This will not be repeated here.

[0021] In a possible implementation of the first aspect, the terminal device includes a second loadable file corresponding to the first system service, and the program code corresponding to the execution of the first loadable file is part of the program code corresponding to the execution of the second loadable file. For example, the function program code corresponding to the execution of the loadable file corresponding to the query function of the upgrade service can be part of the service program code corresponding to the implementation of the upgrade service in the loadable file.

[0022] In a possible implementation of the first aspect, the first loadable file and the second loadable file include shared library (so) files. In some other embodiments, the first loadable file and the second loadable file can also be in the form of other loadable files other than so files, which are not limited here.

[0023] In a possible implementation of the first aspect, the method includes determining that the first function of the first system service does not meet the proxy execution condition, loading a second process corresponding to the first system service, and the second process is used to execute the first function.

[0024] In a possible implementation of the first aspect, the method includes loading a second process corresponding to the first system service according to the result of the failure of the system service manager to proxy execute the first function, and the second process is used to execute the first function.

[0025] In a possible implementation of the first aspect, the system service manager fails to proxy execute the first function, including any of the following cases: the proxy execution service in the system service manager cannot load the first loadable file corresponding to the first function; the first process in which the system service manager or the proxy execution service is located cannot execute the first loadable file.

[0026] In a possible implementation of the first aspect, the method comprises: determining that the system service manager agent performs the first function successfully, and determining that a second function of a first system service meets a second loading condition, wherein the second loading condition comprises that the second function is a function associated with the first function and performed after the first function is performed completely; and loading a second process corresponding to the first system service to perform the second function.

[0027] For example, the agent execution result of the system service manager on the first function can comprise the following execution results: I. agent execution fails; II. agent execution succeeds and a corresponding system service needs to be loaded to perform the next step; III. agent execution succeeds and the next step does not need to be performed. The agent execution results corresponding to the cases I and II can correspond to a judgment result that a system service process needs to be loaded continuously. Agent execution failure in the case I can include a case that a loadable file corresponding to the function cannot be loaded or a case that the loadable file corresponding to the function cannot be executed, for example, a case that part of code fields in the first loadable file are lost, which can cause the loadable file to fail to be loaded or executed, and the like. The present application is not limited in this regard.

[0028] In the second aspect, the present application provides a terminal device, comprising: one or more processors; one or more memories; the one or more memories store one or more programs, when the one or more programs are executed by the one or more processors, the terminal device performs the agent method of the system service provided in the first aspect and the various possible implementations of the first aspect.

[0029] In the third aspect, the present application provides a computer readable medium, the readable medium stores instructions, when the instructions are executed on a computer, the computer executes the agent method of the system service provided in the first aspect and the various possible implementations of the first aspect.

[0030] In the fourth aspect, the present application provides a program product, when the program product is executed on an electronic device, the electronic device implements the agent method of the system service provided in the first aspect and any possible implementation of the first aspect.

[0031] The advantages of the second aspect to the fourth aspect can refer to the related descriptions of the first aspect and the various possible implementations of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 Fig. 1 shows a framework structure diagram of a system service on-demand start-stop management system.

[0033] Figure 2aFig. 1 shows a structure of a system service manager and a principle diagram of managing on-demand start-stop system services according to an embodiment of the present application.

[0034] Figure 2b Fig. 2 shows a structure of a service agent module and a principle diagram of proxying / distributing a listening event according to an embodiment of the present application.

[0035] Figure 3 Fig. 3 shows an interaction implementation flow diagram of a proxy method of a system service according to an embodiment of the present application.

[0036] Figure 4 Fig. 4 shows a scene diagram of prompting upgrade based on query function according to an embodiment of the present application.

[0037] Figure 5 Fig. 5 shows a scene diagram of prompting upgrade based on query function according to an embodiment of the present application. Figure 4 Fig. 6 shows an implementation flow diagram of a proxy method of a system service according to an embodiment of the present application.

[0038] Figure 6 Fig. 7 shows a distributed device networking scene diagram according to an embodiment of the present application.

[0039] Figure 7 Fig. 8 shows a distributed device networking scene diagram according to an embodiment of the present application. Figure 6 Fig. 9 shows an implementation flow diagram of a proxy method of a system service according to an embodiment of the present application.

[0040] Figure 8 Fig. 10 shows a structure diagram of a terminal device according to an embodiment of the present application.

[0041] Figure 9 Fig. 11 shows a software system architecture diagram of a terminal device according to an embodiment of the present application. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0043] Figure 1 Fig. 1 shows a structure of a system service manager and a principle diagram of managing on-demand start-stop system services according to an embodiment of the present application.

[0044] Fig. 2 shows a structure of a service agent module and a principle diagram of proxying / distributing a listening event according to an embodiment of the present application. Figure 1As shown, in the operating system installed in a terminal device such as a mobile phone, some on-demand start-stop system services, i.e., the on-demand start-stop services described above, can be managed by a system service manager (SAMGR). The system service manager can implement loading / unloading management of the on-demand start-stop services through a service start framework, a service module, a process management module, and a SA configuration file. The on-demand start-stop services correspond to a manner of triggering start / stop running, which can include a system event trigger and a client query trigger.

[0045] Specifically, the management process can include the following steps:

[0046] 101: Analyzing loading conditions. The system service manager can analyze loading conditions from a system service configuration file through a service start framework, and the loading conditions can be pre-configured for each on-demand start-stop system service.

[0047] 102: Listening to loading conditions. The SAMGR can register a listener to the system through the service start framework to listen to whether the loading conditions corresponding to each system service are met.

[0048] 103: System event trigger or client query trigger. When the listener registered by the service start framework listens to the corresponding loading conditions, the listener can report a corresponding trigger event to the service start framework, and the trigger event can include a system event and a client query event.

[0049] 104: Initiating a loading request. The service start framework of the SAMGR can call an interface provided by the service management based on the listening event trigger to initiate a loading request to request the system service process to provide a function capable of responding to the listening event.

[0050] 105: Starting running. After the system service process starts running, the system service process can provide a handle to the service management module of the SAMGR as calling information. The service module can cross-process call the system service to provide a corresponding function to respond to the listening event based on the calling information.

[0051] For example, a timer event in a system event can trigger the upgrade service process to provide a query function to query the server whether there is an updated upgrade data package. For another example, a device networking event in a system event or a corresponding triggered task can be to use the information management function of the device profile (DP) service to obtain device information and verification information required for networking, etc. After the loaded system service process completes the corresponding task and enters an idle state, the SAMGR can unload the corresponding system service process through the service module and the process management module to release the memory, computing, and other resources occupied by the process. In this way, the number of resident processes in the system can be reduced to a certain extent, the memory occupation can be reduced, and the system energy efficiency can be improved.

[0052] However, when the loading conditions of some on-demand start-stop services are easily met, for example, the timer condition for triggering the loading of the "upgrade service" can be set to query the upgrade data package once a day or every N hours, and for another example, in some smart home environments, a large number of smart devices can frequently trigger device networking, etc. At this time, the service start framework listens to the listeners registered by the system service loading conditions, and then the timer or device networking system events are frequently listened to. Correspondingly, the service module in the system service manager frequently initiates a loading request to the process management module to request the system to load and run the corresponding system service process through the process management module. The system is also frequently in the process of loading and running the system service such as the upgrade service and the device management service, and frequently unloading the idle system service process.

[0053] As described above, some on-demand start-stop services are triggered to start or stop running due to the fact that the trigger conditions for triggering the start or stop are easily met, which causes these on-demand start-stop services to be frequently loaded / unloaded by the operating system, and further causes the waste of memory resources of the operating system and the increase of energy consumption.

[0054] To solve the above problems, the embodiments of the present application provide a proxy method of a system service. Specifically, the method can determine frequently called functions in frequently loaded on-demand start-stop services, and decouple the program codes corresponding to the functions from the corresponding on-demand start-stop services, and execute the functions by a designated resident process in the system. Wherein, the frequently called functions in the on-demand start-stop services can correspond to the generation of independent loadable files, such as shared object files or other forms of loadable files.

[0055] In some examples, the loadable file can be loaded and executed by the above-mentioned specified resident process when a condition for triggering loading of a system service to which the corresponding function belongs is met. The resident process can be, for example, a process in which a resident service such as a system service manager is located. In this way, the resident process in the system can proxy the system service process to execute some frequently called functions, thereby avoiding the problem that some on-demand start-stop system services are frequently triggered to load / unload the corresponding process. In this way, it is also beneficial to reduce the waste of memory resources and the increase of energy consumption of the terminal device, and to improve the use performance of the terminal device.

[0056] In some examples, for the loadable file decoupled from the on-demand start-stop service in the embodiments of the present application, the system service manager can be relied on. When the loadable file is loaded into the system service manager, the system service manager can implement the corresponding function based on the loadable file.

[0057] In other examples, from the perspective of the file system, the loadable file and the corresponding on-demand start-stop service can be two different and independent files, and can be loaded into a process or a thread respectively. It should be understood that for the method provided by the embodiments of the present application, the loadable file can be part of the on-demand start-stop service, or can not be part of the on-demand start-stop service, which is not limited herein.

[0058] In addition, the above-mentioned process of loading some system service functions for proxy execution is also beneficial to reduce the number of on-demand start-stop services frequently started and stopped in the system, and can to some extent reduce the occupation of system memory, computing and other resources, and is also beneficial to reduce the system energy consumption.

[0059] It can be understood that the above-mentioned decoupled loadable file such as so file corresponding to the corresponding function can be added to the dynamic link library or other shared library of the system. When the loadable file of the corresponding function needs to be loaded, the specified resident process in the system can complete the loading through the corresponding loading function or calling function. The loaded loadable file can also be called and executed in the form of a dynamic link library file.

[0060] It can be understood that the process of analyzing the frequently called functions in the above-mentioned analysis can be completed by the system service or the corresponding subsystem to which the function belongs. For example, the system service can count the function with the highest calling frequency in the process of starting and running the process, and accordingly analyze that the function can be the main factor causing the system service to be frequently loaded. Accordingly, the system service or the subsystem to which the system service belongs can copy the program code segment or code file corresponding to the above-mentioned analyzed function and link it into an independent executable so file.

[0061] It can be understood that the meaning of "frequently" above refers to the frequency of occurrence of the corresponding event being higher than a preset value in the corresponding detection duration, or being a higher value compared to the frequency of occurrence of other similar events. For example, frequent loading refers to the frequency of loading and running the corresponding system service being higher than a preset value in the corresponding detection duration, which is not limited herein.

[0062] In addition, "loading" described in the context of the present application refers to the process of executing the loadable file of the corresponding system service to start running the corresponding system service, which is clarified herein.

[0063] It can be understood that the terminal device to which the proxy method of the system service provided by the present application is applicable can include but is not limited to a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a netbook, an augmented reality (AR) / virtual reality (VR) device, a smart television, a smart watch and other wearable devices, a server, an in-vehicle device, a portable game console, a portable music player, a reader device, other electronic devices having one or more processors, or other electronic devices capable of accessing a network.

[0064] Figure 2a According to an embodiment of the present application, a structure of a system service manager and a principle diagram of managing on-demand start-stop system services are shown.

[0065] As shown in Figure 2a , in the embodiment of the present application, the system service manager 200 includes a service start framework 201, a service module 202, a process management module 203, and an SA configuration file 204, and further includes a service proxy module 205.

[0066] The SA configuration file 204 is used to manage the loading conditions of the system service. Referring to Figure 2a , "1. Analyzing loading conditions", the service start framework 201 can read the SA configuration file 204 and analyze the loading conditions of the SA configured in the configuration file 204. Further, referring to Figure 2a , "2. Listening to loading conditions", the service start framework 201 can set up a listener to the system based on the analyzed loading conditions, for example, register a listener corresponding to some system events and / or client query events to the system.

[0067] Continuing to refer to Figure 2aThe "3.1 system event trigger" and "3.2 client query trigger" shown above can include system events and / or client query events corresponding to the trigger events monitored after the monitoring is set. As an example, the system trigger can include system events such as system attribute changes, timers, device networking, and some common events, and the like, which correspond to the manner in which the corresponding service is triggered. The system attribute change event can include, for example, a system event in which the attribute value of a switch is triggered by the change of the switch state of some switch control. The device networking event can include, for example, a system event triggered by networking through Bluetooth (BT), near field communication (NFC), wireless fidelity (Wi-Fi), and the like. The common event can include, for example, a system event triggered by the sending or receiving of some broadcast message, and the like, without limitation.

[0068] The client query trigger can include a service end corresponding to the manner in which the corresponding service is triggered by the local client, the remote client query / call of the corresponding system service. The local client refers to the system service client in the operating system of the local device or the end device as the calling party, and the corresponding called system service generally provides a functional service through the execution of the code logic of the service end. The remote client refers to the system service client in the operating system of another terminal device as the calling party, and the system service calling process in the local operating system across devices is a remote call or a cross-device call.

[0069] In the embodiments of the present application, the listener registered by the service startup framework 201 can be set as the service agent module 205 corresponding to the reported object. For example, when the service startup framework 201 registers the listener, the interface of the service agent module 205 can be provided to the system as the receiver of the monitoring result.

[0070] The service module 202 is used to manage the handle and the like of the system service (SA) registration, so as to provide the required functions by the cross-process call of the corresponding system service by the service module 202.

[0071] When the service module 202 receives the call of the service startup framework 201, the service startup framework 201 can first determine the state of the system service currently loaded according to the service identification information (ID) and the like pre-registered by each system service, including the states of NOT_LOADED, LOADING, LOADED, UNLOADABLE, and UNLOADING, and the like. In some other embodiments, the state of the system service can also be described as the life cycle of the system service, without limitation.

[0072] With reference back to Figure 2a As shown, "4. Trigger loading", for the system service not loaded, the service agent module 205 can invoke the interface of the service start framework 201 to trigger loading. At this time, the service start framework 201 can invoke the process management module 203 through the service module 202 to trigger the SA loading process. Reference is made to Figure 2a As shown, "5. Initiate loading request", the service module 202 can initiate a loading request to the process management module 203 to request the system to create a process and load the loadable file for executing the corresponding system service to start running the corresponding system service process. The process of starting running can refer to Figure 2a As shown, "6. Start running". The system can load the system service process to run the corresponding system service, for example, through the init process, which is usually the first user program process started by the operating system, also known as the spawn process, which can be used to create other processes such as the above-mentioned system service process, without limitation.

[0073] For the system service being loaded or already loaded, the service module 202 can invoke the function of the corresponding system service according to the handle and other calling information provided by the corresponding system service process after starting running to respond to the loading request of the service start framework 201.

[0074] The service agent module 205 can proxy the corresponding system service process when receiving the corresponding monitored system event, load and execute the loadable file corresponding to some frequently called functions in the system service, and provide the corresponding function through the proxy system service to respond to the corresponding system event or client query request. The service agent module 205 can also include a configuration file for maintaining the configuration of the proxy service corresponding to each system service. The configuration file can be configured with a corresponding proxy service for a decoupled system service, for example, an upgrade proxy service for an upgrade service, or a DP proxy service for a device management service. The configured service agent can be an interface function capable of loading the loadable file of the corresponding function, or another loadable file, for example, a so file capable of loading the loadable file of the corresponding function when executed. In some embodiments, the service agent module 205 can include an event distribution module, a proxy execution module, and a proxy decision module, and the like, which can be referred to the related description below, and will not be repeated here.

[0075] It can be understood that the process corresponding to the running of the service agent module 205 can be a resident process of the system, or the service agent module 205 can be a resident thread of the resident process of the SAMGR 200, without limitation.

[0076] Comparing the above Figure 1 With Figure 2aAs shown in the structure, in the embodiment of the present application, after the SAMGR 200 parses the SA configuration file 204 through the service startup framework 201 to obtain the loading conditions corresponding to the configuration of each on-demand start-stop system service, the service agent module 205 can be registered as the recipient of the corresponding listening results when the system registers the listener. In this way, when the registered listener listens to the system event or client query request corresponding to each system service loading condition, it can be reported to the service agent module 205. At this time, the service agent module 205 can first determine whether the system service triggered to load by the above-mentioned system event is frequently loaded, and whether the function in the system service for responding to the above-mentioned system event has been decoupled from the system service. Based on the determination result, the service agent module 205 can proxy some frequently loaded system services, load and execute the loadable file corresponding to the corresponding decoupled function. At this time, the service agent module 205 can directly provide the corresponding function to respond to the listened system event, avoiding the situation that the corresponding system service process is frequently loaded and run.

[0077] For some system events or client requests that need to start the corresponding system service process to respond, the service agent module 205 can forward the corresponding event or request to the service startup framework to trigger the loading and running of the corresponding system service. At this time, the service startup framework 201 can initiate a request to load the corresponding system service to the service module 202 of the SAMGR 200 based on the received event or request triggering the loading of the corresponding system service. Correspondingly, the service module 202 can initiate a request to load the process to the system through the process management module 203, and request the system to create and start running the system service process triggered to load corresponding to the listened system event.

[0078] After the above-mentioned system service process is started and run, it can also register the handle calling information to the service module 202 of the SAMGR 200, so that the service module 202 can call the corresponding function of the system service, which can respond to the system event or client query request received by the service startup framework 201, which will not be described here. At this time, the corresponding function provided by the system service process started and run can be some function with low calling frequency or function whose program code is highly coupled with other functions and cannot be decoupled, etc. The function can also be the above-mentioned frequently called function, which is not limited here.

[0079] As an example, Figure 2b According to the embodiment of the present application, a structure of a service agent module and a principle diagram of proxying / distributing listening events are shown.

[0080] As Figure 2b shown, the service agent module 205 can include an event distribution module 051, a proxy execution module 052, and a proxy decision module 053.

[0081] The event distribution module 051 can be configured to distribute the trigger events reported by the listeners, and the trigger events can be distributed to the agent service managed by the agent execution module 052 for response. Figure 2b As shown in the figure, the trigger events monitored can include but are not limited to:

[0082] ① Local or remote client query trigger loading event;

[0083] ② Timer trigger loading event;

[0084] ③ System attribute change trigger loading event;

[0085] ④ Public event trigger loading event;

[0086] ⑤ Device networking trigger loading event.

[0087] Among them, ② to ⑤ above can correspond to the above Figure 2a The trigger loading "on-demand start-stop service" system event shown in the figure, ① above can correspond to the above Figure 2a The trigger loading "on-demand start-stop service" client query request shown in the figure. For example, the event distribution module 051 can distribute the timer trigger loading upgrade event to the upgrade agent service for response managed by the agent execution module 052. The process where the upgrade agent service is located can load the dynamic link library file corresponding to the query function of the upgrade service and execute, and then the upgrade service provides the query function to the server to query whether there is an updated upgrade data packet.

[0088] For another example, the event distribution module 051 can distribute the local or remote client query trigger loading query event to the DP agent service for response. The process where the DP agent service is located can load the dynamic link library file corresponding to the information management function of the device management service and execute, and then the device management service queries whether the client requests to query the device information and distributed call information on each distributed device. It can be understood that the process where the upgrade agent service is located, the process where the DP agent service is located, etc. can be the resident process managed by the agent execution module 052.

[0089] The agent execution module 052 can be configured to manage some resident agent service processes to respond to the trigger events distributed by the event distribution module 051. These resident agent service processes can run, for example, upgrade agent service, DP agent service and other agent services. These agent services can proxy the loading and execution of some functions of the loadable files of the corresponding system services, and when the loadable files of the corresponding functions are loaded and executed, the agent services can provide the corresponding system service functions to respond to the distributed trigger events.

[0090] The agent decision module 053 can be configured to determine whether the system service process triggered by the trigger event needs to be loaded continuously based on the agent execution result fed back by the agent execution module 052.

[0091] If the system service process triggered by the trigger event needs to be loaded continuously, the agent decision module 053 can send a corresponding loading request to the service starting framework 201. If the system service process triggered by the trigger event does not need to be loaded, the agent decision module 053 can directly respond to the trigger event based on the function executed by the corresponding agent service, to complete the service request triggered by the trigger event. The agent execution result can include the following cases:

[0092] I. The agent execution fails.

[0093] II. The agent execution succeeds, and the corresponding system service needs to be loaded for further processing. For example, the upgrade agent service successfully executes the query function and queries the upgrade data packet, and the upgrade service needs to be loaded to continue to execute the next step of downloading the upgrade data packet and installing the upgrade data packet.

[0094] III. The agent execution succeeds, and no further processing is needed.

[0095] The agent execution module 052 can return a type of state value to the agent decision module 053 as the agent execution result based on the case III, and the type of state value can indicate that the system service process does not need to be loaded continuously. The agent execution module 052 can return another type of state value to the agent decision module 053 based on the case I and the case II, and the type of state value can indicate that the system service process needs to be loaded continuously. In this way, the agent decision module 053 can determine whether the system service process triggered by the trigger event needs to be loaded continuously based on the state value corresponding to the agent execution result fed back by the agent execution module 052.

[0096] Specifically, based on the structure shown in Figure 2a and Figure 2b , the application embodiment shows an interactive implementation flow diagram of an agent method of a system service. Figure 3

[0097] As shown in Figure 3 , the interactive implementation flow involves the interaction among the service starting framework 201, the service module 202, the process management module 203, the SA configuration file 204, and the service agent module 205 in the SAMGR 200 shown in Figure 2a .

[0098] ​It should be noted that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, and do not limit the sequence. If there is a sequence between the steps, the written description is the reference.

[0099] Specifically, Figure 3 The interaction flow shown can include the following steps:

[0100] 301: The service startup framework 201 parses the loading condition in the SA configuration file 204 to trigger the loading of each system service startup and running.

[0101] For example, referring to the above Figure 2a As shown in "1. Parsing the loading condition", the service startup framework 201 of the SAMGR 200 can parse the loading condition corresponding to the configuration of each system service in the SA configuration file 204. As described above, the loading condition refers to the condition corresponding to the trigger of loading the loadable file of the system service and starting the process of the corresponding system service. Among them, the system service corresponding to the loading condition configured in the SA configuration file 204 can be the on-demand start-stop service described above.

[0102] It can be understood that in some embodiments, the SA configuration file 204 described above can be configured with the loading condition corresponding to each on-demand start-stop service, or the loading condition corresponding to different functions of the same on-demand start-stop service. That is, the loading conditions corresponding to different on-demand start-stop services or different functions of the same on-demand start-stop service can be configured in the same SA configuration file. In other embodiments, different on-demand start-stop services or different functions of the same on-demand start-stop service can also be assigned to a separate SA configuration file, which is not limited here.

[0103] It can be understood that before starting to run, the system service usually needs to load the loadable file corresponding to the system service into the address space of the specified process, such as the address space of the empty process initiated by the init process. When the loadable file of the system service runs in the specified process, the specified process can be referred to as the system service process. Therefore, the loading condition described above can also be understood as the condition for loading the loadable file of the corresponding system service into the address space of the specified process.

[0104] It can be understood that in the operating system of a terminal device such as a mobile phone, the loading condition corresponding to the trigger of the on-demand start-stop service can be pre-configured in the SA configuration file 204 of the SAMGR 200 described above. When the operating system runs, the SAMGR 200 also runs the service startup framework 201 to load the SA configuration file 204 and parse the loading condition corresponding to each on-demand start-stop service.

[0105] 302: The service startup framework 201 registers the listener corresponding to each loading condition, and registers the service agent module as the recipient of the listening result.

[0106] For example, referring to the above Figure 2a As shown in "2. Listen to loading conditions", after the service startup framework 201 of the SAMGR 200 parses the SA configuration file 204 to obtain each loading condition, it can register a listener to the system. The listener can be used to listen to corresponding system events and client query triggered service call requests, etc., which can be collectively referred to as trigger events below. The specific trigger event types listened to can refer to the related description below, and will not be repeated here.

[0107] The above registration of the service agent module 205 as the recipient of the listening result can be, for example, by providing an interface of the service agent module 205 to the registered listener, so that the listener calls the interface to report the trigger event listened to to the service agent module 205. In some other embodiments, the above registration of the service agent module as the recipient of the listening result can also be other, which is not limited here.

[0108] 303: The service agent module 205 receives the trigger event reported by the listener.

[0109] For example, in some embodiments, referring to the above Figure 2a As shown in "3. System event triggering", the above registered listener can listen to some system events related to the corresponding loading conditions during the operation of the operating system, including but not limited to timer events, system attribute change events, public events, and device networking events, etc., which are not limited here.

[0110] In some other embodiments, referring to the above Figure 2a As shown in "3. Client query triggering", the above registered listener can listen to the query or call some system services triggered by the local client or remote client during the operation of the operating system, including the above system events and client query events, etc. When these system services are on-demand start-stop services, the trigger event listened to can trigger the system to load the corresponding system service. The above trigger event listened to by the listener can be reported to the service agent module 205 through the calling interface provided by the service agent module 205.

[0111] 304: The service agent module 205 determines the target service triggered to load by the trigger event.

[0112] For example, after receiving the trigger event reported by the listener, the service agent module 205 can determine the system service triggered to load. In order to distinguish, the system service triggered to load by the trigger event is referred to as the target service below.

[0113] In some embodiments, the service agent module 205 can determine the system service matching the trigger event reported by the listener as the target service based on the correspondence between the system service parsed by the service starting framework 201 and the loading condition. In other embodiments, the trigger event reported by the listener can correspond to the identification information carrying the corresponding system service, so that the service agent module 205 can also determine the target service corresponding to the trigger loading based on the identification information carried therein when receiving the trigger event. This is not limited here.

[0114] 305: The service agent module 205 determines whether there is a proxy service pre-configured for the target service.

[0115] If the determination result is yes, the following step 306 can be continued to execute the loadable file of the function decoupled by the target service to provide the corresponding function;

[0116] If the determination result is no, the following step 308 can be executed to continue to load and run the system service process of the target service.

[0117] Exemplarily, the service agent module 205 of the SAMGR 200 can pre-set a service agent configuration file. The configuration file can be used to record the system service related information of some functions decoupled in the system to be handed over to the service agent module 205 for proxy execution. The service agent module 205 can create a proxy service for the corresponding system service based on the system service related information recorded in the configuration file when starting and running, for example, create an upgrade agent service for an upgrade service. The corresponding proxy service can load the loadable file generated by the corresponding decoupled function and proxy execute to proxy the corresponding system service to provide the corresponding function.

[0118] In some embodiments, the service agent module 205 can update the configuration information in the service agent configuration file based on the loadable file such as the so file updated in the shared address such as the dynamic link library, and timely configure the corresponding proxy service for the system service in the system that opens the proxy execution permission. In other embodiments, the service agent module 205 can also receive the configuration request or notification message and the like corresponding to the decoupled function of the corresponding system service to configure the corresponding proxy service for the corresponding system service. This is not limited here.

[0119] 306: The service agent module 205 loads the loadable file of the corresponding function into the corresponding proxy service process for proxy execution.

[0120] Exemplarily, when the service agent module 205 determines that there is an agent service pre-configured for the target service, the service agent module 205 can load the generated loadable file corresponding to the decoupled function of the target service through the agent service process. The loadable file can be loaded by loading a dynamic link library file, for example.

[0121] It can be understood that each agent service in the service agent module 205 can be run through a resident process. In some embodiments, the resident process can be a process in which the service agent module 205 is located, and each agent service can be run on a thread of the resident process. In other embodiments, the resident process can also be a process in which the SAMGR 200 is located, and the service agent module 205 and each agent service managed thereby can be run on a thread of the resident process. This is not limited herein.

[0122] 307: The service agent module 205 determines whether the system service process needs to be continuously loaded according to the result of the agent execution.

[0123] If the determination result is yes, the corresponding system service process is loaded to obtain the corresponding function, and steps 308 to 312 are continuously executed.

[0124] If the determination result is no, the corresponding function of the agent execution is provided by the service agent module 205 to respond to the system event monitored above, and step 315 is executed.

[0125] Exemplarily, the service agent module 205 provides the corresponding function through the loadable file of the agent execution of the corresponding function of the target service, which can generate agent execution results in various situations. Referring to the related description in the above Figure 2b , the agent execution result can include the following execution results corresponding to the following situations: I. Agent execution fails; II. Agent execution succeeds and the corresponding system service needs to be loaded for next step processing; III. Agent execution succeeds and next step processing is not needed. The agent execution results corresponding to the situations I and II above can correspond to the determination result that the system service process needs to be continuously loaded. The agent execution failure in the situation I above can include situations that the loadable file of the corresponding function cannot be loaded or the loadable file of the corresponding function cannot be executed, such as the loss of part of the code field in the first loadable file above, which can cause the loadable file to fail to be loaded or executed, and the like. The agent execution result corresponding to the situation III above can correspond to the determination result that the system service process does not need to be continuously loaded. For details, reference can be made to the above Figure 2b and related description, which will not be repeated herein.

[0126] 308: The service agent module 205 sends a loading request for the target service to the service startup framework 201.

[0127] Exemplarily, referring to the above Figure 2a As shown in "4. Trigger loading", when the service agent module 205 determines that the system service process needs to be continuously loaded in the execution of the above step 307, corresponding to the determination result being yes, the service agent module 205 can call the interface of the service starting framework 201, and send a request for continuously loading the target service to the service starting framework 201, that is, the above loading request for the target service.

[0128] 309: The service starting framework 201 requests the service module 202 to load the target service.

[0129] Exemplarily, when the service starting framework 201 receives the loading request sent by the service agent module 205, the service starting framework 201 can call the interface provided by the service module 202 to load the system service process corresponding to the target service to provide corresponding functions. It can be understood that the functions provided by the system service process corresponding to the target service after being loaded can be the functions that the service agent module 205 fails to execute, or can be the functions that the service agent module 205 successfully executes and needs the target service to perform the next step processing, which is not limited here.

[0130] 310: The service module 202 determines whether to continue loading the target service process based on the state of the target service.

[0131] If the determination result is yes, the loading starting process of the following steps 311 to 312 is continuously executed.

[0132] If the determination result is no, the calling response process of the following step 314 is executed.

[0133] Exemplarily, the state of the target service can include the states of NOT_LOADED, LOADING, LOADED, UNLOADABLE and UNLOADING, which are not described here. When the target service is in the state of NOT_LOADED or UNLOADING, the service module 202 can determine that the target service process needs to be continuously loaded. When the target service is in the state of LOADING, LOADED or UNLOADABLE, the service module 202 can determine that the target service process does not need to be continuously loaded, at this time, the target service process is about to be ready or has been ready.

[0134] It can be understood that each of the above states can also correspond to each phase of the target service from being loaded and started to run when needed to being unloaded when not needed. Therefore, the process in which the target service experiences each of the above states can also be described as the life cycle of the target service. In some embodiments, the service module 202 can determine the state in which the target service currently is by reading the life cycle data structure of the target service.

[0135] As an example, the way of reading the life cycle data structure of the target service can refer to the following form:

[0136] enum class SystemAbilityState{

[0137] NOT_LOADED = 0, / / not loaded

[0138] LOADING, / / loading

[0139] LOADED, / / loaded

[0140] UNLOADABLE, / / unloadable

[0141] UNLOADING, / / unloading

[0142] };

[0143] Among them, “NOT_LOADED = 0” indicates that the target service is currently in the state of not being loaded.

[0144] In other embodiments, the service module 202 can also determine the state of the target service through other feedback information, such as the handle information provided by the target service during the historical loading and running, the way of querying the system whether the target service process exists, and confirming whether the target service process has been loaded or not. This is not limited here.

[0145] 311: The service module 202 initiates a process loading request for the target service to the process management module 203.

[0146] As an example, referring to the “5. Initiating a loading request” shown in the above Figure 2a When it is determined that the process corresponding to the target service to be loaded has not been started to run, i.e., the target service process needs to be continuously loaded, the service module 202 can initiate a loading request for the target service process to the process management module 203 in response to the request of the service start framework.

[0147] 312: The process management module 203 requests the system to create a target service process and start to run.

[0148] As an example, referring to the “5. Initiating a loading request” shown in the above Figure 2aThe "6. Start running" process management module 203 applies to the system for creating a process to load and start running the target service in response to the process loading request for the target service initiated by the service module 202. Correspondingly, the system can create a process and load the loadable file of the target service into the address space of the created process, execute the loadable file to start running the target service, and complete the loading of the target service process. For the start process of the target service process, for example, the first started init process in the operating system can create and start running the target service process through the fork function, which is not limited here.

[0149] 313: The service module 202 receives the call information provided by the loaded target service process.

[0150] Exemplarily, after the process management module 203 realizes the start running of the target service process by interacting with the system in the above step 312, the process management module 203 can provide the handle of the target service process to the service module 202 as the call information for the service module 202 to call the functions provided by the target service process. Figure 2a The "7. Registration" process, the target service process can provide its handle to the service module 202 as the call information for the service module 202 to call the functions provided by the target service process.

[0151] It can be understood that the process of the target service process providing the handle to the service module 202 as the call information can also be understood as a registration process, but the registration process is different from the process of the target service registering the agent service with the service agent module 205, which will be explained here.

[0152] 314: The service module 202 calls the corresponding function provided by the target service process based on the call information to respond to the monitored system event.

[0153] Exemplarily, the service module 202 can call the corresponding function provided by the target service process to respond to the monitored system event based on the handle provided by the target service process when running, for example, the monitored system event is the event of querying the upgrade data packet, the service module 202 can call the query function provided by the upgrade service process to query the service for the upgrade data packet to respond to the system event. For another example, the monitored system event is the cross-device Bluetooth networking event, the service module 202 can call the information management function provided by the device management service (DP) to provide the device information of the device having the Bluetooth networking capability to respond to the system event. The specific response process will be described in detail in the specific embodiments below, which will not be described here.

[0154] 315: The service agent module 205 provides the corresponding function to respond to the monitored system event based on the result of the successful execution of the agent.

[0155] Exemplarily, the service agent module 205 can load the loadable file corresponding to the corresponding function from the system library based on the target service corresponding to the registered agent service, for example, the upgrade service corresponding to the registered upgrade agent service, the device management service corresponding to the registered DP agent service, etc., and proxy execution. At this time, the service agent module 205 can provide a corresponding function response to the system event listened to based on the execution result of the loadable file.

[0156] It can be understood that the above-mentioned system library, for example, can be the above-mentioned dynamic link library, and the loadable file of the corresponding function can run in the process where the service agent module 205 is located, or in the process where the SAMGR 200 to which the service agent module 205 belongs is located. The embodiments of the present application do not make any limitation here.

[0157] Based on the execution process of the above-mentioned steps 301 to 315, the proxy method of the system service provided by the present application can more reasonably manage the on-demand loading of the system service on demand. Some frequently triggered functions in the system service are put into the resident process of the system to proxy execution, thereby avoiding the corresponding system service from being frequently loaded and run, and being frequently unloaded and stopped running, etc. In turn, the system memory, computing, and other resource overheads can be saved, and the system energy consumption can be reduced. The resident process that proxies the frequently triggered functions, for example, the process corresponding to the above-mentioned SAMGR 200, etc., is not limited here.

[0158] As described above, the terminal device to which the proxy method of the system service provided by the present application is applicable can include but is not limited to a mobile phone, a tablet computer, etc. Therefore, the terminal device with the above-mentioned SAMGR 200 can also include but is not limited to a mobile phone, a tablet computer, etc. The present application does not make any limitation here.

[0159] The following will take the mobile phone 100 with the above-mentioned SAMGR 200 as an example to introduce the specific implementation process of the proxy method of the system service provided by the present application in different application scenarios.

[0160] The following will take the application scenario of the proxy execution of the query function of the upgrade service provided by embodiment 1 to introduce the specific implementation process of the proxy method of the system service provided by the present application in this scenario.

[0161] Embodiment 1

[0162] Figure 4 According to the embodiments of the present application, a scene schematic diagram of the upgrade service prompting upgrade based on the query function is shown.

[0163] It can be understood that the upgrade service running in the operating system of the mobile phone 100 is an on-demand start-stop service. The trigger condition for starting the upgrade service can be a timing trigger condition, i.e., a timer event monitored by the system. The upgrade service will be loaded and run by the system when the corresponding timing trigger condition is met. In this way, the operating system of the mobile phone 100 can query the server 300 based on the upgrade service to determine whether there is a new version update of the related upgrade data package.

[0164] As shown in Figure 4 , if the upgrade data package is queried, i.e., there is a new version update, the mobile phone 100 can display a "new version" interface 401 as shown in Figure 4 , which shows the version number 402 of the new version data package, such as "3.0.0.300", etc. to the user. The user can click "download and install" 403 on the "new version" interface 401 displayed by the mobile phone 100 to perform the upgrade. In some other embodiments, if the upgrade service running on the mobile phone 100 queries that there is a new version of the upgrade data package, the upgrade service can also automatically download and install the upgrade.

[0165] However, the development and release of the new version of the upgrade data package often takes a long time, and the version of the upgrade data package is usually fixed for a long period of time. In this case, the operating system of the mobile phone 100 running the upgrade service often cannot query the new version of the upgrade data package. In this way, the operating system of the mobile phone 100 frequently loads and unloads the upgrade service when the corresponding timing trigger condition is met, which leads to waste of memory resources of the operating system and increase of energy consumption.

[0166] Based on the application scenario as shown in Figure 4 , Figure 5 an embodiment of the present application shows an implementation flowchart of a proxy method of a system service.

[0167] It can be understood that in the embodiment of the present application, the execution subject of each step in the implementation flowchart as shown in Figure 5 may be the mobile phone 100 described above. In some other embodiments, the execution subject of each step in the implementation flowchart as shown in Figure 5 may also be other terminal devices, which are not limited herein.

[0168] As shown in Figure 5 , the implementation flowchart can include the following steps:

[0169] 501: A call request for an upgrade query function of an upgrade service is detected.

[0170] Exemplarily, the upgrade query function of the upgrade service can be frequently triggered to be called based on a timer event of the system. In other embodiments, the function of the upgrade service that is frequently called can also be other functions of the upgrade service, such as a download function, and the like, without limitation.

[0171] It can be understood that the calling request of the upgrade query function can be initiated by a system event triggered when a loading condition of the upgrade service is met, such as a timer event, and the like. For details, reference can be made to the execution process of steps 301 to 304 in the interaction flow shown in FIG. 5. Figure 3

[0172] 502: Determine whether there is a proxy execution right of the requested upgrade query function.

[0173] If the determination result is yes, that is, the SAMGR 200 of the mobile phone 100 has the proxy execution right of the upgrade query function, the mobile phone 100 can continue to execute the following step 503 to use the specified resident process to proxy execute the loadable file corresponding to the upgrade query function. At this time, the mobile phone 100 can not trigger the running of the upgrade service process.

[0174] If the determination result is no, that is, the SAMGR 200 of the mobile phone 100 does not have the proxy execution right of the upgrade query function, the mobile phone 100 can continue to execute the following step 505 to run the upgrade service process to provide the requested upgrade query function.

[0175] Exemplarily, the "proxy execution right of the upgrade query function" can correspond to a case where the upgrade proxy service has been registered in the SAMGR 200 of the mobile phone 100. At this time, the service proxy module 205 in the SAMGR 200 can load the loadable file of the upgrade query function decoupled from the upgrade service based on the proxy execution right possessed by the upgrade proxy service. Correspondingly, the determination result of the mobile phone 100 executing the present step 502 is yes. Correspondingly, the SAMGR 200 proxy executes the query function, which can proxy the upgrade service to query the server 300 whether there is an updated upgrade data package.

[0176] Correspondingly, if the upgrade service does not register the upgrade proxy service in the SAMGR 200 of the mobile phone 100, the service proxy module 205 of the SAMGR 200 cannot obtain the proxy execution right of the upgrade query function. Correspondingly, the determination result of the mobile phone 100 executing the present step 502 is no.

[0177] It can be understood that the process of determining whether the SAMGR 200 has the proxy execution right of the upgrade query function can be specifically referred to the execution process of steps 301 to 304 in the interaction flow shown in FIG. 5. Figure 3 ​The description of step 305 in the illustrated interaction flow is not repeated here.

[0178] 503: Load the loadable file corresponding to the upgrade query function into the specified process for proxy execution.

[0179] For example, in the case where the phone 100 determines that the upgrade query function has the right to proxy execute the upgrade service, i.e., the result of the judgment in step 502 is yes, the phone 100 can load the loadable file corresponding to the upgrade query function into the specified resident process for proxy execution. The loadable file corresponding to the upgrade query function can be loaded by loading a dynamic link library file. When writing the dynamic link library, a unique access path can be configured for loading. The specified resident process can be, for example, the process in which the SAMGR 200 is located or the process in which the service proxy module 205 of the SAMGR 200 is located, without limitation.

[0180] It can be understood that the process of loading the loadable file corresponding to the upgrade query function for proxy execution can be understood with reference to the description of the process of loading the loadable file corresponding to the upgrade query function for proxy execution in step 303 in the illustrated interaction flow. Figure 3 The description of step 306 in the illustrated interaction flow is not repeated here.

[0181] 504: Determine whether the upgrade service process needs to be started and run continuously according to the result of the proxy execution.

[0182] If the result of the determination is yes, e.g., the proxy execution fails or the proxy execution succeeds but further functions of the upgrade service need to be called, step 505 can be executed. The further functions of the upgrade service can be functions associated with the upgrade query function, without limitation.

[0183] If the result of the determination is no, e.g., the proxy execution succeeds and no further processing is needed, the current flow can be ended.

[0184] For example, the result of the proxy execution can include multiple scenarios, e.g., the proxy execution fails, the proxy execution succeeds but further functions of the upgrade service need to be called, or the proxy execution succeeds and no further processing is needed. The further functions of the upgrade service can be, for example, a download function, a notification function, etc. For example, when the SAMGR 200 of the phone 100 proxies the upgrade service to execute the query function, the phone 100 can query the updated upgrade data package on the server 300. At this time, the phone 100 needs to continue to call the download function of the upgrade service to download the upgrade data package. In other embodiments, before calling the download function of the upgrade service, the phone 100 can first call the notification function of the upgrade service to cause the phone 100 to display the notification information as described above. Figure 4The "new version" interface 401 in the illustrated scenario is for the user to confirm whether to download and install the upgrade data package, etc. No limitation is made herein.

[0185] It can be understood that the several cases contained in the result of the execution of the agent described above can be specifically referred to the description of the above Figure 3 The relevant description in step 307 in the illustrated interaction process is not repeated here.

[0186] 505: Run the upgrade service process to provide the corresponding function.

[0187] Exemplarily, the execution of the corresponding function provided by the mobile phone 100 in this step can include several cases. As an example, in the case where the mobile phone 100 determines in the execution of the above step 502 that the agent has no execution authority for the upgrade query function to be called, the operating system of the mobile phone 100 can create and load the upgrade service process to provide the upgrade query function in response to the above-mentioned call request for the upgrade query function. For example, the mobile phone 100 can run the upgrade service process to provide the upgrade query function.

[0188] As another example, in the case where the mobile phone 100 determines in the execution of the above step 504 that the upgrade service process still needs to be loaded according to the result of the agent execution, the operating system of the mobile phone 100 can also create and load the upgrade service process. When the result of the agent execution is the above-mentioned case I, i.e., the agent execution fails, the system runs the upgrade service process to provide the upgrade query function in response to the above-mentioned call request for the upgrade query function. When the result of the agent execution is the above-mentioned case II, i.e., the agent execution succeeds but further calls the download function or the notification function of the upgrade service or other functions, the system runs the upgrade service process to provide the part of the function.

[0189] It can be understood that the process of loading and running the upgrade service process described above can be specifically referred to the description of the above Figure 3 The execution process of steps 308 to 314 in the illustrated interaction process is not repeated here.

[0190] The above embodiment 1 is based on the execution process of the above steps 501 to 505. For the upgrade service in the operating system which can be frequently triggered to be loaded due to the frequent calling of the upgrade query function, the agent method of the system service provided by the present application can execute the upgrade query function of the upgrade service through the resident process of the system, thereby avoiding the frequent loading / unloading of the upgrade service process, and further reducing the occupation of system memory, calculation and other resources by the frequent loading / unloading process, and also reducing the energy consumption of the system.

[0191] The application provides a system service proxy method. The application further provides a system service proxy method for a distributed device networking scenario.

[0192] Embodiment 2

[0193] Figure 6 A distributed device networking scenario is shown in the embodiment of the application.

[0194] As shown in Figure 6 , the distributed device networking scenario can include a mobile phone 100, a monitoring device 400, a sound box 500, and a large-screen device 600, and the like. The operating system of the mobile phone 100 can manage the information of the distributed devices that can establish a Bluetooth connection, including the device ID, networking verification information, and the like of the monitoring device 400, the sound box 500, and the large-screen device 600, and the like, based on the information management function provided by a device management service (DP). The device management service (DP) can be an on-demand start-stop service.

[0195] It can be understood that the distributed devices in the above scenario can establish a device network through Bluetooth connection, or through a distributed soft bus or NFC, which is not limited herein.

[0196] When the terminal devices are close to each other, or access to the same Wi-Fi, the networking function switches such as Bluetooth switches and NFC switches of some terminal devices remain on, which can frequently send a networking request to other terminal devices, or can receive a networking request sent by other terminal devices. For example, the mobile phone 100 can send a Bluetooth networking request to the monitoring device 400, and the mobile phone 100 can also receive a networking request based on a distributed soft bus sent by the sound box 500 or the large-screen device 600.

[0197] However, in some distributed networking scenarios, the mobile phone 100 can not need to network with other devices. At this time, the mobile phone 100 still needs to load and run the function of querying or obtaining information provided by the device management service (DP) to obtain the device ID and the like of the device initiating the networking request. The information query function can be provided by the information management function provided by the device management service. Moreover, in the case that the user does not perform a networking operation for a long time, the mobile phone 100 will unload the device management service to save energy consumption. In this way, the operating system of the mobile phone 100 can have a situation of frequently loading / unloading the device management service, which further causes waste of memory resources of the operating system and an increase in energy consumption.

[0198] Based on the application scenario shown in Figure 6 , the application provides a system service proxy method. Figure 7An implementation flowchart of a proxy method of a system service is shown according to an embodiment of the present application.

[0199] It can be understood that, in the embodiments of the present application, Figure 7 The execution subject of each step in the implementation flowchart shown can be the mobile phone 100. In other embodiments, Figure 7 The execution subject of each step in the implementation flowchart shown can also be other terminal devices, such as the sound box 500, the large-screen device 600, and the like, which are not limited herein.

[0200] As Figure 7 shown, the implementation flowchart can include the following steps:

[0201] 701: A call request for an information management function of a device management service is detected.

[0202] Exemplarily, the mobile phone 100 can detect the call request for the information management function of the device management service when the networkable terminal device is detected or the network request is received.

[0203] In other embodiments, the frequently called function in the device management service can also be other functions of the device management service, such as a query function, a device allocation and recovery function, and the like, which are not limited herein.

[0204] It can be understood that the call request for the information management function can be initiated by a system event triggered when the loading condition corresponding to the device management service is met, such as a device networking event, and the like, which can be specifically referred to the execution process related description of steps 301 to 304 in the interaction flowchart shown above. Figure 3

[0205] 702: It is determined whether there is a proxy execution authority for the requested information management function.

[0206] If the determination result is yes, that is, the SAMGR 200 of the mobile phone 100 has the proxy execution authority for the information management function, the mobile phone 100 can continue to execute the following step 703 to proxy execute the loadable file corresponding to the information management function by using the specified resident process. At this time, the mobile phone 100 can not trigger the running of the device management service process.

[0207] If the determination result is no, that is, the SAMGR 200 of the mobile phone 100 does not have the proxy execution authority for the information management function, the mobile phone 100 can continue to execute the following step 705 to run the device management service process to provide the requested information management function.

[0208] ​Exemplarily, the "function of having proxy execution authority of information management function" above can correspond to a case where the device management service (DP) has registered a DP proxy service in the SAMGR 200 of the mobile phone 100. At this time, the service proxy module 205 in the SAMGR 200 can load the loadable file corresponding to the information management function decoupled from the device management service based on the proxy execution authority possessed by the DP proxy service. Correspondingly, the judgment result of the mobile phone 100 executing the present step 702 is yes. Correspondingly, the SAMGR 200 proxies the execution of the information management function, and can proxy the device management service to determine the device information of the devices that can be networked around, or determine the device information of the device sending the network request, including the device ID of the monitoring device 400, the device ID of the sound box 500, and / or the device ID of the large-screen device 600 in the scenario shown in Figure 6

[0209] Correspondingly, if the device management service does not register the DP proxy service to the SAMGR 200 of the mobile phone 100, the service proxy module 205 of the SAMGR 200 cannot obtain the proxy execution authority of the information management function. Correspondingly, the judgment result of the mobile phone 100 executing the present step 702 is no.

[0210] It can be understood that the process of judging whether the proxy execution authority of the information management function is possessed can refer to the related description in step 305 in the interaction process shown in Figure 3

[0211] 703: Load the loadable file corresponding to the information management function into the specified resident process for proxy execution.

[0212] Exemplarily, the mobile phone 100 can load the loadable file corresponding to the information management function into the specified resident process for proxy execution in a case where it is determined that the SAMGR 200 has the authority to proxy the execution of the information management function of the device management service, i.e., the judgment result of the execution of the above step 702 is yes. The loadable file corresponding to the information management function can be loaded by loading a dynamic link library file. The specified resident process can be the process in which the SAMGR 200 is located, or the process in which the service proxy module 205 of the SAMGR 200 is located, without limitation.

[0213] It can be understood that the process of loading the loadable file corresponding to the information management function for proxy execution can refer to the related description in step 306 in the interaction process shown in Figure 3

[0214] ​​​704: According to the result of the agent execution, it is determined whether the device management service process needs to be started continuously.

[0215] If the determination result is yes, for example, the agent execution fails or the agent execution succeeds but further invocation of other functions of the device management service is needed, the following step 705 can be executed continuously. The other functions of the device management service can be functions associated with the information management function, which are not limited herein.

[0216] If the determination result is no, for example, the agent execution succeeds and no further processing is needed, the current process can be ended.

[0217] Exemplarily, the result of the agent execution can include several cases, for example, the agent execution fails, the agent execution succeeds but further invocation of other functions of the device management service is needed, or the agent execution succeeds and no further processing is needed. The other functions of the device management service can be, for example, device allocation and recovery functions, etc. As an example, when the SAMGR 200 of the mobile phone 100 executes the information management function of the device management service, for example, it is determined that the devices that can be networked include the sound box 500 and the large screen device 600, at this time, the mobile phone 100 needs to continue to invoke the device allocation and recovery functions of the device management service to allocate Bluetooth pairing information or key information needed for networking based on the distributed soft bus to the sound box 500 and the large screen device 600 that can be networked, which are not limited herein.

[0218] It can be understood that the several cases contained in the result of the agent execution can be referred to the related description in step 307 in the interaction process shown in FIG. 7, which is not repeated herein. Figure 3

[0219] 705: The device management service process is run to provide corresponding functions.

[0220] Exemplarily, the corresponding functions provided by the mobile phone 100 in this step can include several cases. As an example, in the case that the mobile phone 100 determines that the SAMGR 200 does not have the agent execution authority for the information management function to be invoked in step 702, the operating system of the mobile phone 100 can create and load the device management service process to provide the information management function in response to the invocation request of the information management function. For example, the mobile phone 100 can run the device management service process to provide the information management function.

[0221] ​As another example, in the case that the phone 100 determines according to the result of the agent execution that the device management service process still needs to be loaded after performing the step 704 described above, the operating system of the phone 100 can also create and load the running device management service process. When the result of the agent execution is the above case I, i.e., the agent execution fails, the system runs the device management service process to provide the information management function in response to the call request for the information management function. When the result of the agent execution is the above case II, i.e., the agent execution succeeds but further calls are needed for the device allocation and recovery function or the notification function of the device management service or other functions, the system runs the device management service process to provide the part of the functions.

[0222] It can be understood that the process of loading and running the device management service process can be specifically referred to the execution process of the steps 308 to 314 in the interaction flow shown in FIG. 3, which will not be repeated here. Figure 3 It can be understood that the process of loading and running the device management service process can be specifically referred to the execution process of the steps 308 to 314 in the interaction flow shown in FIG. 3, which will not be repeated here.

[0223] The above embodiment 2 is based on the execution process of the steps 701 to 705 described above. For the device management service in the operating system that is frequently triggered to be loaded due to the information management function being frequently called, the agent method of the system service provided in the present application can execute the information management function of the device management service through the resident process of the system, thereby avoiding the frequent loading and unloading of the device management service process, and further reducing the occupation of the system memory, calculation and other resources caused by the frequent loading and unloading process, and reducing the energy consumption of the system.

[0224] Figure 8 According to an embodiment of the present application, a structural schematic diagram of a terminal device is shown. In the embodiment of the present application, the terminal device can include the terminal device such as the phone 100 described above. The following will continue to take the phone 100 as an example to introduce the exemplary structure that the terminal device can have.

[0225] As shown in FIG. 4, the phone 100 can include a processor 401, a memory 402, a power supply 403, a display 404, a communication interface 405, a sensor 406, and a storage medium 407. Figure 8As shown, the mobile phone 100 can include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset jack 170D, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identity module (SIM) card interface 195, etc. The sensor module 180 can include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0226] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 can include more or fewer components than shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0227] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices, or can be integrated in one or more processors. The controller can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching instructions and executing instructions.

[0228] In the embodiments of the present application, the processor 110 can control the execution of the instructions corresponding to the steps in the implementation flow shown in the above embodiment 1 based on the controller. Figure 5 The instructions corresponding to the steps in the implementation flow shown in the above embodiment 2, or the execution of the instructions corresponding to the steps in the implementation flow shown in the above embodiment 3, etc.Figure 7 The instructions corresponding to each step in the implementation flow shown, as well as instructions for implementing the corresponding flow based on the agent method of the system service provided in some embodiments of the present application, are not limited herein.

[0229] The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory can hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to use the instructions or data again, it can be directly called from the above-mentioned memory. This avoids repeated access and reduces the waiting time of the processor 110, thereby improving the efficiency of the system.

[0230] In some embodiments, the processor 110 can include one or more interfaces. The interface can include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM card interface, and / or a universal serial bus (USB) interface, etc.

[0231] The USB interface 130 is an interface that conforms to the USB standard specification, and can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the mobile phone 100, and can also be used to transmit data between the mobile phone 100 and peripheral devices. It can also be used to connect earphones to play audio through the earphones. The interface can also be used to connect other electronic devices, such as AR devices, etc.

[0232] It can be understood that the interface connection relationship between the modules shown in the embodiments of the present application is only illustrative and does not constitute a structural limitation on the mobile phone 100. In some other embodiments of the present application, the mobile phone 100 can also use different interface connection methods or combinations of multiple interface connection methods in the above embodiments.

[0233] The charging management module 140 is configured to receive charging input from a charger. The charger can be a wireless charger or a wired charger. In some embodiments with wired charging, the charging management module 140 can receive charging input from a wired charger through the USB interface 130. In some embodiments with wireless charging, the charging management module 140 can receive wireless charging input through a wireless charging coil of the mobile phone 100. The charging management module 140 can charge the battery 142 and power the terminal device through the power management module 141.

[0234] The power management module 141 is configured to connect the battery 142 and the charging management module 140 to the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160.

[0235] The wireless communication function of the mobile phone 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor, and the baseband processor.

[0236] The antenna 1 and the antenna 2 are configured to transmit and receive electromagnetic wave signals. Each antenna in the mobile phone 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example, the antenna 1 can be multiplexed as a diversity antenna for wireless local area networks. In some other embodiments, the antennas can be used in combination with a tuning switch.

[0237] The mobile communication module 150 can provide a solution for wireless communication including 2G / 3G / 4G / 5G applied to the mobile phone 100.

[0238] The wireless communication module 160 can provide a solution for wireless communication including wireless local area networks (WLAN) (e.g., Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR), and the like applied to the mobile phone 100.

[0239] In some embodiments, the antennas 1 and the mobile communication module 150 of the mobile phone 100 are coupled, and the antennas 2 and the wireless communication module 160 are coupled, so that the mobile phone 100 can communicate with a network and other devices through wireless communication technologies. The wireless communication technologies can include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-CDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS can include global positioning system (GPS), global navigation satellite system (GLONASS), beidou navigation satellite system (BDS), quasi-zenith satellite system (QZSS), and / or satellite based augmentation systems (SBAS).

[0240] The mobile phone 100 implements a display function through a GPU, a display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 can include one or more GPUs that execute program instructions to generate or change display information.

[0241] The display screen 194 is configured to display images, videos, and the like. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flex light-emitting diode (FLED), a Mini-LED, a Micro-LED, a Micro-OLED, a quantum dot light emitting diode (QLED), or the like. In some embodiments, the mobile phone 100 can include one or N display screens 194, where N is a positive integer greater than 1.

[0242] The mobile phone 100 can implement a photographing function through an ISP, the camera 193, a video codec, a GPU, the display screen 194, and an application processor, and the like. The ISP is configured to process data fed back by the camera 193. The camera 193 is configured to capture still images or videos.

[0243] The external memory interface 120 can be configured to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile phone 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, music, video, and the like are saved in the external memory card.

[0244] The internal memory 121 can be configured to store computer executable program codes including instructions. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, and the like), and the like. The data storage area can store data created during use of the mobile phone 100 (such as audio data, a phonebook, and the like), and the like. In addition, the internal memory 121 can include a high-speed random access memory, and can further include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like. The processor 110 executes various function applications and data processing of the mobile phone 100 by running instructions stored in the internal memory 121 and / or instructions stored in a memory disposed in the processor.

[0245] The mobile phone 100 can implement audio functions through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor, etc. For example, music playing, recording, etc.

[0246] The audio module 170 is configured to convert digital audio information into an analog audio signal output, and to convert an analog audio input into a digital audio signal. The audio module 170 can also be configured to encode and decode audio signals. In some embodiments, the audio module 170 can be disposed in the processor 110, or some functional modules of the audio module 170 can be disposed in the processor 110.

[0247] The speaker 170A, also known as a "loudspeaker", is configured to convert an audio electrical signal into a sound signal. The mobile phone 100 can listen to music or listen to a hands-free call through the speaker 170A.

[0248] The receiver 170B, also known as a "earpiece", is configured to convert an audio electrical signal into a sound signal. When the mobile phone 100 answers a call or a voice message, the receiver 170B can be held close to the ear to listen to the voice.

[0249] The microphone 170C, also known as a "microphone", "sound transducer", is configured to convert a sound signal into an electrical signal.

[0250] The earphone interface 170D is configured to connect a wired earphone. The earphone interface 170D can be a USB interface 130, or a 3.5mm open mobile terminal platform (OMTP) standard interface, a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0251] The keys 190 include a power-on key, a volume key, etc. The keys 190 can be mechanical keys. Alternatively, the keys 190 can be touch keys. The mobile phone 100 can receive key inputs and generate key signal inputs related to user settings and function control of the mobile phone 100.

[0252] The motor 191 can generate a vibration prompt. The motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations for different applications (such as taking pictures, playing audio, etc.) can correspond to different vibration feedback effects. Touch operations on different regions of the display screen 194 can also correspond to different vibration feedback effects of the motor 191. Different application scenarios (such as time reminders, receiving messages, alarms, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0253] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0254] The SIM card interface 195 is used to connect the SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with or separate from the mobile phone 100.

[0255] Figure 9 This is a schematic block diagram of the software system architecture of the mobile phone 100 according to an embodiment of the present invention.

[0256] It is understood that the software system of mobile phone 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to exemplify the software structure of mobile phone 100.

[0257] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TM The system is divided into four layers, from top to bottom: application layer, application framework layer, and Android. TM runtime (Android) TM runtime and system libraries, as well as the kernel layer.

[0258] like Figure 9 As shown, the application layer can include a series of application packages. These application packages can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0259] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0260] The application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0261] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0262] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, etc.

[0263] The view system includes visual controls, such as controls that display text, controls that display pictures, and the like. The view system can be used to build an application. A display interface can be composed of one or more views. For example, a display interface that includes a short message notification icon can include a view that displays text and a view that displays a picture.

[0264] The phone manager is used to provide the communication function of the mobile phone 100. For example, the management of the call state (including call connection, call hang-up, and the like).

[0265] The resource manager provides various resources for an application, such as localized strings, icons, pictures, layout files, video files, and the like.

[0266] The notification manager enables an application to display notification information in the status bar, which can be used to convey a message of the notification type, can automatically disappear after a short stay, and does not require user interaction. For example, the notification manager is used to notify a download completion, a message reminder, and the like. The notification manager can also be a notification that appears in the top status bar of the system in the form of a chart or a scrolling text, for example, a notification of an application running in the background, and can also be a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in the status bar, a prompt sound is emitted, the device vibrates, the indicator light flashes, and the like.

[0267] In the embodiments of the present application, the application framework layer can also include the system services described above, such as the upgrade service, the device management service (DP), and the like. Among them, the upgrade service can provide the corresponding query function, the function of downloading and installing the corresponding upgrade data package, and the like for the system shown in FIG. 1. Figure 9 The device management service can provide the networking capability for the terminal device, such as the mobile phone 100, installed in the system shown in FIG. 1, including the information management function of determining the ID and verification information of other devices that can be networked around, and the device distribution and recycling function of networking or canceling the networking with other devices that can be networked around, without limitation. Figure 9

[0268] Android TM The runtime includes the core library and the virtual machine. The Android TM runtime is responsible for the scheduling and management of the Android TM system.

[0269] The core library includes two parts: one part is the function function that the java language needs to call, and the other part is the core library of Android.

[0270] ​The application program layer and the application framework layer run in a virtual machine. The virtual machine executes the java files of the application program layer and the application framework layer into binary files. The virtual machine is used to perform functions such as management of object life cycle, stack management, thread management, management of security and exception, and garbage collection.

[0271] The system library can include a plurality of functional modules. For example, a surface manager, media libraries, a three-dimensional graphics processing library (for example, openGL ES), a 2D graphics engine (for example, SGL), and the like.

[0272] The surface manager is used to manage a display subsystem, and provides fusion of 2D and 3D layers for a plurality of application programs.

[0273] The media libraries support playback and recording of a plurality of commonly used audio, video formats, and static image files. The media libraries can support a plurality of audio and video encoding formats, for example, MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, and the like.

[0274] The three-dimensional graphics processing library is used to implement three-dimensional graphics drawing, image rendering, synthesis, and layer processing, and the like.

[0275] The 2D graphics engine is a drawing engine for 2D drawing.

[0276] In the embodiments of the present application, the system library can further include a shared library such as a dynamic link library. The dynamic link library can be used to receive a loadable file formed by decoupled functions corresponding to on-demand start-stop system services, and provide a corresponding interface function to a system service manager for loading.

[0277] The kernel layer is a layer between hardware and software. The kernel layer at least includes a display driver, a camera driver, an audio driver, and a sensor driver.

[0278] The embodiments of the present application further provide a computer program product for implementing the proxy method of the system service provided in the above embodiments.

[0279] Embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware, or a combination of these implementation methods. The embodiments of the present application can be implemented as computer program modules or module codes executed on a programmable system, which includes at least one processor, a storage system (including volatile and non-volatile memories and / or storage elements), at least one input device, and at least one output device.

[0280] Computer program modules or module code, can be applied to input instructions to perform the functions described in this application and to generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system that has a processor, such as for example a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0281] The module code can be implemented in a high-level procedural or object-oriented programming language to communicate with a processing system. In the event that the module code is implemented in assembly language or machine language, then the language can be converted to a higher level language using an assembler or a compiler. In fact, the mechanisms described in this application are not limited to any specific programming language. In any case, the language can be a compiled or interpreted language.

[0282] In some cases, the disclosed embodiments can be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments can also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) medium, which can be read and executed by one or more processors. For example, the instructions can be distributed over the network or by other computer readable media. Thus, a machine-readable medium can include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including without limitation, a floppy disk, an optical disc, an optical compact disc, a magnetic optical disc, read only memory (ROM), random access memory (RAM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), magnetic or optical cards, flash memory, or a tangible, machine-readable storage used in the transmission of information over the Internet via electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Accordingly, the machine-readable medium includes any type of mechanical or tangible implementation that is suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0283] Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the exemplary implementations of the application. The appearance of the phrase “in one embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment.

[0284] The disclosure of the present embodiments also relates to an apparatus for performing operations in text. This apparatus can be specially constructed for the required purposes, or it can comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer readable medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and can be coupled to a computer system bus. Furthermore, the computers described in the specification can include a single processor or can be architectures involving multiple processors related by a computer network.

[0285] Additionally, the language used in the specification has been principally selected for readability and instructional purposes and can not have been selected to delineate or circumscribe the disclosed subject matter. Accordingly, the present embodiments are intended to be illustrative, not limiting, of the scope of the concepts discussed herein.

Claims

1. A proxy method for system services, applied to terminal devices, characterized in that, include: A listening event was detected, and the first loading condition for the first function of the first system service was determined to be met. The first function of the first system service is determined to meet the proxy execution conditions; wherein, the proxy execution conditions include the first system service registering a proxy execution service with the system service manager; The system service manager determines a first loadable file corresponding to the first function; wherein the first loadable file is different from the second loadable file corresponding to the first system service; The first function is executed through the system service manager agent; wherein the system service manager is used to manage system services.

2. The method according to claim 1, characterized in that, The detection of the listening event and the determination of the first loading condition that satisfies the first function of the first system service include: Based on the first configuration file of the first system service, a first loading condition corresponding to the first function of the first system service is obtained; wherein, the first configuration file includes loading condition configuration information corresponding to the first system service; Set a first listener corresponding to the first loading condition, the first listener being used to listen for the listening events that enable the first loading condition to be satisfied; Upon detecting the listening event reported by the first listener, it is determined that the first loading condition of the first function of the first system service is met.

3. The method according to claim 2, characterized in that, The monitored event includes any of the following: System attribute change events, timer events, device networking events, common events, and client query events for the second system service; The second system service is a service running on the terminal device or a service running on a peer device that is communicatively connected to the terminal device.

4. The method according to claim 1, characterized in that, The proxy execution service is a service registered by the first system service with the system service manager for proxying the execution of the first function, and... The determination that the first function of the first system service satisfies the agent execution condition includes: The system service manager's second configuration file is detected to include configuration information corresponding to the proxy execution service, and it is determined that the first function of the first system service meets the proxy execution conditions.

5. The method according to claim 4, characterized in that, The step of determining the first loadable file corresponding to the first function through the system service manager includes: The proxy execution service obtains the access path corresponding to the first loadable file provided by the first system service; Based on the access path, determine the first loadable file corresponding to the first function.

6. The method according to claim 5, characterized in that, The execution of the first function through the system service manager agent includes: Based on the access path, the first loadable file is loaded into the first process where the system service manager or the proxy execution service is located, and the proxy executes the first function.

7. The method according to claim 6, characterized in that, The first loadable file is loaded as a dynamic link library file, and, The step of loading the first loadable file into the first process where the system service manager or the proxy execution service resides, based on the access path, includes: Based on the access path, the dynamic link library of the access system places the first loadable file into the address space corresponding to the first process.

8. The method according to any one of claims 1 to 7, characterized in that, The terminal device includes a second loadable file corresponding to the first system service, and, The program code executed by the first loadable file is a part of the program code executed by the second loadable file.

9. The method according to claim 8, characterized in that, The first loadable file and the second loadable file include shared library (so) files.

10. The method according to claim 1, characterized in that, The method includes: If it is determined that the first function of the first system service does not meet the agent execution conditions, the second process corresponding to the first system service is loaded, and the second process is used to execute the first function.

11. The method according to claim 1, characterized in that, The method includes: Based on the result of the failure of the system service manager agent to execute the first function, the second process corresponding to the first system service is loaded, and the second process is used to execute the first function.

12. The method according to claim 11, characterized in that, The failure of the system service manager agent to execute the first function includes any of the following situations: The proxy execution service in the system service manager is unable to load the first loadable file corresponding to the first function; The first process containing the system service manager or the agent execution service cannot execute the first loadable file.

13. The method according to claim 1, characterized in that, The method includes: It is determined that the system service manager agent successfully executed the first function, and it is determined that the second function of the first system service meets the second loading condition, wherein the second loading condition includes the second function being a function that is executed in association with the first function after its execution; The second process corresponding to the first system service is loaded to execute the second function.

14. A terminal device, characterized in that, include: One or more processors; One or more memories; the one or more memories storing one or more programs that, when executed by the one or more processors, cause the terminal device to perform the proxy method for the system service of any one of claims 1 to 13.

15. A computer-readable medium, characterized in that, The readable medium stores instructions that, when executed on a computer, cause the computer to perform the proxy method for the system service as described in any one of claims 1 to 13.

Images