Method for managing system services, and related apparatus

Abstract

Provided in the present application are a method for managing system services, and a related apparatus. The method comprises: acquiring a called condition of a first system service, wherein the first system service is a preset system service other than basic system services; acquiring the occurrence condition of one or more events related to the first system service, wherein the one or more events are configured in a configuration file corresponding to the first system service; acquiring a silent running state of the first system service; and on the basis of the called condition, the occurrence condition of the one or more events and the silent running state, determining the state of the first system service, wherein the state comprises a working state or an idle state. In this way, whether each system service is in a working state or an idle state can be determined.

Description

Method and related device for managing system services

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on September 19, 2023, with application number 202311224555.X and application name “A method and related device for managing system services”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminal technology, and in particular to a method for managing system services and related devices. Background Art

[0003] System services are programs, routines, or processes that perform specific system functions to support other programs, particularly low-level (hardware-dependent) programs. Alternatively, they encapsulate fundamental application-oriented system capabilities, such as application process management, component management, window management, installation package management, phone management, network management, and distributed communications, providing applications with an application programming interface (API).

[0004] In current operating systems, as long as a terminal device is powered on, regardless of whether the system services in the terminal device's operating system are active, each service system will occupy a certain amount of system resources, resulting in a certain amount of resource waste. However, it is currently impossible to accurately determine the status of each system service, and thus it is impossible to manage the system resources corresponding to each system service based on the status of each system service. Therefore, how to accurately determine the status of each system service has become a technical problem that needs to be solved urgently.

[0005] Summary of the Invention

[0006] The present application provides a method and related apparatus for managing system services, in order to accurately determine the status of each system service.

[0007] In the first aspect, the present application provides a method for managing system services, which can be executed by a terminal device, or the method can be executed by a component configured in the terminal device (such as a chip, a chip system, etc.), or it can be implemented by a logic module or software that can realize all or part of the terminal device functions. The present application does not limit this.

[0008] Exemplarily, the method includes: obtaining a calling status of a first system service, where the first system service is a system service other than a preset basic class system service; obtaining an occurrence status of one or more events related to the first system service, where the one or more events are configured in a configuration file corresponding to the first system service; obtaining a silent running status of the first system service; and determining a status of the first system service based on the calling status, the occurrence status of the one or more events, and the silent running status, where the status includes a working status or an idle status.

[0009] Based on the above scheme, by obtaining the calling situation of non-basic system services, the occurrence of events related to non-basic system services, and the silent running status of non-basic system services, the status of non-basic system services can be judged according to the above three items, for example, whether it is in working state or idle state, so as to accurately judge the status of each system service.

[0010] In combination with the first aspect, in some possible implementations, the state of the silent operation includes being in silent operation or not being in silent operation.

[0011] In combination with the first aspect, in some possible implementations, when the first system service declares to start silent operation but does not declare to end silent operation, the status of the silent operation is in silent operation; or, when the first system service declares to end silent operation or has never declared to start silent operation, the status of the silent operation is not in silent operation.

[0012] In combination with the first aspect, in some possible implementations, whether the occurrence of any one of the one or more events triggers the running of the first system service or triggers the termination of the running of the first system service is also configured in the configuration file corresponding to the first system service.

[0013] In combination with the first aspect, in some possible implementations, the status of the first system service is determined based on the calling situation, the occurrence of the one or more events and the state of the silent operation, including: when the first system service is called, or when the occurrence of any one of the one or more events triggers the operation of the first system service, or when the state of the silent operation is in silent operation, determining that the state of the first system service is a working state.

[0014] That is, the terminal device can determine whether the status of the first system service is a working status based on any one of the calling situation, the occurrence of the one or more events, or the silent running status of the first system service.

[0015] In combination with the first aspect, in some possible implementations, the status of the first system service is determined based on one or more of the calling situation of the first system service, the occurrence of the one or more events, and the state of the silent operation, including: when the first system service is not called, and the occurrence of any one of the one or more events triggers the termination of the operation of the first system service or no event of the one or more events occurs, and the state of the silent operation is not in silent operation, determining that the state of the first system service is an idle state.

[0016] That is, the terminal device can determine whether the state of the first system service is idle based on the calling state of the first system service, the occurrence of the one or more events, and the silent running state of the first system service.

[0017] In combination with the first aspect, in some possible implementations, obtaining the calling status of the first system service includes: obtaining a calling count of the first system service; when the calling count is zero, determining that the calling status is not called; or, when the calling count is greater than zero, determining that the calling status is called.

[0018] In combination with the first aspect, in some possible implementations, obtaining the occurrence of one or more events related to the first system service includes: detecting the one or more events related to the first system service.

[0019] In combination with the first aspect, in some possible implementations, the method further includes: updating a status identifier based on a most recently determined status of the first system service, where the status identifier is used to record the status of the first system service.

[0020] The terminal device can not only use the status identifier to record the status of each system service, but also modify the status of each system service.

[0021] In combination with the first aspect, in some possible implementations, the status identifier is updated according to the most recently determined status of the first system service, including: when the status identifier is empty or the recorded status of the first system service is a working status, when the most recently determined called situation is not called, and no event among the one or more events occurs or the occurrence of any event among the one or more events triggers the termination of the operation of the first system service, and when the silent operation status is not in silent operation, the status identifier is updated to an idle state.

