System service proxy method, terminal equipment and computer readable medium

Abstract

The invention relates to the technical field of computers, in particular to a system service proxy method, terminal equipment and a computer readable medium. According to the method, when it is detected that a part of functions in a system service started and stopped according to needs meet a loading condition, under the condition that it is determined that the part of functions meet an agent execution condition, the part of functions can be executed through a system service manager agent so as to respond to a correspondingly detected monitoring event triggering loading of the part of functions. In this way, the system service manager in the system can be used for executing functions which are frequently called in some system services which are started and stopped according to needs, and therefore the problem that the system services which are started and stopped according to needs are frequently triggered to load / unload corresponding processes is avoided.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a system service proxy method, terminal equipment and computer-readable medium. Background Art

[0002] The terminal device can only be used by the user after the operating system is installed. Taking a mobile phone as an example, the operating system of the mobile phone may be Apple TM Operating system (iphone operation system, iOS), Android TM (Android) operating system, open source Hongmeng TM (Open Harmony, OH) system and Hongmeng TM operating system (harmony operation system, Harmony TM OS), etc. For the operating systems in the above examples, they all have a large number of system services (SA), so there are also a large number of system service processes or threads running in the operating system, and the running of these processes or threads occupies the memory resources of the operating system to varying degrees.

[0003] System services in current operating systems can be divided into resident services and on-demand services. Among them, resident services can run permanently in the operating system, while on-demand services need to start or stop running accordingly when the trigger conditions for starting or stopping running are met.

[0004] However, some on-demand start-stop services are frequently loaded / unloaded by the operating system because the trigger conditions for starting or stopping the operation are easily met, which leads to a waste of memory resources and an increase in energy consumption of the terminal device. Summary of the invention

[0005] The present application provides a system service proxy method, terminal device and computer-readable medium, which can use the resident process in the system to proxy the corresponding system service process to execute some frequently called functions in the system service, thereby avoiding the problem of some system services that are started and stopped on demand being frequently triggered to load / unload the corresponding processes.

[0006] Specifically, in the first aspect, the present application provides a proxy method for system services, applied to a terminal device, the method comprising: detecting a monitoring event, determining a first loading condition that satisfies a first function of a first system service; determining that the first function of the first system service satisfies a proxy execution condition; wherein the proxy execution condition comprises the first system service registering a proxy execution service with a system service manager; determining, through 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; executing the first function through the system service manager; wherein the system service manager is used to manage system services.

[0007] For example, the first system service is a system service that starts and stops on demand, and the first function may be a partial function of the system service that starts and stops on demand. The proxy method for the system service provided in the first aspect, that is, when it is detected that some functions in the system service that starts and stops on demand meet the loading conditions, the system service manager may be used to proxy and execute the partial functions when it is determined that the partial functions meet the proxy execution conditions, in response to the corresponding detected listening event that triggers the loading of the partial functions. It can be understood that the first function of the first system service may 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 may be different from the loadable file corresponding to the upgrade service, for example, the program code used to describe the query function in the loadable file of the upgrade service corresponds to a file compiled in the system development stage, such as a shared library (so) file. The proxy execution conditions that need to be met for the first function correspond to the first system service that provides the first function, that is, the proxy execution service is pre-registered in the system service manager for the first system service that provides the first function.

[0008] In addition, the above-mentioned first function corresponds to the proxy execution condition that needs to be met, that is, the first system service that provides the first function pre-registers the proxy execution service in the system service manager, such as the upgrade agent service that the upgrade service pre-registers in the system service manager. Therefore, the above-mentioned process of executing the above-mentioned first function through the system service manager agent can be, for example, the process of loading the first loadable file and executing the loadable file through the upgrade agent service pre-registered in the system service manager through the upgrade service, so as to provide the query function of the upgrade service on behalf of the agent. The above-mentioned terminal device can be, for example, an electronic device such as a mobile phone. This is not limited here.

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

[0010] In some implementations of the first aspect, the formats of the first loadable file and the second loadable file may be different. For the first loadable file of the system service, its format may be Android's apk format, or Hongmeng's hap format, or Windows' exe format, or so format, etc. For the second loadable file of the first function, its format may also be one of the formats in the above examples or other formats.

[0011] In a possible implementation of the first aspect, the above-mentioned detection of a monitoring event and determination of a first loading condition that satisfies a first function of a first system service includes: obtaining a first loading condition corresponding to the first function of the first system service based on a first configuration file of the first system service; the first configuration file includes 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 monitor the monitoring event that can satisfy the first loading condition; detecting the monitoring event reported by the first listener, and determining that the first loading condition that satisfies the first function of the first system service.

