System service management method and related device

Abstract

The invention provides a system service management method and a related device, and the method comprises the steps: obtaining a called condition of a first system service, the first system service being a system service except a preset basic system service; acquiring occurrence conditions 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; obtaining a silent operation state of the first system service; based on the called condition, the occurrence condition of the one or more events and the silent operation state, the state of the first system service is determined, and 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 judged.

Description

A method and related apparatus for managing system services

[0001] This application claims priority to Chinese Patent Application No. 202311224555.X, filed on September 19, 2023, entitled “A Method and Related Apparatus for a Management System Service”, the entire contents of which are incorporated herein by reference.

[0002] This application relates to the field of terminal technology, and in particular to a method and related apparatus for managing system services.

[0003] System services are programs, routines, or processes that perform specified system functions to support other programs, especially low-level (close to hardware) programs. In other words, system services encapsulate application-oriented basic system capabilities, such as application process management, component management, window management, installation package management, telephone management, network management, distributed communication, etc., providing application programming interfaces (APIs) to applications.

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

[0005]

[0006] This application provides a method and related apparatus for managing system services, with the aim of accurately determining the status of each system service.

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

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

[0009] Based on the above scheme, by obtaining the invocation status 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 determined based on these three items, such as whether they are in a working state or an idle state, thereby accurately determining the status of each system service.

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

[0011] In conjunction with the first aspect, in some possible implementations, if the first system service has declared the start of silent operation but has not declared the end of silent operation, the state of the silent operation is silent operation; or, if the first system service has declared the end of silent operation, or has never declared the start of silent operation, the state of the silent operation is not silent operation.

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

[0013] In conjunction with the first aspect, in some possible implementations, the state of the first system service is determined based on the invocation status, the occurrence of the one or more events, and the silent operation status, including: determining the state of the first system service as working when the first system service is invoked, or when the occurrence of any of the one or more events triggers the operation of the first system service, or when the silent operation status is in silent operation.

[0014] In other words, the terminal device can determine whether the first system service is in a working state based on any one of the following: the invocation status, the occurrence of one or more events, or the silent operation status of the first system service.

[0015] In conjunction with the first aspect, in some possible implementations, the state of the first system service is determined based on one or more of the following: the invocation status of the first system service, the occurrence of one or more events, and the silent running state. This includes determining the state of the first system service as idle when the first system service is not invoked, the occurrence of any of the one or more events triggers the termination of the first system service or no event occurs in the one or more events, and the silent running state is not in silent running.

[0016] In other words, by combining the call status of the first system service, the occurrence status of one or more events, and the silent running status of the first system service, the terminal device can determine whether the first system service is in an idle state.

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

[0018] In conjunction 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 conjunction with the first aspect, in some possible implementations, the method further includes: updating a status identifier based on the most recently determined status of the first system service, the status identifier being used to record the status of the first system service.

[0020] Terminal devices can not only use status identifiers to record the status of various system services, but also modify the status of various system services.

[0021] In conjunction with the first aspect, in some possible implementations, the status identifier is updated based on the most recently determined state of the first system service, including: if the status identifier is empty or the recorded state of the first system service is working, if the most recently determined call condition is not called, and if no event occurs in the one or more events or the occurrence of any of the one or more events triggers the termination of the first system service, and if the silent running state is not in silent running, the status identifier is updated to idle state.

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

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

[0024] With knowledge of 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 idle, the terminal device can release the system resources corresponding to the first system service to avoid wasting system resources and allow other system services or application processes to utilize these system resources.

[0025] Secondly, this application provides a terminal device that can be used to implement the methods in the first aspect and any possible implementation thereof. The terminal device includes corresponding modules for performing the above-described methods. The modules included in the terminal device can be implemented in software and / or hardware.

[0026] Thirdly, this application provides a terminal device that includes at least a processor and at least one communication interface. The processor is coupled to the communication interface and can be used to execute programs to implement the method of managing system services in the first aspect and any possible implementation of the first aspect.

[0027] Optionally, the terminal device also includes a memory, with the processor coupled to the memory.

[0028] Fourthly, this application provides a chip system including at least one processor for supporting the functions involved in implementing the first aspect and any possible implementation of the first aspect, such as processing data involved in the above method.

[0029] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located inside or outside the processor.