[0022] In combination with the first aspect, in some possible implementations, the status identifier is updated according to the most recently determined status of the first system service, including: when the status identifier is empty or the recorded status of the first system service is idle, when the last call situation is determined to be called, or when the occurrence of any one or more events triggers the operation of the first system service, or when the silent operation state is in silent operation, the status identifier is updated to the working state.

[0023] In combination with the first aspect, in some possible implementations, the method further includes: when the state of the first system service is an idle state, releasing system resources occupied by the first system service.

[0024] On the premise of understanding the status of each system service, the terminal device can manage the system resources corresponding to each system service based on the status of each system service. For example, when the first system service is in an idle state, the terminal device can release the system resources corresponding to the first system service to avoid wasting system resources, so that other system services or application processes can utilize this part of the system resources.

[0025] In a second aspect, the present application provides a terminal device that can be used to implement the method of the first aspect and any possible implementation of the first aspect. The terminal device includes corresponding modules for executing the above-mentioned method. The modules included in the terminal device can be implemented in software and / or hardware.

[0026] In a third aspect, the present application provides a terminal device comprising at least one processor and at least one communication interface. The processor is coupled to the communication interface and can be used to execute a program to implement the method for managing system services in the first aspect and any possible implementation of the first aspect.

[0027] Optionally, the terminal device further includes a memory, and the processor is coupled to the memory.

[0028] In a fourth aspect, the present application provides a chip system comprising at least one processor for supporting the implementation of the functions involved in the above-mentioned first aspect and any possible implementation of the first aspect, for example, processing the data involved in the above-mentioned method, etc.

[0029] In one possible design, the chip system also includes a memory, which is used to store program instructions and data. The memory is located inside or outside the processor.

[0030] The chip system can be composed of chips, or can include chips and other discrete devices.

[0031] In a fifth aspect, a readable storage medium is provided, on which a program (also referred to as code, or instruction) is stored. When the program is run, the method in the above-mentioned first aspect and any possible implementation of the first aspect is executed.

[0032] In a sixth aspect, a program product is provided, comprising: a program (also referred to as code, or instruction), which, when run, enables the method in the above-mentioned first aspect and any possible implementation of the first aspect to be executed.

[0033] It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] FIG1 is a schematic diagram of a structure of a terminal device applicable to the method for managing system services provided in an embodiment of the present application;

[0035] FIG2 is a structural block diagram of software for a terminal device applicable to the method for managing system services provided in an embodiment of the present application;

[0036] 3 is another structural block diagram of software for a terminal device applicable to the method for managing system services provided in an embodiment of the present application;

[0037] FIG4 is a schematic flow chart of a method for managing system services provided in an embodiment of the present application;

[0038] FIG5 is a schematic diagram of various triggering methods for changing the status of system services provided in an embodiment of the present application;

[0039] FIG6 is a schematic diagram of an application process calling a system service according to an embodiment of the present application;

[0040] 7 is a schematic diagram of obtaining a call count of a first system service according to an embodiment of the present application;

[0041] FIG8 is a schematic diagram of a detection system event provided by an embodiment of the present application;

[0042] Figure 9 is a schematic diagram of the system service declaration to start silent operation and the declaration to end silent operation provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The technical solution in this application will be described below with reference to the accompanying drawings.

[0044] First, in the embodiments of the present application, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a device, system, product or equipment that includes a series of modules, modules or units is not necessarily limited to those modules, modules or units clearly listed, but may include other modules, modules or units that are not clearly listed or inherent to these devices, systems, products or equipment.

[0045] Second, in the embodiments of this application, "and / or" describes the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects are in an "or" relationship, but it does not exclude the possibility of indicating an "and" relationship between the associated objects. The specific meaning of the symbol should be understood in the context.

[0046] Third, in this application, "when...", "in the case of...", "if" and "if" all mean that the device will take corresponding actions under certain objective circumstances, which does not limit the time, nor does it require that the device must perform judgment actions when it is implemented, nor does it mean that there are other limitations.

[0047] System services are programs, routines, or processes that perform designated system functions to support other programs, especially low-level (hardware-based) programs. Alternatively, system services encapsulate basic application-oriented system capabilities, such as application process management, component management, window management, installation package management, phone management, network management, distributed communications, and so on, providing APIs to applications. The operating system of a terminal device includes many system services, some of which must be running at all times when the terminal device is operating normally. For example, these include but are not limited to system services related to power management, screen display, or application processes. These system services can be referred to as basic system services. Other system services do not need to be running at all times when the terminal device is operating normally, such as but not limited to Bluetooth services, phone services, or upgrade services. These system services can be referred to as non-basic system services.

[0048] In current operating systems, as long as a terminal device is powered on, regardless of whether the system services in the terminal device's operating system are active, each service system will occupy a certain amount of system resources, resulting in a certain amount of resource waste. However, it is currently impossible to accurately determine the status of each system service, and thus it is impossible to manage the system resources corresponding to each system service based on the status of each system service. Therefore, how to accurately determine the status of each system service has become a technical problem that needs to be solved urgently.