[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 one or more system services for loading condition configuration information corresponding to different functions. For example, the SA configuration file may include loading condition configuration information preset for the query function in the upgrade service, and the configuration information can, for example, configure the loading condition of the query function as a timed trigger condition. Correspondingly, the terminal device can be set to monitor the corresponding trigger event when the corresponding timed trigger condition is met based on the configuration information. Furthermore, the terminal device can trigger the corresponding process of executing the query function of the upgrade service through the system service manager agent when the trigger event is monitored, that is, the monitoring event is detected. It will not be elaborated here.

[0013] In a possible implementation of the first aspect above, the monitoring event includes any one of the following: a system property 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 that is communicatively connected to the terminal device.

[0014] For example, the client query event may include query events initiated by a local client and a remote client. The local client may include a client of another system service running on the terminal device itself. The remote client may include a system service client running as a caller in the operating system of another terminal device, that is, a system service client running on the opposite device connected to the terminal device for communication.

[0015] In a possible implementation of the first aspect above, the proxy execution service is a service registered by the first system service to the system service manager and used to proxy execute the first function, and determining that the first function of the first system service meets the proxy execution condition includes: 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 service proxy configuration file preset in the system service manager, which can be used to record the system service related information that decouples some functions in the system to be handed over to the system service manager for proxy execution. The system service manager can create a proxy execution service for the corresponding system service based on the system service related information recorded in the configuration file, such as creating an upgrade proxy service for the upgrade service.

[0017] In a possible implementation of the first aspect above, determining the first loadable file corresponding to the first function through the system service manager includes: obtaining an access path corresponding to the first loadable file provided by the first system service through the proxy execution 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 above, executing the first function through the system service manager agent includes: based on the access path, loading the first loadable file into the first process where the system service manager or the agent execution service is located, and the agent executes the first function.

[0019] In a possible implementation of the first aspect above, the first loadable file is loaded in the form of a dynamic link library file, and based on the access path, the first loadable file is loaded into the first process where the system service manager or the agent execution service is located, including: based on the access path, accessing the system's dynamic link library to move the first loadable file to the address space corresponding to the first process.

[0020] It can be understood that the above-mentioned first process can be, for example, the process where the system service manager is located, and the process can be a resident process running in the system, and the process can load the first loadable file corresponding to the above-mentioned first function and perform proxy execution during the process of running the proxy execution service. At this time, the above-mentioned proxy execution service can run on a subprocess or thread of the process where the system service manager is located, and can run resident or start and stop as needed. In other embodiments, the subprocess where the above-mentioned proxy execution service runs can be a resident process, and the above-mentioned first process is, for example, the process where the proxy execution service runs. Then the process can load the above-mentioned first loadable file and perform proxy execution during the running process. It will not be elaborated 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 executed by the first loadable file is a part of the program code executed by the second loadable file. For example, the function program code executed by the loadable file corresponding to the query function of the upgrade service may be a part of the service program code implemented in the loadable file corresponding to the upgrade service.

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

[0023] In a possible implementation of the first aspect, the method includes: determining that a first function of a first system service does not satisfy 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: based on a result of failure of the system service manager agent to execute the first function, loading a second process corresponding to the first system service, wherein the second process is used to execute the first function.

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

[0026] In a possible implementation of the first aspect above, the method includes: determining that the system service manager agent executes the first function successfully, and determining that the second function that satisfies the first system service satisfies a second loading condition, wherein the second loading condition includes that the second function is an associated function executed after the first function is executed; loading a second process corresponding to the first system service to execute the second function.

[0027] For example, the proxy execution result of the system service manager for the above-mentioned first function may include the execution results corresponding to the following situations: Ⅰ. Proxy execution failed; Ⅱ. Proxy execution was successful, and the corresponding system service needs to be loaded to perform the next step of processing; Ⅲ. Proxy execution was successful, and no next step of processing is required. Among them, the proxy execution results corresponding to the above-mentioned situations Ⅰ and Ⅱ may correspond to the judgment results that the system service process needs to continue to be loaded. The proxy execution failure in the above-mentioned situation Ⅰ may include the situation that the loadable file of the corresponding function cannot be loaded, and the loadable file of the corresponding function cannot be executed, etc., which leads to the execution failure. For example, the loss of some code fields in the above-mentioned first loadable file may cause the loadable file to be unable to load or the execution fails, etc., which is not limited here.

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

[0029] In a third aspect, the present application provides a computer-readable medium having instructions stored thereon, which, when executed on a computer, causes the computer to execute a proxy method for system services provided in the first aspect and various possible implementations of the first aspect.

[0030] In a fourth aspect, the present application provides a program product, which, when running on an electronic device, enables the electronic device to implement the above-mentioned first aspect and any one of the above-mentioned first aspect's possible agent methods for implementing the system service provided.

[0031] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant descriptions in the first aspect mentioned above and various possible implementations of the first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 The figure shows a schematic diagram of an on-demand start-stop framework structure for managing on-demand start-stop system services.

[0033] Figure 2aShown is a schematic diagram of the structure of a system service manager provided by the present application and the principle of managing system services started and stopped on demand.

[0034] Figure 2b Shown is a schematic diagram of the structure of a service proxy module provided by the present application and the principle of proxy / distribution monitoring events.

[0035] Figure 3 Shown is a schematic diagram of the interactive implementation flow of a proxy method for a system service provided by the present application.

[0036] Figure 4 The figure is a schematic diagram of a scenario in which an upgrade service provided in Example 1 of the present application prompts an upgrade based on a query function.

[0037] Figure 5 Shown Figure 4 A schematic diagram of the implementation flow of a proxy method for a system service in the illustrated scenario.

[0038] Figure 6 Shown is a schematic diagram of a distributed device networking scenario provided in Example 2 of the present application.

[0039] Figure 7 Shown Figure 6 A schematic diagram of the implementation flow of a proxy method for a system service in the illustrated scenario.

[0040] Figure 8 Shown is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application.

[0041] Fig. 9 The figure is a schematic block diagram of the software system architecture of a terminal device provided in 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 in conjunction with the accompanying drawings and specific implementation methods.

[0043] Figure 1 A schematic diagram of an on-demand start-stop framework structure for managing on-demand start-stop system services is shown.

[0044] like Figure 1As shown, in the operating system installed on terminal devices such as mobile phones, some on-demand system services, namely the on-demand start-stop services mentioned above, can be managed by the system ability manager (SAMGR). Among them, the system service manager can realize the loading / unloading management of the on-demand start-stop services through the service startup framework, service module, process management module and SA configuration file. The on-demand start-stop service corresponds to the triggering start / stop operation mode, which can include system event triggering and client query triggering.

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

[0046] 101: Parsing loading conditions. The system service manager may first parse the loading conditions from the system service configuration file through the service startup framework. The loading conditions may be pre-configured corresponding to each on-demand system service.

[0047] 102: Listening for loading conditions. SAMGR can register a listener with the system through the service startup 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 startup framework listens to the corresponding loading conditions, it can report the corresponding trigger event to the service startup framework. The trigger event can include system events and client query events.

[0049] 104: Initiate a loading request. The service startup framework of SAMGR can trigger the call of the interface provided by the service management based on the monitoring event, and initiate a loading request to request the loading system service process to provide a function that can respond to the monitoring event.

[0050] 105: Start running. After the system service process starts running, it can provide a handle as call information to the service management module of SAMGR. Based on the call information, the service module can call the system service across processes to provide corresponding functions to respond to the above monitoring events.

[0051] As an example, for example, a timer event in a system event can trigger an upgrade service process to provide a query function to query the server for updated upgrade data packets. 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 the device information and verification information of the requested network. When the loaded system service process completes the corresponding task and enters an idle state, SAMGR can then uninstall 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 usage can be reduced, and the system energy efficiency can also be improved.

[0052] However, when the loading conditions of some on-demand start-stop services are easily met, for example, the timer condition that triggers the loading of the "upgrade service" may be set to query the upgrade data package every day or every N hours. For example, in some smart home environments, there are many smart devices that may frequently trigger device networking, etc. At this time, the service startup framework monitors the system service loading conditions and the corresponding registered listener, and will frequently monitor system events such as timers or device networking. Correspondingly, the service module in the system service manager will frequently initiate 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 upgrade services, starting and running system services such as device management services, and frequently unloading idle system service processes.

[0053] As mentioned above, some on-demand start-stop services are easily triggered to start or stop, so these on-demand start-stop services are frequently loaded / unloaded by the operating system, which leads to a waste of memory resources and an increase in energy consumption of the operating system.

[0054] In order to solve the above problems, the following embodiments of the present application provide a proxy method for system services. Specifically, the method can determine the frequently called functions in the frequently loaded on-demand start-stop service, and decouple the program code corresponding to the function from the corresponding on-demand start-stop service, and execute the function by a resident process proxy specified in the system. Among them, the frequently called functions in the above-mentioned on-demand start-stop service can generate 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-specified resident process when the loading conditions of the system service to which the corresponding function belongs are triggered are met. The resident process can be, for example, the process where the resident service such as the system service manager is located. In this way, the resident process in the system can act as a proxy for the system service process to execute some frequently called functions, thereby avoiding the problem of some system services that are started and stopped on demand being frequently triggered to load / unload the corresponding processes. 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 improve the performance of the terminal device.

[0056] In some examples, the loadable file decoupled from the on-demand start-stop service in each embodiment of the present application may rely on the system service manager. When the loadable file is loaded into the system service manager, the system service manager may 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, which can be loaded into a process or thread respectively. It should be understood that for the methods provided in various embodiments of the present application, the loadable file can be part of the on-demand start-stop service or not, and this is not limited here.

[0058] In addition, the above process of loading some system service function agents to execute responses is also conducive to reducing the number of on-demand start-stop services that are frequently started and stopped in the system, which can reduce the occupation of system memory, computing and other resources to a certain extent, and is also conducive to reducing system energy consumption.

[0059] It can be understood that the loadable files such as so files corresponding to the above-mentioned decoupled corresponding functions can be added to the system's dynamic link library or other shared libraries. When it is necessary to load the loadable files of the corresponding functions, the resident process specified in the system can complete the loading through the corresponding loading function or calling function, and the loaded loadable files can also be called and executed in the form of dynamic link library files, etc.

[0060] It can be understood that the process of frequently called functions in the above 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 functions that are most frequently called during the process startup and run, and analyze that the function may 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 analyzed function and link it into an independent executable so file, etc.

[0061] It is understood that the above-mentioned "frequent" means that the frequency of occurrence of the corresponding event is higher than the preset value within the corresponding detection time, or is higher than the frequency of occurrence of other similar events. For example, frequent loading means that the frequency of the corresponding system service being loaded and running within the corresponding detection time is higher than the preset value, which is not limited here.

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

[0063] It can be understood that the proxy method of the system service provided by the present application can be applicable to terminal devices including but not limited to mobile phones, tablet computers, desktops, laptops, handheld computers, netbooks, as well as augmented reality (AR) / virtual reality (VR) devices, smart TVs, smart watches and other wearable devices, servers, car equipment, portable game consoles, portable music players, reader devices, and other electronic devices with one or more processors or capable of accessing the network.

[0064] Figure 2a According to an embodiment of the present application, a structure of a system service manager and a schematic diagram of the principles of managing system services that are started and stopped on demand are shown.

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

[0066] The SA configuration file 204 is used to manage the loading conditions corresponding to the system services. Figure 2a As shown in “1. Analyze loading conditions”, the service startup framework 201 can read the SA configuration file 204 and analyze the loading conditions of the SA configured in the configuration file 204. Figure 2a As shown in “2. Listening for loading conditions”, the service startup framework 201 can set up listening for the system based on the parsed loading conditions, for example, registering listeners corresponding to some system events and / or client query events with the system.

[0067] Continue to refer Figure 2aAs shown in “3.1 System Event Trigger” and “3.2 Client Query Trigger”, the trigger events corresponding to the above settings for monitoring may include system events and / or client query events. As an example, the above system triggers may include system events such as system property changes, timers, device networking, and some public events, which trigger the loading of corresponding services. System property change events include, for example, system events corresponding to the switching of switch states of some switch controls, which trigger changes in switch property values. Device networking events include, for example, system events triggered by networking through connections such as Bluetooth (BT), near field communication (NFC), and wireless fidelity (Wi-Fi). Public events include, for example, system events triggered by the sending or receiving of some broadcast messages, which are not limited here.

[0068] Client query triggering can include local clients and remote clients querying / calling the server of the corresponding system service to trigger the loading of the corresponding service. Among them, the local client refers to the system service client as the caller in the operating system of the local machine or the local device, and the corresponding called system service generally provides functional services by executing code logic on the server. The remote client refers to the system service client as the caller in the operating system of another terminal device. The process of the client calling the system service in the local operating system across devices is a remote call or a cross-device call.

[0069] In an embodiment of the present application, the object reported by the listener registered by the service startup framework 201 can be set to the service agent module 205. 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 recipient of the monitoring results.

[0070] The service module 202 is used to manage the call information such as the handle registered by the system service (SA), so that the service module 202 can call the corresponding system service across processes to provide the required functions.

[0071] When receiving the call from the service startup framework 201, the service module 202 can first determine the current state of the system service requested to be loaded by the service startup framework 201 according to the service identification information (identification, ID) pre-registered by each system service, including not loaded (NOT_LOADED), loading (LOADING), loaded (LOADED), can be unloaded (UNLOADABLE) and unloaded (UNLOADING) etc. In other embodiments, the state of the above system service can also be described as the life cycle of the system service, which is not limited here.

[0072] Continue to refer Figure 2a As shown in "4. Trigger loading", for unloaded system services, the service proxy module 205 can call the interface of the service startup framework 201 to trigger loading. At this time, the service startup framework 201 can call the process management module 203 through the service module 202 to trigger the SA loading process. Figure 2a As shown in "5. Initiate a load request", the service module 202 can initiate a load request to the process management module 203 to request the system to create a process and load a loadable file that executes the corresponding system service, and start running the corresponding system service process. The process of starting and running can refer to Figure 2a As shown in "6. Start running". The system can, for example, load the system service process through the init process to run the corresponding system service. The init process 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, and is not limited here.

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

[0074] When receiving the corresponding monitored system event, the service proxy module 205 can act as an agent for the corresponding system service process, load and execute the loadable files corresponding to some frequently called functions in the system service, act as an agent for the corresponding system service to provide the corresponding functions, and then respond to the corresponding system event or client query request. The service proxy module 205 can also include a configuration file for the proxy service corresponding to the configuration of each system service, and the configuration file can be a corresponding proxy service for the system service configuration of the decoupled corresponding function, such as configuring an upgrade proxy service for the upgrade service, or configuring a DP proxy service for the device management service, etc. The configured service proxy can be, for example, an interface function capable of loading the loadable file of the corresponding function, or another loadable file, such as a so file capable of loading the loadable file of the corresponding function when executing. In some embodiments, the service proxy module 205 can include an event distribution module, an agent execution module, and an agent decision module, etc., and specific reference can be made to the relevant description below, which will not be repeated here.

[0075] It can be understood that the process corresponding to 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 where the SAMGR 200 is located, which is not limited here.

[0076] Compare the above Figure 1 and Figure 2aAs can be seen from the structure shown, in the embodiment of the present application, SAMGR 200 parses the SA configuration file 204 through the service startup framework 201, obtains the loading conditions corresponding to the system service configurations that are started and stopped on demand, and then registers the service proxy module 205 as the recipient of the corresponding monitoring results when registering the listener to the system. In this way, when the registered listener monitors the system events or client query requests corresponding to the loading conditions of each system service, it can be reported to the service proxy module 205. At this time, the service proxy module 205 can first determine whether the system service corresponding to the system event triggering loading is frequently loaded, whether the function in the system service used to respond to the above system event has been decoupled by the system service, etc. Based on the above determination results, the service proxy module 205 can act as a proxy for some frequently loaded system services, and load and execute the loadable files corresponding to the corresponding decoupled functions. At this time, the service proxy module 205 can directly provide the corresponding function response to the monitored system events, avoiding the situation where the corresponding system service process is frequently loaded and run.

[0077] For some system events or client requests that need to start corresponding system service processes to respond, the service proxy module 205 can forward the corresponding events or requests to the service startup framework to trigger the loading and running of the corresponding system services. At this time, the service startup framework 201 can initiate a request to load the corresponding system services to the service module 202 of SAMGR200 based on the received trigger loading corresponding system service events or requests. Correspondingly, the service module 202 can initiate a request to load the process to the system through the process management module 203, requesting the system to create and start running the system service process corresponding to the trigger loading of the above-mentioned monitored system events.

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

[0079] As an example, Figure 2b According to an embodiment of the present application, a schematic diagram of the structure of a service proxy module and the principle of proxy / distribution monitoring events are shown.

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

[0081] The event distribution module 051 can be used to distribute the triggering events monitored and reported by the listener, and specifically can be distributed to each proxy service managed by the proxy execution module 052 for proxy response. Figure 2b As shown, the monitored trigger events may include but are not limited to:

[0082] ① Local or remote client queries the event that triggers loading;

[0083] ②The timer triggers the loading event;

[0084] ③Events triggered by changes in system properties;

[0085] ④ Public events trigger loading events;

[0086] ⑤Device networking triggers loading events.

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

[0088] For another example, the event distribution module 051 can distribute the query event loaded by the local or remote client query trigger to the DP agent service response. The process where the DP agent service is located can then load the dynamic link library file corresponding to the information management function of the device management service and execute it, and then the agent device management service queries whether each distributed device has the device information and distributed call information requested by the client. 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 a resident process managed by the agent execution module 052.

[0089] The proxy execution module 052 can be used to manage some resident proxy service processes to respond to the trigger events distributed by the event distribution module 051. These resident proxy service processes can respectively run such as upgrade proxy services, DP proxy services and other proxy services. These proxy services can act as agents for the corresponding system services to perform the loading and execution process of loadable files of some functions. When the loadable files of the corresponding functions are loaded and executed, the above-mentioned proxy services can provide corresponding system service functions to respond to the above-mentioned distributed trigger events.

[0090] The proxy decision module 053 can be used to determine whether it is necessary to continue loading the system service process triggered by the triggering event based on the proxy execution result fed back by the proxy execution module 052.

[0091] If it is necessary to continue loading the system service process corresponding to the trigger event, the proxy decision module 053 can send a corresponding loading request to the service startup framework 201. If it is not necessary to load the system service process corresponding to the trigger event, the proxy decision module 053 can directly respond to the monitored trigger event based on the function executed by the corresponding proxy service, and complete the corresponding triggered service request. The above proxy execution results may include the following situations:

[0092] Ⅰ. Proxy execution failed.

[0093] Ⅱ. If the agent is executed successfully, the corresponding system service needs to be loaded for the next step. For example, if the upgrade agent service executes the query function successfully and finds the upgrade data package, the upgrade service needs to be loaded to continue the next step of downloading the upgrade data package, installing the upgrade data package, etc.

[0094] III. The proxy is executed successfully and no further processing is required.

[0095] Among them, the proxy execution module 052 can return a type of status value as the proxy execution result to the proxy decision module 053 based on the above situation III, and this type of status value can indicate that there is no need to continue loading the system service process. The proxy execution module 052 can return another type of status value to the proxy decision module 053 based on the above situations I and II, and this type of status value can indicate that the system service process needs to continue loading. In this way, the proxy decision module 053 can determine whether it is necessary to continue loading the system service process triggered by the above triggering event based on the status value corresponding to the proxy execution result fed back by the proxy execution module 052.

[0096] Specifically, based on the above Figure 2a and Figure 2b The structure shown, Figure 3 According to an embodiment of the present application, a schematic diagram of an interactive implementation process of a proxy method for a system service is shown.

[0097] like Figure 3 As shown, the interactive implementation process involves Figure 2a The illustrated SAMGR 200 includes the interaction between a service startup framework 201 , a service module 202 , a process management module 203 , an SA configuration file 204 , and a service proxy module 205 .

[0098] It should also be stated that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

[0099] Specifically, Figure 3 The interactive process shown may include the following steps:

[0100] 301: The service startup framework 201 parses the loading conditions for triggering the loading of each system service startup from the SA configuration file 204.

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

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

[0103] It can be understood that before a system service is started, it is usually necessary to load the corresponding loadable file of the system service into the address space of a specified process, such as the address space of an empty process initiated and created by the init process. When the loadable file of the system service runs in the specified process, the specified process can be called the system service process. Therefore, the above loading conditions can also be understood as the conditions 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 conditions corresponding to the trigger loading of the on-demand start-stop service can be pre-configured in the SA configuration file 204 of the above-mentioned SAMGR 200. When the operating system is running, SAMGR 200 will also run the service startup framework 201 to load the SA configuration file 204 and parse the loading conditions corresponding to each on-demand start-stop service.

[0105] 302: The service startup framework 201 registers the listeners corresponding to each loading condition, and registers the service proxy module as the receiver of the monitoring result.

[0106] For example, referring to the above Figure 2a As shown in "2. Listening for loading conditions", after parsing the SA configuration file 204 to obtain various loading conditions, the service startup framework 201 of SAMGR 200 can register a listener with the system. The listener can be used to listen to corresponding system events and service call requests triggered by client queries, etc., which can be collectively referred to as trigger events below. The specific trigger event types to be monitored can be referred to in the relevant description below, which will not be repeated here.

[0107] The service proxy module 205 may be registered as a recipient of the monitoring result, for example, by providing an interface of the service proxy module 205 to the registered listener, so that the listener calls the interface to report the monitored trigger event to the service proxy module 205. In other embodiments, the service proxy module may be registered as a recipient of the monitoring result in other ways, which are not limited here.

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

[0109] For example, in some embodiments, reference Figure 2a As shown in “3. System event trigger”, the above-mentioned registered listener can monitor some system events related to the corresponding loading conditions during the operation of the operating system, including but not limited to timer events, system property change events, public events, and device networking events, etc., which are not limited here.

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

[0111] 304: The service proxy module 205 determines that the triggering event corresponds to the target service that triggers loading.

[0112] Exemplarily, after receiving the trigger event reported by the listener, the service proxy module 205 can determine the system service corresponding to the trigger loading. For the sake of distinction, the system service corresponding to the trigger loading of the trigger event is referred to as the target service below.

[0113] In some embodiments, the service proxy module 205 can determine the system service that matches the trigger event reported by the listener as the target service based on the correspondence between the system service and the loading condition parsed by the service startup framework 201. In other embodiments, the trigger event reported by the listener can carry the identification information of the corresponding system service, so when the service proxy module 205 receives the trigger event, it can also determine the target service corresponding to the trigger loading based on the identification information carried therein. This is not limited here.

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

[0115] If the result of the judgment is yes, the following step 306 may be continued to be executed, wherein the proxy executes the loadable file of the function decoupled from the target service to provide the corresponding function;

[0116] If the judgment result is no, the following step 308 may be executed to continue loading the system service process running the target service.

[0117] Exemplarily, a service proxy configuration file may be preset in the service proxy module 205 of the SAMGR 200. The configuration file may be used to record the system service related information that decouples some functions in the system to be handed over to the service proxy module 205 for proxy execution. When the service proxy module 205 is started and operated, it may create a proxy service for the corresponding system service based on the system service related information recorded in the configuration file, for example, create an upgrade proxy service for the upgrade service. The correspondingly created proxy service may load the correspondingly generated loadable file of the correspondingly decoupled function and execute it as a proxy, so as to provide the corresponding function as a proxy for the corresponding system service.

[0118] In some embodiments, the service proxy module 205 can update the configuration information in the maintained service proxy configuration file based on the updated so file or other loadable files in the shared address of the dynamic link library, so as to timely configure the corresponding proxy service for the system service with the open proxy execution authority in the system. In other embodiments, the service proxy module 205 can also receive the corresponding configuration request or notification message sent when the corresponding system service decouples some functions, and configure the corresponding proxy service for the corresponding system service. This is not limited here.

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

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

[0121] It is understood that each proxy service in the service proxy module 205 can be run through a resident process. In some embodiments, the resident process can be the process where the service proxy module 205 is located, and each proxy service can be run on the thread of the resident process. In other embodiments, the above-mentioned resident process can also be the process where the SAMGR 200 is located, and the service proxy module 205 and each proxy service managed by it can be run on the thread of the resident process. No limitation is made here.

[0122] 307: The service agent module 205 determines whether it is necessary to continue loading the system service process according to the result of the agent execution.

[0123] If the judgment result is yes, then continue to execute the following steps 308 to 312 to load the corresponding system service process to obtain the corresponding function;

[0124] If the judgment result is no, the following step 315 is executed, and the service agent module 205 provides the corresponding function of the agent execution to respond to the above-listened system event.

[0125] Exemplarily, the service proxy module 205 provides corresponding functions through the proxy service corresponding to the target service, and the proxy executes the loadable file of the corresponding function, which may produce proxy execution results in various situations. Figure 2b According to the relevant description in, the above-mentioned proxy execution results may include the execution results corresponding to the following situations: Ⅰ. Proxy execution failed; Ⅱ. Proxy execution was successful, and the corresponding system service needs to be loaded to execute the next step; Ⅲ. Proxy execution was successful, and no next step is required. Among them, the proxy execution results corresponding to the above-mentioned situations Ⅰ and Ⅱ may correspond to the judgment results that the system service process needs to be loaded continuously. The proxy execution failure in the above-mentioned situation Ⅰ may include the inability to load the loadable file of the corresponding function, and the inability to execute the loadable file of the corresponding function, etc., which may lead to the execution failure. For example, the loss of some code fields in the above-mentioned first loadable file may cause the loadable file to be unable to load or the execution fails, etc., which is not limited here. The proxy execution result corresponding to the above-mentioned situation III may correspond to the judgment result that the system service process does not need to be loaded continuously. For details, please refer to the above Figure 2b The above and related descriptions will not be repeated here.

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

[0127] For example, referring to the above Figure 2a As shown in "4. Trigger loading", if the service agent module 205 determines that it is necessary to continue loading the system service process when executing the above step 307, corresponding to the judgment result being yes, then the interface of the service startup framework 201 can be called to send a request to the service startup framework 201 to continue loading the target service, i.e., the above-mentioned loading request for the target service.

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

[0129] Exemplarily, when receiving the loading request sent by the service proxy module 205, the service startup 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 the corresponding function. It can be understood that the function provided by the system service process corresponding to the target service after loading can be the function that the above-mentioned service proxy module 205 proxy execution fails, or it can be the function that the target service needs to perform the next step of processing corresponding to the use after the above-mentioned service proxy module 205 proxy execution succeeds, and there is no limitation 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 result of the judgment is yes, then continue to execute the loading and starting process of the following steps 311 to 312;

[0132] If the judgment result is no, the call response process of step 314 is executed.

[0133] Exemplarily, the state of the target service may include not loaded (NOT_LOADED), loading (LOADING), loaded (LOADED), unloadable (UNLOADABLE), and unloading (UNLOADING), etc., which are not described in detail here. Among them, when the target service is in the not loaded (NOT_LOADED) or unloading (UNLOADING) state, the service module 202 can determine that it is necessary to continue to load the target service process. When the target service is in the loading (LOADING), loaded (LOADED), and unloadable (UNLOADABLE) state, the service module 202 can determine that it is not necessary to continue to load the target service process, and the target service process is about to be ready or is ready.

[0134] It is to be understood that the above-mentioned states may also correspond to the various stages from when the target service is loaded and started to when it is needed to when it is unloaded when it is not needed. Therefore, the process of the target service going through the above-mentioned states may also be described as the life cycle of the target service. In some embodiments, the service module 202 may determine the current state of the target service by reading the life cycle data structure of the target service.

[0135] As an example, the method of reading the lifecycle 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] Here, “NOT_LOADED=0” indicates that the target service is currently in an unloaded state.