[0030] The chip system can consist of chips or include chips and other discrete components.

[0031] Fifthly, a readable storage medium is provided, on which a program (also referred to as code or instructions) is stored, which, when run, causes the methods of the first aspect and any possible implementation thereof to be executed.

[0032] In a sixth aspect, a program product is provided, the program product comprising: a program (also referred to as code or instructions), which, when run, causes the methods of the first aspect and any possible implementation thereof to be executed.

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

[0034] Figure 1 is a schematic diagram of a terminal device for a method of providing management system services according to an embodiment of this application;

[0035] Figure 2 is a structural block diagram of the software of a terminal device for a method of providing management system services applicable to embodiments of this application;

[0036] Figure 3 is another structural block diagram of the software of a terminal device for a method of providing management system services applicable to embodiments of this application;

[0037] Figure 4 is a schematic flowchart of a method for providing management system services according to an embodiment of this application;

[0038] Figure 5 is a schematic diagram of various triggering methods for changing the state of system services provided in the embodiments of this application;

[0039] Figure 6 is a schematic diagram of an application process calling system services according to an embodiment of this application;

[0040] Figure 7 is a schematic diagram of obtaining the call count of the first system service provided in an embodiment of this application;

[0041] Figure 8 is a schematic diagram of the detection system events provided in an embodiment of this application;

[0042] Figure 9 is a schematic diagram of the system service application starting silent operation and ending silent operation provided in the embodiment of this application.

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

[0044] First, in the embodiments of this application, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, an apparatus, system, product or device that includes a series of modules, units or units is not necessarily limited to those modules, units or units that are explicitly listed, but may include other modules, units or units that are not explicitly listed or that are inherent to such apparatus, system, product or device.

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

[0046] Third, in this application, "when," "under the circumstances," "if," and "if" all refer to the device making a corresponding action under certain objective circumstances, and are not time-limited, nor do they require the device to make a judgment when it is implemented, nor do they imply any other limitations.

[0047] System services are programs, routines, or processes that perform specified system functions to support other programs, especially low-level (close to hardware) programs. In other words, system services encapsulate application-oriented basic system capabilities, such as application process management, component management, window management, installation package management, telephone management, network management, distributed communication, etc., providing APIs to applications. The operating system of a terminal device includes many system services. Some of these system services must be constantly running while the terminal device is operating normally, such as, but not limited to, some system services related to power management, some related to screen display, or some related to application processes; these can be called basic system services. Other system services do not need to be constantly running while the terminal device is operating normally, such as, but not limited to, Bluetooth services, telephone services, or upgrade services; these can be called non-basic system services.

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

[0049] To address the aforementioned issues, this application provides a method and related apparatus for managing system services. By acquiring information on the invocation status of non-basic system services, the occurrence of events related to non-basic system services, and the silent operation status of non-basic system services, the state of non-basic system services can be determined, such as whether they are in a working state or an idle state, thereby accurately determining the state of each system service.

[0050] Before detailing the method for providing management system services according to the embodiments of this application, we will first provide an exemplary description of the terminal device applicable to the embodiments of this application in conjunction with Figures 1, 2 and 3.

[0051] The management system service method provided in this application can be applied to devices such as mobile phones, tablets, smart TVs, smart screens, smartwatches, wearable devices, in-vehicle devices, laptops, personal computers (PCs), ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), and distributed devices. This application does not limit the specific type of device. The device can also be referred to as user equipment (UE), mobile device, user terminal, wireless communication device, or user device, etc., and this application does not limit this terminology.

[0052] Furthermore, the methods described in this application embodiment can support operating systems such as Android OS, Harmony OS, OpenHarmony OS, iOS, Windows OS, and lightweight operating systems (such as LiteOS). This application embodiment does not impose any limitations on these methods.

[0053] Figure 1 is a schematic diagram of a terminal device for a method of providing management system services applicable to embodiments of this application.

[0054] For example, Figure 1 shows a schematic diagram of the structure of terminal device 100. As shown in Figure 1, 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, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity 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] Processor 110 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and neural network processing unit (NPU). 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) or displays images or videos through the display screen 194.

[0057] The controller can serve as the nerve center and command center of the terminal device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0058] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0059] The processor 110 can execute different operations by executing instructions to achieve different functions. These instructions may 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 application embodiment does not limit them in any way.