[0049] In order to solve the above problems, the present application provides a method and related devices for managing system services. By obtaining the calling situation of non-basic system services, the occurrence of events related to non-basic system services, and the silent running status of non-basic system services, the status of non-basic system services can be judged, for example, whether they are in working state or idle state, so as to accurately judge the status of each system service.

[0050] Before describing in detail the method for managing system services provided by an embodiment of the present application, an exemplary description of a terminal device applicable to an embodiment of the present application is first given in conjunction with Figures 1, 2 and 3.

[0051] The method for managing system services provided in the embodiments of the present application can be applied to mobile phones, tablet computers, smart TVs, smart screens, smart watches, wearable devices, vehicle-mounted devices, laptop computers, personal computers (PCs), ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), distributed devices and the like. The embodiments of the present application do not impose any restrictions on the specific type of device. Among them, the device may also be referred to as user equipment (UE), mobile device, user terminal, wireless communication device, or user device, etc., and the embodiments of the present application do not impose any restrictions on this.

[0052] In addition, the methods described in the embodiments of the present application can support operating systems such as the Android operating system (Android OS), Harmony OS, OpenHarmony OS, iOS, Windows OS, and lightweight operating systems (such as LiteOS). The embodiments of the present application do not impose any limitations on this.

[0053] FIG1 is a schematic structural diagram of a terminal device applicable to the method for managing system services provided in an embodiment of the present application.

[0054] For example, FIG1 shows a schematic structural diagram of a terminal device 100. As shown in FIG1 , the terminal device 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 194, and a subscriber identification module (SIM) card interface 195. 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 and a bone conduction sensor 180M, etc.

[0055] The processor 110 may include one or more processing units. For example, the processor 110 may include one or more of an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0056] The application processor outputs sound signals through the audio module 170 (such as the speaker 170A, etc.), or displays images or videos through the display screen 194.

[0057] The controller can be the nerve center and command center of the terminal device 100. The controller can generate operation control signals according to instruction operation codes and timing signals to complete the control of instruction fetching and execution.

[0058] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0059] The processor 110 can perform different operations to implement different functions by executing instructions. The instructions can be, for example, instructions pre-stored in the memory before the device leaves the factory, or instructions read from the APP after the user installs a new APP during use. This embodiment of the application does not impose any restrictions on this.

[0060] In some embodiments, the processor 110 may include one or more interfaces. The interfaces 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 interface, and / or a USB interface.

[0061] The USB interface 130 is an interface that complies with the USB standard specification, and specifically 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 terminal device 100, and can also be used to transmit data between the terminal device 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 devices, such as augmented reality (AR) devices, etc. It will be understood that the interface connection relationship between the modules illustrated in this application is only a schematic illustration and does not constitute a structural limitation on the terminal device 100. In other embodiments, the terminal device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0062] The charging management module 140 is configured to receive charging input from a charger. The charger can be either a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 can receive charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 can receive wireless charging input via the wireless charging coil of the terminal device 100. While charging the battery 142, the charging management module 140 can also provide power to the terminal device 100 via the power management module 141.

[0063] 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 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module 141 can also be provided in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be provided in the same device.

[0064] The wireless communication function of the terminal device 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.

[0065] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0066] The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G applied on the terminal device 100.

[0067] The wireless communication module 160 can provide wireless communication solutions applied to the terminal device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC) technology, infrared (IR) technology, etc.

[0068] In some embodiments, antenna 1 of terminal device 100 is coupled to mobile communication module 150 , and antenna 2 is coupled to wireless communication module 160 , so that terminal device 100 can communicate with the network and other devices through wireless communication technology.

[0069] The terminal device 100 can implement display functions through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that 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.

[0070] Display screen 194, also referred to as a screen, can be used to display images, videos, and the like. It should be understood that display screen 194 may also include additional components, such as a backlight panel and a driver circuit. The backlight panel can be used to provide a light source, and the display panel emits light based on the light provided by the backlight panel. The driver circuit can be used to control the light transmission or opacity of the liquid crystal layer.

[0071] The terminal device 100 can realize the shooting function through the ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0072] 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 terminal device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0073] The internal memory 121 can be used to store device executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the terminal device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can 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 can store data created during the use of the terminal device 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, etc.

[0074] The terminal device 100 can implement audio functions such as music playback and recording through the audio module 170, such as the speaker 170A, the receiver 170B, the microphone 170C and the headphone jack 170D, and the application processor.

[0075] It should be understood that the structure illustrated in this application does not constitute a specific limitation on the terminal device 100. In other embodiments, the terminal device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0076] The software system of the terminal device 100 can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. The layered architecture divides the software system of the terminal device 100 into several layers, each layer having a clear role and division of labor, and the layers communicate with each other through software interfaces. This application uses operating systems such as OpenHarmony OS and Android with layered architecture as examples to illustrate the software structure of the terminal device 100, but should not limit the type of operating system of the terminal device used in the method for managing system services provided in the embodiments of this application.

[0077] FIG2 is a structural block diagram of software of a terminal device applicable to the method for managing system services provided in an embodiment of the present application.