[0144] In other embodiments, the service module 202 may also determine the state of the target service through other feedback information, such as querying the system whether the target service process exists through the handle information provided by the target service during the historical loading and running period, to confirm whether the target service process has been loaded, etc. 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] For example, referring to the above Figure 2a As shown in “5. Initiate a load request”, the service module 202 responds to the request of the service startup framework. When it is determined that the process corresponding to the target service requested to be loaded has not yet started and running, that is, it is necessary to continue loading the target service process, it can initiate a load request to load the target service process to the process management module 203.

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

[0148] For example, referring to the above Figure 2aAs shown in "6. Start running", the process management module 203 responds to the process loading request for the target service initiated by the service module 202, and applies to the system to create a process to load the target service and start running. Correspondingly, the system can create a process and load the loadable file of the target service to 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 startup process of the target service process, for example, the first init process started 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 calling information provided by the loaded target service process.

[0150] For example, in the above step 312, after the process management module 203 starts and runs the target service process by interacting with the system, refer to the above Figure 2a As shown in “7. Registration”, the target service process can provide its own handle to the service module 202 as calling information for the service module 202 to call various functional services provided by the target service process.

[0151] It can be understood that the process in which the above-mentioned target service process provides a handle etc. as calling information to the service module 202 can also be understood as a registration process, but this registration process is different from the process in which the target service registers the proxy service to the service proxy module 205, which is explained in this application.