[0060] In some embodiments, the processor 110 may include one or more interfaces. 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, etc.

[0061] USB interface 130 is an interface conforming to the USB standard specification, specifically a Mini USB interface, Micro USB interface, USB Type-C interface, etc. USB interface 130 can be used to connect a charger to charge the terminal device 100, and can also be used for data transfer between the terminal device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other devices, such as augmented reality (AR) devices. It is understood that the interface connection relationships between the modules illustrated in this application are merely illustrative and do not constitute a structural limitation on the terminal device 100. In other embodiments, the terminal device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0062] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives 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 supply power to the terminal device 100 via the power management module 141.

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

[0064] The wireless communication function of the terminal device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and 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 one or more 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, for use on the terminal device 100.

[0067] The wireless communication module 160 can provide wireless communication solutions for use on 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, and infrared (IR) technology.

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

[0069] Terminal device 100 can implement display functions through a GPU, display screen 194, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0070] Display screen 194, also known as a screen, can be used to display images, videos, etc. It should be understood that display screen 194 may also include more components, such as a backlight panel and driving circuitry. The backlight panel provides a light source, and the display panel emits light based on this light source. The driving circuitry controls whether the liquid crystal layer is transparent or opaque.

[0071] Terminal device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0072] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0073] Internal memory 121 can be used to store executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of terminal device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc. The data storage area may store data created during the use of terminal device 100 (such as audio data, phone book, etc.). In addition, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, etc.

[0074] Terminal device 100 can implement audio functions, such as music playback and recording, through audio modules 170, such as speakers 170A, receivers 170B, microphones 170C, and headphone jacks 170D, and application processors.

[0075] It is 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 illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

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

[0077] Figure 2 is a structural block diagram of the software of a terminal device applicable to the method for managing system services provided in the embodiments of this application.

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

[0079] The application layer can include a series of applications. As shown in Figure 2, the application layer can include system applications and third-party applications. System applications can be understood as applications that come pre-installed 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, which can be downloaded and installed from app stores or app markets.

[0080] As 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 user program frameworks and component frameworks in multiple languages, including C, C++, and JavaScript (JS), as well as APIs for various software and hardware services that are exposed to the outside world in multiple languages. Simultaneously, it provides devices with UI frameworks in multiple languages, including C, C++, and JS. The APIs supported by different devices are related to the degree of componentization and customization of the system.

[0081] The system service layer is the core capability set of the operating system, providing various system services to applications through the framework layer. In this embodiment, the system service layer may further include a system service management module. This module can determine the status of non-basic system services by acquiring information such as the invocation status 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, based on one or more of these three items. A detailed description of the system service management module can be found in the relevant description below; for brevity, it will not be repeated here.

[0082] As not shown in Figure 2, the system service layer may include a set of basic system capability subsystems, a set of basic software service subsystems, a set of enhanced software service subsystems, and a set of hardware service subsystems.

[0083] 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 distributed applications to run, schedule, migrate and perform other operations on multiple devices.

[0084] The basic software service subsystem set can consist of subsystems such as event notification, telephone, and multimedia, and can provide public and general software services.

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

[0086] The hardware service subsystem suite can consist of subsystems such as location services, biometric recognition, wearable proprietary hardware services, and IoT proprietary hardware services, and can provide hardware services.

[0087] It should be noted that, depending on the deployment environment of different device types, 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 further tailored at the functional granularity. This application's embodiments do not impose any limitations on this.

[0088] Not shown in Figure 2, the kernel layer can include a kernel subsystem and a driver subsystem. The operating system can employ a multi-kernel design. Based on the kernel subsystem, the operating system supports selecting a suitable OS kernel for different resource-constrained devices. The kernel abstract layer (KAL) provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including process / thread management, memory management, file system, network management, and peripheral device management. The driver framework within the driver subsystem is the foundation for the open hardware ecosystem of the operating system, providing unified peripheral access capabilities and a framework for driver development and management.

[0089] Figure 3 is another structural block diagram of the software of a terminal device applicable to the management system service provided in the embodiments of this application.

[0090] As shown in Figure 3, in some embodiments, the Android operating system is divided into the application layer, application framework layer, Android runtime, system libraries, and kernel layer from top to bottom.

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