[0078] As shown in Figure 2, in some embodiments, the operating system is divided into four layers, namely, the application layer, the framework layer, the system service layer, and the kernel layer, from top to bottom. In some embodiments, the terminal device 100 also includes hardware, such as a GPU, a central processing unit (CPU), a display screen, etc.

[0079] The application layer includes a range of applications. As shown in Figure 2, the application layer can include both system applications and third-party applications. System applications can be understood as applications that come with the system, such as camera, gallery, calendar, call, map, Bluetooth, video, and music. Third-party applications can be understood as non-system applications that can be downloaded and installed from app stores or app markets.

[0080] Not shown in Figure 2, the framework layer can include a user interface (UI) framework, a user program framework, and a component framework. The framework layer provides operating system applications with a user program framework and component framework in multiple languages, such as C, C++, and JavaScript (JS), as well as APIs for various software and hardware services. It also provides devices with a UI framework in multiple languages, such as C, C++, and JS. The APIs supported by different devices are related to the degree of componentization of the system.

[0081] The system service layer is a collection of core capabilities of the operating system, which provides various system services to applications through the framework layer. In an embodiment of the present application, the system service layer may also include a system service management module, which can be used to determine the status of non-basic system services based on one or more of the three items by obtaining the circumstances in which non-basic system services are called, the occurrence of events related to non-basic system services, and the silent operation of non-basic system services. For a detailed description of the system service management module, please refer to the relevant description below. For the sake of brevity, it will not be repeated here.

[0082] Not shown in FIG2 , the system service layer may include a system basic capability subsystem set, a basic software service subsystem set, an enhanced software service subsystem set, and a hardware service subsystem set.

[0083] Among them, the system basic capability subsystem set can be composed of subsystems such as distributed soft bus and distributed data management. The system basic capability subsystem set can provide basic capabilities for the operation, scheduling, migration and other operations of distributed applications on multiple devices.

[0084] The basic software service subsystem set can be composed of event notification, telephone, multimedia and other subsystems, and can provide public and general software services.

[0085] The enhanced software service subsystem set can be composed of subsystems such as smart screen proprietary business, wearable proprietary business, and Internet of Things (IoT) proprietary business, and can provide differentiated capability-enhanced software services for different devices.

[0086] The hardware service subsystem set can be composed of subsystems such as location services, biometric recognition, wearable proprietary hardware services, IoT proprietary hardware services, etc., and can provide hardware services.

[0087] It should be noted that, depending on the deployment environment of different device forms, the basic software service subsystem set, the enhanced software service subsystem set, and the hardware service subsystem set can be tailored at the subsystem granularity, and each subsystem can be tailored at the functional granularity. This embodiment of the application does not impose any limitation on this.

[0088] Not shown in Figure 2, the kernel layer includes a kernel subsystem and a driver subsystem. The operating system can adopt a multi-kernel design. Based on the kernel subsystem, the operating system supports the selection of appropriate OS kernels for different resource-constrained devices. The kernel abstraction layer (KAL) shields the differences between multiple kernels and provides basic kernel capabilities to upper layers, including process / thread management, memory management, file system, network management, and peripheral management. The driver framework in the driver subsystem is the foundation of the operating system's open hardware ecosystem, providing unified peripheral access capabilities and a driver development and management framework.

[0089] FIG3 is another structural block diagram of software of a terminal device applicable to the method for managing system services provided in an embodiment of the present application.

[0090] As shown in FIG3 , in some embodiments, the Android operating system is divided from top to bottom into an application layer, an application framework layer, an Android runtime (Android runtime), a system library, and a kernel layer.

[0091] In some embodiments, the terminal device 100 also includes hardware, such as a GPU, a CPU, a display screen, etc.

[0092] The application layer can include a range of applications. As shown in Figure 3, the application layer can include system applications and third-party applications. System applications can be understood as applications that come with the system, such as camera, gallery, calendar, call, map, Bluetooth, video, and music applications. Third-party applications can be understood as non-system applications that can be downloaded and installed from the app store.

[0093] The application framework layer provides an API and programming framework for applications in the application layer. The application framework layer includes some predefined functions. As shown in Figure 3, the application framework layer may include, among other things, a system service management module. A detailed description of the system service management module can be found in Figure 2 and will not be repeated here for the sake of brevity.

[0094] 3 , the Android runtime may include a core library and a virtual machine. The Android runtime is responsible for scheduling and management of the Android operating system.

[0095] The core library can contain two parts: one part is the functional functions that need to be called by the Java language, and the other part is the core library of the Android operating system.

[0096] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0097] Not shown in Figure 3 , the system library may include multiple functional modules, such as a status monitoring service, a surface manager, media libraries, a 3D graphics processing library (e.g., OpenGL ES), and a 2D graphics engine (e.g., SGL).

[0098] The kernel layer is the layer between hardware and software. Not shown in Figure 3, the kernel layer may include power management services, sensor services (also known as sensor drivers), display services (also known as display drivers), camera drivers, audio drivers, etc. This embodiment of the application does not impose any restrictions on this.

[0099] In an embodiment of the present application, as shown in FIG. 2 or FIG. 3 , the terminal device may include a system service management module so that the terminal device has the ability to implement the method for managing system services provided in the present application.