[0152] 314: Based on the calling information, the service module 202 calls the target service process to provide corresponding functions in response to the monitored system events.

[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 call information such as the handle provided by the target service process when it is running. For example, if the monitored system event is an event corresponding to a timed query for an 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 in response to the system event. For another example, if the monitored system event is a cross-device Bluetooth networking event, the service module 202 can call the information management function provided by the device management service (DP) to provide device information with Bluetooth networking capabilities of related devices in response to the system event. The specific response process will be described in detail in the specific embodiments below and will not be repeated here.

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

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

[0156] It can be understood that the above-mentioned system library can be, for example, the above-mentioned dynamic link library, and the loadable file of the corresponding function can be 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 are not limited here.

[0157] Based on the execution process of the above steps 301 to 315, the proxy method of the system service provided by the present application can perform more reasonable on-demand loading management on the system services that are started and stopped on demand, and put the frequently triggered functions in some system services into the resident process of the system for proxy execution, thereby avoiding the corresponding system services from being frequently loaded and run, and frequently unloaded and stopped, etc., thereby saving the system's memory, computing and other resource overheads, and also helping to reduce system energy consumption. Among them, the resident process of the proxy execution of the frequently triggered functions is, for example, the process corresponding to the above SAMGR 200, etc., which is not limited here.

[0158] As mentioned above, the proxy method of the system service provided in this application may be applicable to terminal devices including but not limited to mobile phones, tablet computers, etc. Therefore, the terminal devices with the above-mentioned SAMGR 200 may also include but not limited to mobile phones, tablet computers, etc., and are not limited here.

[0159] In combination with specific application scenarios, the following describes in detail the specific implementation process of the proxy method for the system service provided by the present application in different application scenarios by taking the mobile phone 100 having the above-mentioned SAMGR 200 as an example.

[0160] The following first introduces the specific implementation process of the proxy method for the system service provided by the present application in this scenario in conjunction with the application scenario of the proxy execution upgrade service query function provided in Example 1.

[0161] Example 1

[0162] Figure 4 According to an embodiment of the present application, a schematic diagram of a scenario in which an upgrade service prompts an upgrade based on a 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 timed trigger condition, that is, a timer event monitored by the system. The upgrade service will be loaded and run by the system when the corresponding timed trigger condition is met. In this way, the operating system of the mobile phone 100 can query the server 300 whether there is a new version update for the relevant upgrade data package based on the upgrade service.

[0164] like Figure 4 As shown, if the upgrade data package is found, that is, there is a new version update, the mobile phone 100 can display Figure 4 The "new version" interface 401 shown shows the version number 402 of the new version data package to the user, such as "3.0.0.300". The user can click "download and install" 403 to upgrade on the "new version" interface 401 displayed on the mobile phone 100. In other embodiments, if the upgrade service running on the mobile phone 100 finds that there is a new version of the upgrade data package, it can also automatically download and install the upgrade.

[0165] However, it often takes a long time for the new version of the upgrade data package to be developed and released, 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 often cannot query the new version of the upgrade data package when running the upgrade service. In this way, the operating system of the mobile phone 100 frequently loads the upgrade service to run and uninstalls the upgrade service to stop running when the corresponding timing trigger condition is met, which leads to a waste of memory resources of the operating system and an increase in energy consumption.

[0166] based on Figure 4 The application scenario shown, Figure 5 According to an embodiment of the present application, a schematic diagram of an implementation flow of a proxy method for system services is shown.

[0167] It can be understood that in the embodiments of the present application, Figure 5 The execution subject of each step in the illustrated implementation process may be the mobile phone 100. In other embodiments, Figure 5 The execution entity of each step in the illustrated implementation process may also be other terminal devices, which is not limited here.

[0168] like Figure 5 As shown, the implementation process may include the following steps:

[0169] 501: A request to call the upgrade query function of the upgrade service was detected.

[0170] Exemplarily, the upgrade query function of the upgrade service can be frequently triggered and called based on the timer event of the system. In other embodiments, the frequently called function of the upgrade service can also be other functions of the upgrade service, such as the download function, etc., which is not limited here.

[0171] It can be understood that the above-mentioned call request for the upgrade query function can be initiated by a system event triggered when the loading condition corresponding to the upgrade service is met. The system event is, for example, a timer event, etc. For details, please refer to the above-mentioned Figure 3 The description of the execution process of step 301 to step 304 in the interactive process shown is not repeated here.

[0172] 502: Determine whether the proxy execution authority for the requested upgrade query function is available.

[0173] If the judgment result is yes, that is, the SAMGR 200 of the mobile phone 100 has the proxy execution authority for the upgrade query function, the mobile phone 100 can continue to execute the following step 503, using the designated resident process proxy to execute the loadable file corresponding to the upgrade query function. At this time, the mobile phone 100 can temporarily not trigger the upgrade service process.

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

[0175] Exemplarily, the above-mentioned "having the proxy execution authority for the upgrade query function" may correspond to the situation where the upgrade service has registered the upgrade proxy service in the SAMGR 200 of the mobile phone 100. At this time, the service proxy module 205 in the SAMGR 200 may load the loadable file of the upgrade query function decoupled from the upgrade service based on the proxy execution authority possessed by the upgrade proxy service. Correspondingly, the judgment result of the mobile phone 100 executing this step 502 is yes. Correspondingly, the SAMGR 200 agent executes the query function, and can act as an agent for the upgrade service to query the server 300 whether there is an updated upgrade data package.

[0176] Accordingly, if the upgrade service has not registered the upgrade agent service with the SAMGR 200 of the mobile phone 100, the service agent module 205 of the SAMGR 200 cannot obtain the agent execution authority for the upgrade query function. Correspondingly, the result of the judgment of the mobile phone 100 executing this step 502 is no.

[0177] It can be understood that the above process of determining whether SAMGR 200 has the proxy execution authority for the upgrade query function can be specifically referred to the above Figure 3The relevant description in step 305 in the interactive process shown is not repeated here.

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

[0179] Exemplarily, when the mobile phone 100 determines that it has the authority to perform the upgrade query function of the upgrade service as a proxy, that is, when the judgment result of executing the above step 502 is yes, the loadable file corresponding to the upgrade query function can be loaded into the designated resident process for proxy execution. Among them, the loadable file corresponding to the upgrade query function can be loaded by loading a dynamic link library file. Moreover, when the loadable file corresponding to the upgrade query function is written into the dynamic link library, a unique access path can be configured for use during loading. The above-mentioned designated resident process, for example, can be the process where the SAMGR 200 is located, or the process where the service proxy module 205 of the SAMGR 200 is located, which is not limited here.

[0180] It can be understood that the process of executing the loadable file agent corresponding to the above-mentioned loading and upgrading query function can be specifically referred to above Figure 3 The relevant description in step 306 in the interactive process shown is not repeated here.

[0181] 504: According to the result of the agent execution, determine whether it is necessary to continue to start and run the upgrade service process.

[0182] If the judgment result is yes, for example, the proxy execution fails or the proxy execution succeeds but other functions of the upgrade service need to be further called, the following step 505 can be continued. The other functions of the upgrade service can be functions associated with the above-mentioned upgrade query function, which is not limited here.

[0183] If the judgment result is no, for example, the proxy execution is successful and no further processing is required, the process can be ended.

[0184] Exemplarily, the results of the above-mentioned proxy execution may include a variety of situations, such as proxy execution failure, proxy execution success but the need to further call other functions of the upgrade service, or proxy execution success and no need for further processing. Among them, other functions of the upgrade service may be, for example, a download function, a notification function, etc. As an example, when the SAMGR 200 proxy upgrade service of the mobile phone 100 executes the query function, for example, it can query the updated upgrade data package on the server 300. At this time, the mobile 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 mobile phone 100 may also call the notification function of the upgrade service so that the mobile phone 100 displays the above-mentioned 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 here.

[0185] It is understood that the above-mentioned proxy execution results include several situations, which can be specifically referred to above Figure 3 The relevant description in step 307 in the interactive process shown is not repeated here.

[0186] 505: Run the upgrade service process and provide corresponding functions.

[0187] Exemplarily, the mobile phone 100 may perform various functions provided in this step. As an example, when the mobile phone 100 performs the above step 502 and determines that there is no proxy execution permission for the upgrade query function to be called, the operating system of the mobile phone 100 may create and load an upgrade service process to provide the upgrade query function in response to the above call request for the upgrade query function. For example, the mobile phone 100 may run the upgrade service process to provide the upgrade query function.

[0188] As another example, when the mobile phone 100 determines that the upgrade service process still needs to be loaded according to the result of the proxy execution in the above step 504, the operating system of the mobile phone 100 can also create and load the upgrade service process. Among them, when the result of the proxy execution is the above situation I, that is, the proxy execution fails, the system runs the upgrade service process and can respond to the above call request for the upgrade query function to provide the upgrade query function. When the result of the proxy execution is the above situation II, that is, the proxy execution is successful but other functions such as the download function or notification function of the upgrade service need to be further called, the system runs the upgrade service process to provide these functions.

[0189] It can be understood that the above process of loading and running the upgrade service process can be specifically referred to above Figure 3 The description of the execution process of steps 308 to 314 in the interactive process shown 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 that may be frequently triggered to load due to the frequent call of the upgrade query function, the proxy method based on the system service provided by the present application can execute the upgrade query function of the upgrade service through the system's resident process agent, thereby avoiding frequent loading / unloading of the upgrade service process, which is beneficial to reduce the occupation of system memory, computing and other resources by the frequent loading / unloading process, and is also beneficial to reduce the energy consumption of the system.

[0191] The following introduces the specific implementation process of the proxy method for the system service provided by the present application in this scenario in conjunction with the application scenario of the information management function of the proxy execution device management service provided in Example 2.

[0192] Example 2

[0193] Figure 6 According to an embodiment of the present application, a schematic diagram of a distributed device networking scenario is shown.

[0194] like Figure 6 As shown, the distributed device networking scenario may include terminal devices such as a mobile phone 100, a monitoring device 400, a speaker 500, and a large-screen device 600. Among them, the operating system of the mobile phone 100 can manage the relevant information of each distributed device that can establish a communication connection such as Bluetooth based on the information management function provided by the device management service (DP), including the device ID, networking verification information, etc. of the terminal devices such as the monitoring device 400, the speaker 500, and the large-screen device 600. Among them, the device management service (DP) can be an on-demand start and stop service.

[0195] It can be understood that the terminal devices in the above scenario can be networked through Bluetooth connection, or through a distributed soft bus or NFC, and there is no limitation here.

[0196] When the terminal devices are close to each other or connected to the same Wi-Fi, the Bluetooth switch, NFC switch and other networking function switches of some terminal devices remain turned on, and they may frequently send networking requests to other terminal devices, and may also receive networking requests from other terminal devices. For example, the mobile phone 100 may send a Bluetooth networking request to the monitoring device 400, and the mobile phone 100 may also receive a distributed soft bus-based networking request from the speaker 500 or the large-screen device 600.

[0197] However, in some distributed networking scenarios, the mobile phone 100 may not need to be networked with other devices. At this time, each time the mobile phone 100 receives a networking request, it still needs to load and run the device management service (DP) to provide information query or information acquisition functions to obtain information such as the device ID that initiated the networking request. The information query function can be provided by the information management function provided by the device management service. In addition, if the user does not perform networking operations for a long time, the mobile phone 100 will uninstall the device management service to save energy. In this way, there may be a situation in which the device management service is frequently loaded / unloaded in the operating system of the mobile phone 100, which will lead to a waste of memory resources of the operating system and an increase in energy consumption.

[0198] based on Figure 6 The application scenario shown, Figure 7According to an embodiment of the present application, a schematic diagram of an implementation flow of a proxy method for system services is shown.

[0199] It can be understood that in the embodiments of the present application, Figure 7 The execution subject of each step in the illustrated implementation process may be the mobile phone 100. In other embodiments, Figure 7 The execution entity of each step in the illustrated implementation process may also be other terminal devices, such as the above-mentioned speaker 500, large-screen device 600, etc., and no limitation is made here.

[0200] like Figure 7 As shown, the implementation process may include the following steps:

[0201] 701: A request to call the information management function of the device management service is detected.

[0202] Exemplarily, when the mobile phone 100 detects a terminal device capable of networking or receives a networking request, the system may detect a request for calling the information management function of the device management service.

[0203] In other embodiments, the frequently called functions in the above-mentioned device management service may also be other functions of the device management service, such as a query function, a device allocation and recycling function, etc., which are not limited here.

[0204] It can be understood that the above-mentioned 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. The system event is, for example, a device networking event, etc. For details, please refer to the above-mentioned Figure 3 The description of the execution process of step 301 to step 304 in the interactive process shown is not repeated here.

[0205] 702: Determine whether the proxy execution authority for the requested information management function is available.

[0206] If the result of the judgment 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, using the designated resident process proxy to execute the loadable file corresponding to the information management function. At this time, the mobile phone 100 may not trigger the running of the device management service process.

[0207] If the result of the determination 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 may proceed to the following step 705 to run the device management service process to provide the requested information management function.

[0208] Exemplarily, the above-mentioned "function with proxy execution authority for information management function" may correspond to a situation where the device management service (DP) has registered the DP proxy service in the SAMGR 200 of the mobile phone 100. At this time, the service proxy module 205 in the SAMGR 200 may 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 this step 702 is yes. Correspondingly, the SAMGR 200 agent executes the information management function, and may act as an agent for the device management service to determine the device information of the surrounding devices that can be networked, or determine the device information that sends a networking request, including the above-mentioned Figure 6 The device information such as the device ID of the monitoring device 400, the device ID of the speaker 500 and / or the device ID of the large-screen device 600 in the illustrated scenario is not limited here.

[0209] Accordingly, if the device management service has not registered the DP agent service with the SAMGR 200 of the mobile phone 100, the service agent module 205 of the SAMGR 200 cannot obtain the agent execution authority for the above information management function. Correspondingly, the result of the judgment of the mobile phone 100 executing this step 702 is no.

[0210] It can be understood that the above process of determining whether the agent has the authority to execute the information management function can be specifically referred to above. Figure 3 The relevant description in step 305 in the interactive process shown is not repeated here.

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

[0212] Exemplarily, when the mobile phone 100 determines that SAMGR 200 has the authority to execute the information management function of the device management service on behalf of the mobile phone 100, that is, when the judgment result of executing the above step 702 is yes, the mobile phone 100 can load the loadable file corresponding to the information management function into the designated resident process for proxy execution. The loadable file corresponding to the information management function can be loaded by loading a dynamic link library file. The above designated resident process, for example, can be the process where SAMGR 200 is located, or the process where the service proxy module 205 of SAMGR 200 is located, which is not limited here.

[0213] It can be understood that the process of the loadable file agent execution corresponding to the above loading information management function can be specifically referred to the above Figure 3 The relevant description in step 306 in the interactive process shown is not repeated here.

[0214] 704: According to the result of the agent execution, it is determined whether it is necessary to continue to start and run the device management service process.

[0215] If the judgment result is yes, for example, the proxy execution fails or the proxy execution succeeds but other functions of the device management service need to be further called, the following step 705 can be continued. The other functions of the device management service can be functions associated with the above information management function, which is not limited here.

[0216] If the judgment result is no, for example, the proxy execution is successful and no further processing is required, the process can be ended.

[0217] Exemplarily, the result of the above-mentioned proxy execution may include a variety of situations, such as proxy execution failure, proxy execution success but the need to further call other functions of the device management service, or proxy execution success and no need to proceed to the next step. Among them, other functions of the above-mentioned device management service may be, for example, device allocation and recycling functions, etc. As an example, when the SAMGR 200 agent device management service of the mobile phone 100 executes the information management function, for example, it is determined that the devices that can be networked include the above-mentioned speakers 500 and large-screen devices 600. At this time, the mobile phone 100 needs to continue to call the device allocation and recycling function of the device management service to allocate Bluetooth pairing information to the speakers 500 and large-screen devices 600 that can be networked, or the key information required for networking based on the distributed soft bus, etc., which is not limited here.

[0218] It is understood that the above-mentioned proxy execution results include several situations, which can be specifically referred to above Figure 3 The relevant description in step 307 in the interactive process shown is not repeated here.

[0219] 705: Run the device management service process and provide corresponding functions.

[0220] Exemplarily, the mobile phone 100 may perform various functions provided in this step. As an example, when the mobile phone 100 performs the above step 702 and determines that the SAMGR 200 does not have the proxy execution authority for the information management function to be called, the operating system of the mobile phone 100 may create and load a device management service process to provide the information management function in response to the above call request for the information management function. For example, the mobile phone 100 may run the device management service process to provide the information management function.

[0221] As another example, when the mobile phone 100 determines that the device management service process still needs to be loaded according to the result of the proxy execution in the above step 704, the operating system of the mobile phone 100 can also create and load the device management service process. Among them, when the result of the proxy execution is the above situation I, that is, the proxy execution fails, the system runs the device management service process and can respond to the above-mentioned call request for the information management function to provide the information management function. When the result of the proxy execution is the above situation II, that is, the proxy execution is successful but it is necessary to further call other functions such as the device allocation and recovery function or the notification function of the device management service, the system runs the device management service process to provide these functions.

[0222] It can be understood that the process of loading and running the device management service process can be specifically referred to above. Figure 3 The description of the execution process of steps 308 to 314 in the interactive process shown is not repeated here.

[0223] The above embodiment 2 is based on the execution process of the above steps 701 to 705. For the device management service in the operating system that may be frequently triggered to be loaded due to the frequent call of the information management function, the proxy method based on the system service provided by the present application can execute the information management function of the device management service through the system's resident process agent, thereby avoiding frequent loading / unloading of the device management service process, which is beneficial to reduce the occupation of system memory, computing and other resources by the frequent loading / unloading process, and is also beneficial to reduce the energy consumption of the system.

[0224] Figure 8 According to an embodiment of the present application, a schematic diagram of the structure of a terminal device is shown. In the embodiment of the present application, the terminal device may include the mobile phone 100 and other terminal devices. The following continues to take the mobile phone 100 as an example to introduce an exemplary structure that the terminal device may have.

[0225] like Figure 8As shown, the mobile phone 100 may 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, an earphone interface 170D, a sensor module 180, a button 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 may include a pressure sensor 180A, a gyroscope sensor 180B, an air 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 is understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0227] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (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. Among them, different processing units may be independent devices or integrated into one or more processors. The controller may generate an operation control signal according to the instruction opcode and the timing signal to complete the control of fetching and executing instructions.

[0228] In the embodiment of the present application, the processor 110 may execute the above-mentioned embodiment 1 based on the controller control. Figure 5 The instructions corresponding to each step in the implementation process shown, or the execution of the above embodiment 2 provided Figure 7 The instructions corresponding to each step in the implementation process shown, as well as the instructions for implementing the corresponding processes implemented by the proxy method of the system service provided in this application in some other embodiments, are not limited here.

[0229] The processor 110 may 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 may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0230] In some embodiments, the processor 110 may include one or more interfaces. The interface may 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 complies with 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 transfer data between the mobile phone 100 and peripheral devices. It can also be used to connect headphones to play audio through the headphones. The interface can also be used to connect other electronic devices, such as AR devices, etc.