[0092] The application layer can include a series 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 pre-installed 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, which can be downloaded and installed from app stores, etc.

[0093] The application framework layer provides APIs and a programming framework for applications within the application layer. The application framework layer includes some predefined functions. As shown in Figure 3, the application framework layer may include modules such as the system service management module. A detailed description of the system service management module can be found in Figure 2; for brevity, it will not be repeated here.

[0094] As not shown in Figure 3, the Android runtime can include core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android operating system.

[0095] The core library can consist of two parts: one part is the functionalities that the Java language needs to call, 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 the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, 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. For example: status monitoring service, surface manager, media libraries, 3D graphics processing library (e.g., OpenGLES), 2D graphics engine (e.g., SGL), etc.

[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 application embodiment does not impose any limitations on this.

[0099] In the embodiments of this application, as shown in FIG2 or FIG3, the terminal device may include a system service management module, so that the terminal device has the ability to implement the method of the management system service provided in this application.

[0100] It should be understood that Figures 1, 2 and 3 are merely examples and should not be construed as limiting the embodiments of this application.

[0101] Figure 4 is a schematic flowchart of the method for providing management system services according to an embodiment of this application.

[0102] As shown in Figure 4, method 400 may include steps 410 to 440. The steps of method 400 may be executed by a terminal device, or by a component (such as a chip, chip system, etc.) configured in the terminal device, or by a logic module or software capable of implementing all or part of the terminal device's functions; this application embodiment does not limit this. The terminal device may have the structure shown in Figures 1, 2, or 3; this application embodiment does not limit this. The steps in Figure 4 are described in detail below.

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

[0104] It is understood that the first system service is any system service among the non-basic system services. Non-basic system services are system services other than the preset basic system services. For a detailed description of basic 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 the configuration file corresponding to the first system service. Whether the occurrence of any of the one or more events triggers the running of the first system service or triggers the termination of the first system service 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 state of this silent operation includes being in silent operation or not being in silent operation.

[0109] In this embodiment, a system service can proactively declare the start of silent operation or proactively declare the end of silent operation. If the first system service declares the start of silent operation but does not declare the end of silent operation, the state of the silent operation is silent operation; or, if the first system service declares the end of silent operation, or never declares the start of silent operation, the state of the silent operation is not silent operation.

[0110] The terminal device can utilize the system service management module shown in Figure 2 or Figure 3 to obtain information on the invocation status of the first system service, the occurrence status of one or more events related to the first system service, and the silent running status of the first system service. In other words, the system service management module provided in this application has the ability to obtain information on the invocation status of the first system service, the ability to obtain information on the occurrence of one or more events related to the first system service, and the ability to obtain information on the silent running status of the first system service.

[0111] Figure 5 is a schematic diagram of various triggering methods for changing the state of system services provided in the embodiments of this application.

[0112] As shown in Figure 5, the method for managing system services provided in this application embodiment takes into account a variety of triggering methods that can change the state of system services.

[0113] The first triggering method: Application processes (including system applications and third-party applications) call system services.

[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 a 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 taking photos or recording videos).

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

[0116] A system service can correspond to one or more related events. These one or more events associated with a first system service are pre-configured, as are the events that trigger or terminate the first system service upon occurrence of any of these events. As an example, and not a limitation, each system service can correspond to a configuration file that configures one or more events associated with that system service, specifying whether the occurrence of any of these events triggers the system service to run or terminate. For example, network connection events and network disconnection events are associated with a network service; a network connection event can trigger the network service to run, and a network disconnection event can trigger the network service to terminate.

[0117] The third triggering method: The system service can actively request to start silent operation or actively request to end silent operation.

[0118] In the method for managing system services provided in this application embodiment, interfaces are provided for the system service to declare the start and end of silent operation. When a system service needs to run silently, it can actively declare the start of silent operation through the aforementioned interfaces, thereby allowing the system service to enter a working state. When a system service wants to end silent operation, it can actively declare the end of silent operation through the aforementioned interfaces, thereby allowing the system service to end silent operation. For example, if an upgrade service needs to run silently, it can actively declare the start of silent operation through the aforementioned interfaces; after the upgrade is completed, the system service can actively declare the end of silent operation through the aforementioned interfaces.

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

[0120] For example, the terminal device can use the system service management module to execute step 410 above. That is, the terminal device can use the system service management module to obtain the invocation status of the first system service, and then use the invocation status of the first system service to determine whether the first system service is in a working state. If the first system service is invoked by at least one application process, it can be determined that the state of the first system service is working; if no application process invokes the first system service, the first system service may not necessarily be in an idle state, and other factors can be combined to determine whether the first system service is in an idle state.

[0121] For example, the terminal device can use the system service management module to execute step 420 above. That is, the terminal device can use the system service management module to obtain the occurrence status of one or more events related to the first system service. In other words, when an 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 determine whether the event triggered the first system service to run or triggered the first system service to terminate. If it is determined that the event triggered the first system service to run, the state of the first system service can be determined to be in a working state. If it is determined that the event triggered the first system service to terminate, the first system service may not necessarily enter an idle state; other factors can be considered to determine whether the first system service has entered an idle state.

[0122] For example, the terminal device can use the system service management module to execute step 430 above. That is, the terminal device can use the system service management module to obtain the silent running status of the first system service. In other words, when the first system service needs to run silently, it can actively request the system service management module to initiate silent operation, thus informing the system service management module that the first system service has entered a working state. When the first system service wants to end silent operation, it can actively request the system service management module to end silent operation, thus ending silent operation. However, the first system service may not necessarily enter an idle state; other factors can be considered to determine whether the first system service is in an idle state. In other words, if the first system service requests to start silent operation but does not request to end silent operation, its silent running status is silent operation; or, if the first system service requests to end silent operation, or never requests to start silent operation, its silent running status is not silent operation. If the service is not in a silent running state, the first system service may not necessarily be in an idle state. Other factors can be considered to determine whether the first system service is in an idle state.

[0123] It is understood that this application does not impose any restrictions on the execution order of steps 410, 420 and 430. That is, steps 410, 420 and 430 may be executed simultaneously or not simultaneously. This application does not impose any restrictions on this.

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

[0125] The status of the first system service includes either a working state or an idle state. A working state means that the first system service is running; an idle state means that the first system service is not running.

[0126] Terminal devices can use the system service management module to determine the status of the first system service based on the invocation status of the first system service, the occurrence status of one or more events, and the silent operation status of the first system service.

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

[0128] When the invocation condition is "invocation", that is, when the first system service is invoked by at least one application process, the terminal device can determine that the state of the first system service is "working".

[0129] If the occurrence of any one of the one or more events related to the first system service triggers the operation of the first system service, the terminal device can determine that the state of the first system service is a working state.

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

[0131] In other words, the terminal device can determine whether the first system service is in a working state based on any one of the following: the invocation status of the first system service, the occurrence of one or more events, or the silent operation status of the first system service.

[0132] In one possible implementation, the state of the first system service is determined based on the invocation status of the first system service, the occurrence of the one or more events, and the state of silent operation, including: determining the state of the first system service as idle when the first system service is not invoked, and when the occurrence of any of the one or more events triggers the first system service to terminate operation or when no event occurs in the one or more events, and when the first system service declares the termination of silent operation or does not declare the start of silent operation.

[0133] If the first system service is not invoked (i.e., it is not invoked by any application process), and any one of the events related to the first system service triggers the first system service to terminate or none of the events occurs, and the silent operation is not in a dynamic silent operation state, the terminal device can determine that the state of the first system service is idle.

[0134] In other words, by combining the call status of the first system service, the occurrence status of one or more events, and the silent running status of the first system service, the terminal device can determine whether the first system service is in an idle state.

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

[0136] Figure 6 is a schematic diagram of an application process calling system services according to an embodiment of this application. To facilitate a better understanding of the method for managing system services provided in this embodiment of the application, the process of an application calling system services will be briefly explained below with reference to Figure 6.

[0137] Step 1: Query system services for application processes.

[0138] As shown in Figure 6, when a system application process and / or a third-party application process need to call a certain system service, it can first query the system service management module for that system service.

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

[0140] The system service management module can load the system service in response to queries from application processes.

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

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

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

[0144] Application processes can invoke the corresponding system service based on the system service returned by the system service management module.

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

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

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

[0148] As shown in Figure 7, in user space, the client component a proxy calls the first system service through process object a. This is mapped in kernel space as the reference between the client component a proxy and the server node corresponding to the service component of the first system service in kernel space. Similarly, in user space, the client component b proxy calls the first system service through process object b. This is mapped in kernel space as the reference between the client component b proxy and the server node corresponding to the service component of the first system service in kernel space.

[0149] The terminal device can utilize the system service management module to obtain and count the number of service nodes corresponding to the service components of the first system service referenced in the kernel space, that is, the number of service references associated with the service nodes. This number is also the call count of the first system service. If the call count is zero, the terminal device can determine that the service has not been called, i.e., the first system service has not been called; or, if the call count is greater than zero, the terminal device can determine that the service has been called, i.e., the first system service has been called. As mentioned above, if the first system service is called, it is in a working state; however, if the first system service is not called, it is not necessarily in an idle state.

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

[0151] Figure 8 is a schematic diagram of the detection system events provided in the embodiments of this application.

[0152] As shown in Figure 8, the terminal device can utilize 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 connection events, network disconnection events, etc., as shown in the figure. When an event occurs, the terminal device's system service management module can receive a notification message about the event. Based on the pre-configured and stored configuration file of the first system service, the system service management module can determine whether the event is related to the first system service. If the event is related to the first system service, based on the configuration file, it can determine whether the event triggered the first system service to run or terminate. If it is determined that the event triggered the first system service to run, the state of the first system service can be determined to be in a working state. If it is determined that the event triggered the first system service to terminate, the first system service may not necessarily enter an idle state; other factors can be considered to determine whether the first system service has entered an idle state. For example, in a case where network service is the primary system service, the relevant events for the network service may include network access events. For instance, if the configuration file is set to trigger the network service to run when a network access event occurs, then based on the configuration file, the terminal device can determine that the network service has entered a working state when a network access event occurs.

[0153] Figure 9 is a schematic diagram of the system service application starting silent operation and ending silent operation provided in the embodiment of this application.

[0154] In step 430 of method 400 above, the status of the first system service running silently is obtained. This step presupposes that the system service management module can provide interfaces for the system service to declare and terminate silent operation. As shown in Figure 9, when a system service needs to run silently, it can actively declare and terminate silent operation through the aforementioned interface. In this way, the system service management module knows when the system service started silent operation and entered the working state. Similarly, when a system service wants to terminate silent operation, it can actively declare and terminate silent operation through the aforementioned interface. In this way, the system service management module knows when the system service terminated silent operation.

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

[0156] In other words, after the most recent determination of the status of the first system service, the terminal device can use the system service management module to record the status of the first system service.

[0157] In one possible implementation, the status identifier is updated based on the most recently determined state of the first system service, including: if the status identifier is empty or the recorded state of the first system service is working, if the most recently determined call condition is not called, and if no event occurs in the one or more events or the occurrence of any of the one or more events triggers the first system service to terminate operation, and if the silent operation state is not in silent operation, the status identifier is updated to idle state.

[0158] In other words, after the terminal device is powered on and running, if the status identifier is empty or the status of the first system service has been determined and recorded as working, the system service management module continuously obtains 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 running status of the first system service. If the call status is determined to be not called in the most recent time, and if no event occurs in one or more events related to the first system service, or if the occurrence of any of the one or more events triggers the first system service to end its operation, and if the first system service has never declared that it has started silent operation or declared that it has ended silent operation, the terminal device can use the system service management module to update the status of the first system service to idle status.

[0159] In one possible implementation, updating the status identifier based on the most recently determined state of the first system service includes: updating the status identifier to working state when the status identifier is empty or the recorded state of the first system service is idle, when the most recently determined call situation is called, or when the occurrence of any of the one or more events triggers the first system service to run, or when the silent running state is in silent running.

[0160] In other words, after the terminal device is powered on and running, if the status identifier is empty or the status of the first system service has been determined and recorded as 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 running status of the first system service. When the call status is most recently determined to be called, the terminal device can use the system service management module to update the status of the first system service to working status; or, when the occurrence of any event related to the first system service in the most recent determination triggers the running 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 working status; or, when the first system service actively reports to the system service management module to start silent running, but has not reported to end silent running, the terminal device can use the system service management module to update the status of the first system service to working status.

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

[0162] When the first system service is idle, the terminal device can release the system resources corresponding to the first system service to avoid wasting system resources and allow other system services or application processes to utilize these system resources.

[0163] Based on the above scheme, the terminal device determines the status of non-basic system services by acquiring information on the invocation status of non-basic system services, the occurrence of events related to non-basic system services, and the silent operation status of non-basic system services. For example, it determines whether a non-basic system service is in a working state or an idle state, thus accurately judging the status of each system service. Furthermore, the terminal device updates the status of each system service in real time based on these three conditions. Moreover, with real-time monitoring of the status of each system service, the terminal device can manage the system resources corresponding to each system service. For example, if a first system service is in an idle state, the terminal device can release the system resources corresponding to that first system service to avoid wasting system resources, allowing other system services or application processes to utilize these resources.

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

[0165] This application also provides a terminal device, which includes a memory and a processor. The memory is used to store a program, and the processor is used to call and execute the program so that the terminal device performs the steps in any of the embodiments in Figures 4 to 9 above.

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

[0167] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0168] The chip system can consist of chips or include chips and other discrete components.