[0100] It should be understood that FIG1 , FIG2 and FIG3 are merely examples and should not limit the embodiments of the present application in any way.

[0101] FIG4 is a schematic flowchart of a method for managing system services provided in an embodiment of the present application.

[0102] As shown in Figure 4, method 400 may include steps 410 to 440. The steps of method 400 may be performed by a terminal device, or the method 400 may be performed by a component configured in the terminal device (such as a chip, a chip system, etc.), or may be implemented by a logic module or software that can realize all or part of the functions of the terminal device, which is not limited in this embodiment of the present application. The terminal device may have a structure as shown in Figure 1, Figure 2 or Figure 3, which is not limited in this embodiment of the present application. The steps in Figure 4 are described in detail below.

[0103] In step 410, the calling status of the first system service is obtained.

[0104] It is understood that the first system service is any system service in the non-basic system service. Non-basic system services are system services other than the preset basic system services. For the relevant description of basic system services and non-basic system services, please refer to the relevant content above. For the sake of brevity, it will not be repeated here.

[0105] In step 420, the occurrence of one or more events related to the first system service is obtained.

[0106] The one or more events are configured in a configuration file corresponding to the first system service. Whether the occurrence of any of the one or more events triggers the first system service to run or terminate is also configured in the configuration file corresponding to the first system service.

[0107] In step 430, the status of the silent operation is obtained.

[0108] The silent operation state includes being in silent operation or not being in silent operation.

[0109] In an embodiment of the present application, a system service can proactively declare to start silent operation or proactively declare to end silent operation. If the first system service declares to start silent operation but does not declare to end silent operation, the state of the silent operation is in silent operation; or, if the first system service declares to end silent operation or has never declared to start silent operation, the state of the silent operation is not in silent operation.

[0110] The terminal device can use the system service management module shown in Figure 2 or Figure 3 to obtain the call status of the first system service, the occurrence status of one or more events related to the first system service, and the silent operation status of the first system service. In other words, the system service management module provided by this application can have the ability to obtain the call status of the first system service, the occurrence status of one or more events related to the first system service, and the silent operation status of the first system service.

[0111] FIG5 is a schematic diagram of various triggering methods for changing the status of system services provided in an embodiment of the present application.

[0112] As shown in FIG. 5 , in the method for managing system services provided in the embodiment of the present application, a variety of triggering methods that can change the system service status are comprehensively considered.

[0113] The first triggering method: the application process (including system applications and third-party application processes) calls the system service.

[0114] An application process can call one or more system services, and a system service can also be called by one or more application processes. When an application process calls a first system service, the first system service will run, that is, the first system service will enter the working state. For example, some application processes can call the camera service to implement functions related to the camera service (including but not limited to the photo or video recording function).

[0115] The second triggering method: the occurrence of events related to system services.

[0116] A system service may correspond to one or more related events. One or more events related to the first system service are pre-configured, and the occurrence of any of the one or more events triggers the first system service to run or end, which is also pre-configured. As an example and not a limitation, each system service may correspond to a configuration file, in which one or more events related to the system service are configured, and the occurrence of any of these events is configured to trigger the system service to run or to end. For example, networking events and network disconnection events are related to network services. When a networking event occurs, the network service can be triggered to run; when a network disconnection event is triggered, the network service can be triggered to end.

[0117] The third triggering method: the system service can actively declare to start silent operation, and can also actively declare to end silent operation.

[0118] In the method for managing system services provided in the embodiment of the present application, an interface for declaring the start of silent operation and the end of silent operation is provided for the system service. When the system service needs to run silently, the system service can actively declare the start of silent operation through the above interface, so that the system service can enter the working state; when the system service wants to end silent operation, the system service can actively declare the end of silent operation through the above interface, so that the system service can end silent operation. For example, when the upgrade service needs to run silently, the upgrade service can actively declare the start of silent operation through the above interface; after the upgrade is completed, the system service can actively declare the end of silent operation through the above interface.

[0119] Therefore, considering the above three triggering methods, the terminal device can use the system service management module to execute any step from step 410 to step 430.

[0120] For example, the terminal device may utilize the system service management module to perform step 410 above. That is, the terminal device may utilize the system service management module to obtain information about the first system service being called, and then subsequently determine whether the first system service is in an active state based on the information about the first system service being called. If the first system service is called by at least one application process, it may be determined that the first system service is in an active state. If no application process calls the first system service, the first system service does not necessarily enter an idle state, and other factors may be used to determine whether the first system service is in an idle state.

[0121] For another example, the terminal device can use the system service management module to perform the above step 420, that is, the terminal device can use the system service management module to obtain the occurrence of one or more events related to the first system service. That is to say, when a certain event occurs, the terminal device can determine whether the event is related to the first system service based on the configuration file corresponding to the first system service. If the event is related to the first system service, based on the configuration file, it can be determined whether the occurrence of the event triggers the operation of the first system service or triggers the end of the operation of the first system service. In the case where it is determined that the occurrence of the event triggers the operation of the first system service, it can be determined that the state of the first system service is a working state. In the case where it is determined that the occurrence of the event triggers the end of the operation of the first system service, the first system service does not necessarily enter the idle state, and other aspects can be combined to determine whether the first system service enters the idle state.