[0232] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the mobile phone 100. In other embodiments of the present application, the mobile phone 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

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

[0234] The power management module 141 is used to connect the battery 142, the charging management module 140 and 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] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0237] The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G etc. applied on the mobile phone 100 .

[0238] The wireless communication module 160 can provide wireless communication solutions for application on the mobile phone 100, including wireless local area networks (WLAN) (such as Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field wireless communication technology (NFC), infrared technology (IR), etc.

[0239] In some embodiments, the antenna 1 of the mobile phone 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the mobile phone 100 can communicate with the network and other devices through wireless communication technology. The above wireless communication technology may 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 technology. The above-mentioned GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

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

[0241] The display screen 194 is used to display images, videos, etc. 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 or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Mini-LED, Micro-LED, Micro-OLED, quantum dot light-emitting diodes (QLED), etc. In some embodiments, the mobile phone 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0242] The mobile phone 100 can realize the shooting function through the ISP, the camera 193, the video codec, the GPU, the display screen 194 and the application processor, etc. Among them, the ISP is used to process the data fed back by the camera 193. The camera 193 is used to capture static images or videos.

[0243] The external memory interface 120 can be used 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, such as storing music, video and other files in the external memory card.

[0244] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the mobile phone 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional 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 provided in the processor.

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

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