[0169] This application also provides a readable storage medium storing a program thereon, which, when executed by a terminal device, causes the terminal device to perform the steps in any of the embodiments shown in Figures 4 to 9.

[0170] This application also provides a program product, including a program that, when run by a terminal device, causes the terminal device to perform the steps in any of the embodiments shown in Figures 4 to 9.

[0171] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The 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. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

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

[0173] The terms “unit”, “module”, etc., used in this specification may be used to refer to an entity related to the device, hardware, firmware, a combination of hardware and software, software, or software in execution.

[0174] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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 apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of modules is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or modules may be electrical, mechanical, or other forms.

[0175] The modules described as separate components may or may not be physically separate. 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 can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0177] If the aforementioned functions are implemented as 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

A method for managing system services, characterized in that, include: Obtain the invocation status of the first system service, which is a system service other than the preset basic system services; Obtain the occurrence status of one or more events related to the first system service, wherein the one or more events are configured in the configuration file corresponding to the first system service; Obtain the silent running status of the first system service; based on the invocation status, the occurrence status of the one or more events, and the silent running status, determine the status of the first system service, the status including working status or idle status. The method as described in claim 1, characterized in that, Determining the state of the first system service based on the invocation status, the occurrence of the one or more events, and the silent operation status includes: determining the state of the first system service as working when the first system service is invoked, or when the occurrence of any of the one or more events triggers the operation of the first system service, or when the silent operation status is in silent operation. The method as described in claim 1, characterized in that, Determining the state of the first system service based on the invocation status, the occurrence of the one or more events, and the silent operation status includes: determining the state of the first system service as idle when the first system service is not invoked, and when the occurrence of any of the one or more events triggers the first system service to terminate operation or when no event occurs in the one or more events, and when the silent operation status is not in silent operation. The method as described in any one of claims 1 to 3, characterized in that, The step of obtaining the call status of the first system service includes: obtaining the call count of the first system service; if the call count is zero, determining that the call status is not called; or, if the call count is greater than zero, determining that the call status is called. The method according to any one of claims 1 to 4, characterized in that, The step of obtaining the occurrence status of one or more events related to the first system service includes: detecting the one or more events related to the first system service. The method as described in any one of claims 1 to 5, characterized in that, The method further includes updating a status identifier based on the most recently determined status of the first system service, wherein the status identifier is used to record the status of the first system service. The method according to any one of claims 1 to 6, characterized in that, The method further includes: releasing the system resources occupied by the first system service when the first system service is in an idle state. The method as described in any one of claims 1 to 7, characterized in that, The silent operation state includes being in silent operation or not being in silent operation, and, in the case where the first system service has declared the start of silent operation but has not declared the end of silent operation, the silent operation state is being in silent operation; Alternatively, if the first system service has declared the termination of silent operation, or has never declared the start of silent operation, the status of the silent operation is not in silent operation. A terminal device, characterized in that, It includes a processor and a memory, wherein the memory is used to store a program; the processor is used to invoke the program so that the terminal device performs the method of any one of claims 1 to 8. A readable storage medium having a program stored thereon, characterized in that, When the program is executed, it causes the terminal device to perform the method as described in any one of claims 1 to 8. A program product, characterized in that, Includes a program that, when run, causes a terminal device to perform the method as described in any one of claims 1 to 8.

Images