[0122] For another example, the terminal device can use the system service management module to perform the above step 430, that is, the terminal device can use the system service management module to obtain the state of the silent operation of the first system service. That is, when the first system service needs to run silently, the first system service can actively report to the system service management module to start the silent operation, so that the system service management module knows that the first system service has entered the working state; when the first system service wants to end the silent operation, the first system service can actively report to the system service management module to end the silent operation, so that the first system service can end the silent operation, but the first system service does not necessarily enter the idle state, and other aspects can be combined to determine whether the first system service is in the idle state. That is, when the first system service reports to start the silent operation but does not report to end the silent operation, the state of the silent operation is in silent operation; or, when the first system service reports to end the silent operation, or has never reported to start the silent operation, the state of the silent operation is not in silent operation. When the silent operation state is not in silent operation, the first system service does not necessarily enter the idle state, and it can be determined in combination with other aspects whether the first system service is in the idle state.

[0123] It is understandable that the present application does not impose any limitation on the execution order of step 410, step 420 and step 430, that is, step 410, step 420 and step 430 can be executed simultaneously or at different times, and the present application does not impose any limitation on this.

[0124] In step 440 , the state of the first system service is determined based on the calling condition, the occurrence of the one or more events, and the state of the silent operation.

[0125] The state of the first system service includes a working state or an idle state. The first system service being in the working state can be understood as the first system service being running; the first system service being in the idle state can be understood as the first system service not being running.

[0126] The terminal device may utilize the system service management module to determine the status of the first system service based on the calling status of the first system service, the occurrence status of the one or more events, and the silent running status of the first system service.

[0127] In one possible implementation, the status of the first system service is determined based on the calling situation, the occurrence of the one or more events and the state of the silent operation, including: when the first system service is called, or when the occurrence of any one of the one or more events triggers the operation of the first system service, or when the state of the silent operation is in silent operation, determining that the state of the first system service is a working state.

[0128] When the calling condition is called, that is, when the first system service is called by at least one application process, the terminal device may determine that the state of the first system service is a working state.

[0129] In a case where the occurrence of any one of the one or more events related to the first system service triggers the running of the first system service, the terminal device may determine that the state of the first system service is a working state.

[0130] When the silent operation state of the first system service is in silent operation, that is, when the first system service actively declares to start silent operation but has not yet declared to end silent operation, it can be determined that the state of the first system service is working state.

[0131] That is, the terminal device can determine whether the status of the first system service is in a working state based on any one of the calling status of the first system service, the occurrence of the one or more events, or the silent running status of the first system service.

[0132] In one possible implementation, the status of the first system service is determined based on the calling status of the first system service, the occurrence status of the one or more events, and the silent running status, including: when the first system service is not called, and the occurrence of any one of the one or more events triggers the termination of the operation of the first system service or no event of the one or more events occurs, and the first system service declares the termination of silent operation or the first system service does not declare the start of silent operation, determining that the status of the first system service is an idle state.

[0133] When the called condition is not called (that is, the first system service is not called by any application process), and the occurrence of any one of the one or more events related to the first system service triggers the termination of the first system service or none of the one or more events occurs, and the silent operation is not in dynamic silent operation, the terminal device can determine that the state of the first system service is idle.

[0134] That is, the terminal device can determine whether the state of the first system service is idle based on the calling state of the first system service, the occurrence of the one or more events, and the silent running state of the first system service.

[0135] In one possible implementation, step 410 of the above method 400, obtaining the calling status of the first system service, includes: obtaining a calling count of the first system service; when the calling count is zero, determining that the calling status is not called; or, when the calling count is greater than zero, determining that the calling status is called.

[0136] Figure 6 is a schematic diagram of an application process calling a system service according to an embodiment of the present application. In order to better understand the method for managing system services according to an embodiment of the present application, the process of an application calling a system service is briefly described below with reference to Figure 6.

[0137] Step 1: The application process queries the system service.

[0138] As shown in FIG6 , when an application process of a system application and / or an application process of a third-party application needs to call a certain system service, the application process may first query the system service management module for the system service.

[0139] Step 2: The system service management module loads the system service.

[0140] The system service management module may load the system service in response to a query of the application process for the system service.

[0141] Step 3: The system service management module returns the system service.

[0142] When the system service management module is loaded into the corresponding system service, it can return the system service to the application process.

[0143] Step 4: The application process calls the system service.

[0144] The application process can call the corresponding system service according to the system service returned by the system service management module.

[0145] FIG7 is a schematic diagram of obtaining a call count of a first system service provided in an embodiment of the present application.

[0146] Each service component corresponds to a server node in the Binder driver, that is, a Binder entity object. As shown in Figure 7, the service component of the first system service corresponds to a server node in the kernel space.

[0147] Each client component in the Binder driver corresponds to a server reference, also known as a Binder reference object. As shown in Figure 7, the client component a proxy corresponds to a server reference in kernel space, and the client component b proxy also corresponds to a server reference in kernel space.