[0247] The speaker 170A, also called a "speaker", is used 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 called a "earpiece", is used to convert audio electrical signals into sound signals. When the mobile phone 100 receives a call or voice message, the voice can be received by placing the receiver 170B close to the ear.

[0249] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals.

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

[0251] The key 190 includes a power key, a volume key, etc. The key 190 can be a mechanical key or a touch key. The mobile phone 100 can receive key input and generate key signal input related to the user settings and function control of the mobile phone 100.

[0252] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. For touch operations acting on different areas of the display screen 194, motor 191 can also correspond to different vibration feedback effects. Different application scenarios (for example: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

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

[0254] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to or disconnected from the mobile phone 100 by inserting the SIM card interface 195 or pulling the SIM card out of the SIM card interface 195.

[0255] Fig. 9 It 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 the mobile phone 100 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present invention takes the Android system of the layered architecture as an example to exemplify the software structure of the mobile phone 100.

[0257] The layered architecture divides the software into several layers, each with a clear role and division of labor. The 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, Android TM Runtime (Android TM runtime) and system libraries, as well as the kernel layer.

[0258] like Fig. 9 As shown, the application layer may include a series of application packages, which may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0259] The application framework layer provides an application programming interface (API) and a programming framework for the 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, telephony manager, resource manager, notification manager, and the like.