[0148] As shown in Figure 7, in the user space, the client a component agent calls the first system service through the process object a. The mapping in the kernel space is the reference relationship between the server reference corresponding to the client a component agent in the kernel space and the server node corresponding to the service component of the first system service in the kernel space; similarly, in the user space, the client b component agent calls the first system service through the process object b. The mapping in the kernel space is the reference relationship between the server reference corresponding to the client b component agent in the kernel space and the server node corresponding to the service component of the first system service in the kernel space.

[0149] The terminal device can use the system service management module to obtain and count the number of references to the server node corresponding to the service component of the first system service in the kernel space, that is, the number of server references associated with the server node, which is also the call count of the first system service. When the call count is zero, the terminal device can determine that the call situation is not called, that is, the first system service is not called; or, when the call count is greater than zero, the terminal device can determine that the call situation is called, that is, the first system service is called. As mentioned above, when the first system service is called, the first system service is in a working state; but when the first system service is not called, the first system service is not necessarily in an idle state.

[0150] In a possible implementation, step 420 of the method 400 , obtaining the occurrence of an event related to the first system service, includes: detecting the event related to the first system service.

[0151] FIG8 is a schematic diagram of a detection system event provided in an embodiment of the present application.

[0152] As shown in Figure 8, the terminal device can use the system service management module to detect system events (hereinafter referred to as events). System events may include but are not limited to Internet access events, network events, network disconnection events, etc. as shown in the figure. When a certain event occurs, the system service management module of the terminal device can receive a notification message about the occurrence of the event. Thus, the system service management module can determine whether the event is related to the first system service based on the pre-configured and stored configuration file of the first system service. When the event is related to the first system service, based on the configuration file, it is determined whether the occurrence of the event triggered the operation of the first system service or triggered the termination of the operation of the first system service. When it is determined that the occurrence of the event triggered the operation of the first system service, it can be determined that the state of the first system service is a working state. When it is determined that the occurrence of the event triggered the termination of the operation of the first system service, the first system service does not necessarily enter the idle state. It can also be determined in combination with other aspects whether the first system service enters the idle state. For example, taking network service as an example of the first system service, related events of the network service may include networking events. For example, the configuration file is configured to trigger the operation of the network service when an Internet event occurs. Based on the configuration file, when a networking event occurs, the terminal device can determine that the network service enters the working state.

[0153] Figure 9 is a schematic diagram of the system service declaration to start silent operation and the declaration to end silent operation provided in an embodiment of the present application.

[0154] In step 430 of the above method 400, the state of the silent operation of the first system service is obtained. The premise of this step is that the system service management module can provide the system service with an interface for declaring the start of silent operation and the end of silent operation. As shown in Figure 9, when the system service needs to run silently, the system service can actively declare the start of silent operation through the above interface. In this way, the system service management module knows when the system service started silent operation and entered the working state; when the system service wants to end silent operation, the system service can actively declare the end of silent operation through the above interface. In this way, the system service management module knows when the system service ended silent operation.

[0155] In a possible implementation, the method 400 further includes: updating a status identifier according to the most recently determined status of the first system service, where the status identifier is used to record the status of the first system service.

[0156] That is, after determining the status of the first system service for the most recent time, the terminal device may utilize the system service management module to record the status of the first system service.

[0157] In one possible implementation, the status identifier is updated according to the most recently determined status of the first system service, including: when the status identifier is empty or the recorded status of the first system service is a working status, when the most recently determined called status is not called, and no event among the one or more events occurs or the occurrence of any event among the one or more events triggers the termination of the operation of the first system service, and when the silent operation status is not in silent operation, the status identifier is updated to an idle state.

[0158] That is to say, after the terminal device is started and running, when the status identifier is empty or the status of the first system service has been determined and recorded to be in the working state, the system service management module continuously obtains the calling status of the first system service, the occurrence of one or more events related to the first system service, and the silent running status of the first system service. When the calling status is last determined to be not called, and no event occurs in one or more events related to the first system service or the occurrence of any of the one or more events triggers the termination of the first system service, and the first system service has never declared the start of silent operation or declared the end of silent operation, the terminal device can use the system service management module to update the status of the first system service to the idle state.

[0159] In one possible implementation, the status identifier is updated according to the most recently determined status of the first system service, including: when the status identifier is empty or the recorded status of the first system service is idle, when the last call situation is determined to be called, or when the occurrence of any one or more events triggers the operation of the first system service, or when the silent operation state is in silent operation, the status identifier is updated to the working state.

[0160] That is to say, after the terminal device is started and running, when the status identifier is empty or the status of the first system service has been determined and recorded to be idle, the system service management module continuously obtains the call status of the first system service, the occurrence of events related to the first system service, and the silent operation status of the first system service. When the call status is determined to be called for the last time, the terminal device can use the system service management module to update the status of the first system service to a working state; or, when the occurrence of any event in the most recent event determined to be related to the first system service triggers the operation of the first system service, the terminal device can use the system service management module to update the status of the first system service to a working state; or, when the first system service actively reported to the system service management module the start of silent operation for the last time, but did not report the end of silent operation, the terminal device can use the system service management module to update the status of the first system service to a working state.