[0261] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0262] Content providers are used to store and retrieve data and make it accessible to applications. This data can include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0263] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0264] The phone manager is used to provide communication functions of the mobile phone 100, such as management of call status (including answering, hanging up, etc.).

[0265] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0266] The notification manager allows applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, the device vibrates, the indicator light flashes, etc.

[0267] In the embodiment of the present application, the application framework layer may also include the above-mentioned upgrade service, device management service (DP) and other system services. Among them, the upgrade service can be Fig. 9 The system shown in the figure provides corresponding query functions, download and install corresponding upgrade data packages, etc. The device management service can be Fig. 9 The terminal devices such as the mobile phone 100 installed in the system shown provide networking capabilities, including information management functions such as determining the IDs of other devices that can be networked around and verification information, as well as device allocation and recycling functions for networking or canceling networking with other devices that can be networked around, etc., which are not restricted here.

[0268] Android TM Runtime includes core libraries and virtual machines. Android TM runtime is responsible for Android TM Scheduling and management of the system.

[0269] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

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

[0271] The system library may include multiple functional modules, such as surface manager, media libraries, 3D graphics processing library (such as openGL ES), 2D graphics engine (such as SGL), etc.

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

[0273] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0274] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

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

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

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

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

[0279] The various 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 a computer program module or module code executed on a programmable system, and the programmable system includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device.

[0280] A computer program module or module code can be applied to input instructions to perform the functions described in this application and 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 having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0281] Module code can be implemented with high-level modular language or object-oriented programming language to communicate with the processing system. When necessary, module code can also be implemented with assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any specific programming language. In either case, the language can be a compiled language or an interpreted language.

[0282] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, instructions may be distributed over a network or through other computer-readable media. Therefore, a machine-readable medium may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, a floppy disk, an optical disk, an optical disk, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic card or an optical card, a flash memory, or a tangible machine-readable memory for transmitting information (e.g., a carrier wave, an infrared signal, a digital signal, etc.) using the Internet in an electrical, optical, acoustic, or other form of propagation signal. Accordingly, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

[0283] References to "one embodiment" or "an embodiment" in the specification mean that the specific features, structures, or characteristics described in conjunction with the embodiment are included in at least one exemplary implementation or technology disclosed according to the embodiment of the present application. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment.

[0284] The disclosure of the embodiment of the present application also relates to an operating device for executing the text. The device can be specially constructed for the required purpose or it can include 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 a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC) or any type of medium suitable for storing electronic instructions, and can be coupled to a computer system bus. In addition, the computer mentioned in the specification may include a single processor or may be an architecture involving multiple processors for increased computing power.

[0285] In addition, the language used in this specification has been primarily selected for readability and instructional purposes and may not be selected to describe or limit the disclosed subject matter. Therefore, the present application embodiment disclosure is intended to illustrate rather than limit the scope of the concepts discussed herein.

Claims

1. A system service proxy method, applied to a terminal device, characterized in that: include: A monitoring event is detected, and a first loading condition of a first function of a first system service is determined to be satisfied; Determining that a first function of a first system service satisfies an agent execution condition; wherein the agent execution condition includes that the first system service registers an agent 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; The first function is executed by 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 detecting of the monitoring event and determining that a first loading condition of a first function of the first system service is satisfied includes: Based on a first configuration file of the first system service, obtaining a first loading condition corresponding to a first function of the first system service; wherein the first configuration file includes loading condition configuration information corresponding to the first system service; Setting a first listener corresponding to the first loading condition, the first listener being used to listen to the listening event that can satisfy the first loading condition; A monitoring event reported by the first monitor is detected, and a first loading condition of a first function of a first system service is determined to be satisfied.

3. The method according to claim 2, characterized in that The monitoring event includes any of the following: System property change events, timer events, device networking events, public events, and client query events of 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 in communication with 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 to the system service manager and used to execute the first function on behalf of the first system service, and The determining that the first function of the first system service meets the proxy execution condition includes: It is detected that the second configuration file of the system service manager includes 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 condition.

5. The method according to claim 4, characterized in that The determining, by the system service manager, a first loadable file corresponding to the first function comprises: Acquire, by the proxy execution service, an access path corresponding to the first loadable file provided by the first system service; Based on the access path, a first loadable file corresponding to the first function is determined.

6. The method according to claim 5, characterized in that The performing the first function by 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 agent executes the service, and the agent executes the first function.

7. The method according to claim 6, characterized in that The first loadable file is loaded in the form of a dynamic link library file, and, The step of loading the first loadable file to the first process where the system service manager or the agent execution service is located based on the access path includes: Based on the access path, the dynamic link library of the access system moves the first loadable file to 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 corresponding to the first loadable file is a part of the program code executed corresponding to 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 comprises: It is determined that the first function of the first system service does not meet the proxy execution condition, and a second process corresponding to the first system service is loaded, where the second process is used to execute the first function.

11. The method according to claim 1, characterized in that: The method comprises: According to the result that the system service manager agent fails to execute the first function, a 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 system service manager agent fails to execute the first function, including any one of the following situations: The proxy execution service in the system service manager cannot load the first loadable file corresponding to the first function; The first process where the system service manager or the agent execution service is located cannot execute the first loadable file.

13. The method according to claim 1, characterized in that The method comprises: Determining that the system service manager agent executes the first function successfully, and determining that a second function that satisfies the first system service satisfies a second loading condition, wherein the second loading condition includes that the second function is a function that is executed in association with the first function after the first function is executed; Load a second process corresponding to the first system service 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 store one or more programs, and when the one or more programs are executed by the one or more processors, the terminal device executes the proxy method of the system service described in any one of claims 1 to 13.

15. A computer readable medium, characterized in that The readable medium stores instructions, which, when executed on a computer, enable the computer to execute the agent method for the system service according to any one of claims 1 to 13.

Images