[0161] In a possible implementation, the method 400 further includes: when the state of the first system service is an idle state, releasing system resources occupied by the first system service.

[0162] When the first system service is in an idle state, the terminal device may release the system resources corresponding to the first system service to avoid wasting the system resources so that other system services or application processes can utilize these system resources.

[0163] Based on the above scheme, the terminal device obtains the calling situation of non-basic system services, the occurrence of events related to non-basic system services, and the silent running status of non-basic system services, and combines the above three items to determine the status of non-basic system services, for example, whether it is in working state or idle state, so as to accurately determine the status of each system service. In addition, the terminal device modifies the status of each system service in real time according to the above three situations. Furthermore, under the premise of being able to grasp the status of each system service in real time, the terminal device can manage the system resources corresponding to each system service based on the status of each system service. For example, when the first system service is in an idle state, the terminal device can release the system resources corresponding to the first system service to avoid wasting system resources, so that other system services or application processes can use this part of the system resources.

[0164] The embodiment of the present application further provides a terminal device, which includes corresponding modules for executing the steps in any of the embodiments in Figures 4 to 9. The modules included in the terminal device can be implemented in software and / or hardware.

[0165] An embodiment of the present application also provides a terminal device, which includes a memory and a processor, wherein the memory is used to store programs, and the processor is used to call and execute programs, so that the terminal device performs the steps in any one of the embodiments in Figures 4 to 9 above.

[0166] The present application also provides a chip system, which includes at least one processor for implementing the functions involved in the steps of any one of the embodiments in Figures 4 to 9 above.

[0167] In one possible design, the chip system further includes a memory, which is used to store program instructions and data, and the memory is located inside or outside the processor.

[0168] The chip system can be composed of chips, or can include chips and other discrete devices.

[0169] An embodiment of the present application further provides a readable storage medium on which a program is stored. When the program is executed by a terminal device, the terminal device executes the steps in any one of the embodiments in Figures 4 to 9 above.

[0170] An embodiment of the present application also provides a program product, including a program. When the program is executed by a terminal device, the terminal device executes the steps in any one of the embodiments in Figures 4 to 9 above.

[0171] It should be understood that the processor in the embodiments of the present application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above-mentioned method embodiment can be completed by hardware integrated logic circuits in the processor or by software instructions. The above-mentioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above-mentioned method.

[0172] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories.

[0173] The terms "unit", "module", etc. used in this specification may be used to represent device-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution.

[0174] Those skilled in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, or a combination of software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed devices, equipment, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the module division is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not implemented. In addition, the coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, and can be electrical, mechanical, or other forms.

[0175] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of the present embodiment according to actual needs.

[0176] In addition, the functional modules in the various embodiments of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more units may be integrated into one module.

[0177] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device to execute all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0178] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for managing system services, characterized in that: include: Acquiring a calling status of a first system service, where the first system service is a system service other than a preset basic system service; Acquire occurrence of one or more events related to the first system service, where the one or more events are configured in a configuration file corresponding to the first system service; Obtaining the silent running status of the first system service; Based on the calling situation, the occurrence of the one or more events and the silent running state, the state of the first system service is determined, where the state includes a working state or an idle state.

2. The method according to claim 1, characterized in that The determining the state of the first system service based on the calling situation, the occurrence of the one or more events and the silent running state includes: When the first system service is called, or when the occurrence of any one of the one or more events triggers the operation of the first system service, or when the silent operation state is in silent operation, it is determined that the state of the first system service is a working state.

3. The method according to claim 1, characterized in that The determining the state of the first system service based on the calling situation, the occurrence of the one or more events and the silent running state includes: When the first system service is not called, and the occurrence of any one of the one or more events triggers the termination of the operation of the first system service or no event of the one or more events occurs, and the state of the silent operation is not in silent operation, it is determined that the state of the first system service is an idle state.

4. The method according to any one of claims 1 to 3, characterized in that The obtaining of the calling status of the first system service includes: Obtaining a call count of the first system service; When the called count is zero, determining that the called status is not called; or, When the called count is greater than zero, the called situation is determined to be called.

5. The method according to any one of claims 1 to 4, characterized in that The obtaining of occurrence of one or more events related to the first system service includes: The one or more events related to the first system service are detected.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: According to the most recently determined state of the first system service, a state identifier is updated, where the state identifier is used to record the state of the first system service.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: When the state of the first system service is an idle state, system resources occupied by the first system service are released.

8. The method according to any one of claims 1 to 7, characterized in that The silent operation state includes being in silent operation or not in silent operation, and, When the first system service declares to start the silent operation but does not declare to end the silent operation, the state of the silent operation is in silent operation; or, When the first system service declares to end the silent operation, or has never declared to start the silent operation, the state of the silent operation is not in silent operation.

9. A terminal device, characterized in that: comprising a processor and a memory, wherein: The memory is used to store programs; The processor is used to call the program so that the terminal device executes the method according to any one of claims 1 to 8.

10. A readable storage medium having a program stored thereon, characterized in that: When the program is executed, the terminal device executes the method according to any one of claims 1 to 8.

11. A program product, characterized in that The method comprises a program, which, when being executed, causes a terminal device to execute the method according to any one of claims 1 to 8.

Images