Application management method and related apparatus
By determining the module calling interface allowed in the card rendering service, the problem that the card rendering service does not require all module functions when rendering card components is solved, and fine control of module loading is achieved, reducing the power consumption and security risks of the terminal.
Patent Information
- Application Number
- PCT/CN2024/119443
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-12-19
- Filing Date
- 2024-09-18
- Publication Date
- 2025-06-26
AI Technical Summary
When rendering card components, the card rendering service may not require the functions of all modules, resulting in increased terminal power consumption and security risks. The prior art cannot realize fine interface call control.
By determining the module calling interface allowed by the card rendering service, the interface-level call control is implemented to avoid excessive loading of modules and reduce power consumption and security risks.
It realizes fine control of module loading, meets the interface call needs of different scenarios, and reduces the power consumption and security risks of the terminal.
Smart Images

Figure CN2024119443_26062025_PF_FP_ABST
Abstract
Description
Application management method and related device
[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 19, 2023, with application number 202311756393.4 and application name “Application Management Method and Related Devices”, 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 an application management method and related devices. Background Art
[0003] There are many applications in the terminal, such as a weather application for querying weather information, a camera application for providing photo-taking functions, and a card rendering service (FormRenderService, FRS) for rendering card components of the terminal's service cards, etc. Among them, the service card is a quick service provided by an intelligent service assistant, which can display more content than the application icon; when the card component is in use (for example, during the addition of a card), it is necessary to run the application of the card provider. For example, the card rendering service needs to run the weather application in the process of rendering the weather card. During the operation of the weather application, multiple modules need to be loaded, such as the internationalization module, the Global Positioning System (GPS) module, etc.
[0004] However, during the card rendering process, the card rendering service does not necessarily need to provide the functions of all modules corresponding to the application, nor does it necessarily need all the functions of each module. For example, the internationalization module includes multiple functions such as obtaining the current time format, setting the time format, and obtaining the date format. It may only need the function of obtaining the current time format. If the card rendering service does not restrict the functions obtained by the card rendering service during the rendering of the card component, it will affect the power consumption and security of the terminal.
[0005] Summary of the Invention
[0006] This application provides an application management method and related apparatus. When a card rendering service (FRS) renders a card corresponding to a terminal application, it loads the terminal's module. By determining the calling interface of the module allowed to be called by the FRS, the FRS is controlled at the interface level. This prevents excessive module abuse that could affect terminal security and power consumption, while also achieving fine-grained control at the interface level.
[0007] To achieve the above objectives, this application adopts the following technical solutions:
[0008] In a first aspect, an application management method is provided, which is applied to a terminal, and the method includes: rendering a first card corresponding to a first application of the terminal through a card rendering service FRS; receiving a loading request from the card rendering service FRS, the loading request being used to request loading a first target module, and the first loading request is formed by the FRS when rendering the card corresponding to the application of the terminal; loading the first target module based on the loading request and determining a first target calling interface set, the first target calling interface set including at least one calling interface in the first target module that is allowed to be called by the application.
[0009] In this way, when the FRS renders the card corresponding to the application of the terminal, a loading request is formed, the first target module is loaded based on the loading request of the application, and the target calling interface set and the calling interface that the FRS is not allowed to call in the first target module are determined, wherein the target calling interface set includes a calling interface that is allowed to be called by the FRS in at least one calling interface of the first target module, so that the FRS calls the calling interface in the module that is allowed to be called by the FRS; since the module supports multiple calling interfaces, each calling interface supports specific functions; by determining the calling interface that is allowed to be called by the FRS, the module is loaded with the interface as the management unit, thereby achieving more refined interface call control and meeting the user's diverse FRS interface call restriction configuration requirements. By controlling the loading of FRS modules, the risk of excessive module loading can also be reduced.
[0010] Among them, the control strategy of FRS can be implemented through pre-configured configuration information or based on the restriction information carried in the FRS loading request. The control strategy here can be an interface that can be called by FRS or a function that can be used (or obtained) by FRS.
[0011] In some embodiments, loading the first target module based on the loading request and determining the first target call interface set includes: obtaining first configuration information of the FRS; loading the first target module based on the loading request, and determining the first target call interface set based on the first configuration information.
[0012] In this way, the control policy of FRS is pre-configured through configuration information. When FRS requests to load a module, targeted interface call restrictions are performed on the FRS based on the configuration information corresponding to the FRS, so as to obtain more refined control over the functions available to the FRS.
[0013] In some embodiments, the first configuration information is the configuration information corresponding to the FRS in a first scenario, and the first scenario includes at least one of the operating status of the FRS, the working mode of the terminal, the operating time period of the terminal, and the number of times the first target module is called by the FRS; the method also includes: when the scenario corresponding to the FRS is changed to a second scenario, obtaining the second configuration information corresponding to the FRS in the second scenario; reloading the first target module, and determining a second target calling interface set based on the second configuration information, the second target calling interface set including a calling interface in at least one calling interface of the first target module that is allowed to be called by the FRS in the second scenario.
[0014] The terminal's FRS has multiple scenarios. The scenario can be the state of the FRS itself, such as whether the FRS is a foreground application or a background application; the scenario can also be the working mode of the terminal, such as whether the terminal is in normal mode or flight mode; the scenario can also be when the terminal is in different time periods, such as 7:00 am to 9:00 pm or 12:00 pm to 5:00 am. The FRS scenario can also be a limit on the number of calls to the first target module, such as allowing the FRS to call the internationalization module twice within 24 hours; the configuration information corresponding to the FRS in different scenarios may be different, that is, the FRS corresponds to different scenarios, and the FRS's corresponding control strategy is also different accordingly. If the FRS's scenario changes, the configuration information corresponding to the FRS's current scenario (or the changed scenario) is obtained, and the first target module is reloaded according to the configuration information corresponding to the current scenario. Since the FRS's control strategy may be different in different scenarios, after the FRS scenario changes, the module is reloaded according to the current scenario to achieve real-time control of the FRS's control strategy according to the FRS scenario change.
[0015] In some embodiments, after receiving the first load request from the FRS, the method further includes: determining a replacement module corresponding to the first target module based on the first configuration information, and loading the replacement module. In this way, by pre-configuring the replacement module for each module in the configuration information, when the FRS requests to load the module, the replacement module can be loaded according to the configuration information. The replacement module can be a mock (MOCK) module or any module specified by the user, so that the loading of each module can be adjusted or replaced according to the user's actual needs.
[0016] In some embodiments, determining the first target call interface set based on the first configuration information includes: receiving a call interface of the first target module sent by the first target module; and determining the first target call interface set in the call interface of the first target module based on the first configuration information. The terminal filters the call interface of the first target module based on the first configuration information to determine the call interfaces of the first target module that are allowed to be called by the FRS and the call interfaces that are not allowed to be called by the FRS.
[0017] In some embodiments, determining the first target call interface set based on the first configuration information includes: determining a control policy of the FRS for the first target module based on the first configuration information; sending the control policy to the first target module; obtaining an export object of the first target module, the export object being determined by the first target module based on the control policy, the export object including the first target call interface set; and filtering the call interfaces through the loaded modules to determine a call interface among the call interfaces that the FRS is allowed to call.
[0018] In some embodiments, after determining the second target call interface set based on the second configuration information, the method further includes: obtaining transition data of the first target module loaded by the FRS in the first scenario; and importing the transition data into the first target module loaded by the FRS in the second scenario. Thus, after the module manager loads the first target module based on the first configuration information, transition data is obtained due to user operations or processing by the first target module itself. The transition data may be temporary files or user data. The transition data is sent to the reloaded first target module or imported into the reloaded first target module so that the reloaded first target module can use the transition data, or the user or FRS can use the transition data through the first target module.
[0019] In some embodiments, before reloading the first target module, the method further includes: determining whether the control strategies of the application for the first target module in the first configuration information and the second configuration information are the same; and reloading the first target module when the control strategies of the FRS for the first target module in the first configuration information and the second configuration information are different. Before reloading the first target module, determining whether the control strategies of the FRS for the first target module have changed before and after the scene change; if the control strategies of the FRS for the first target module are the same before and after the scene change, there is no need to reload the first target module.
[0020] In some embodiments, before loading the first target module based on the loading request, the method further includes: determining whether the FRS is allowed to load the first target module based on the first configuration information; if the FRS is allowed to load the first target module, executing the loading of the first target module based on the loading request.
[0021] In some embodiments, obtaining the first configuration information of the FRS includes: querying a module loading checker whether the FRS is allowed to load the first target module, the module loading checker being generated based on the configuration file of the application; obtaining the query result, if the FRS is allowed to load the first target module, the query result carries the first configuration information.
[0022] In some embodiments, the first configuration information describes the FRS's control strategy for the first target module, and the configuration file describes the FRS's control strategy for the terminal's module.
[0023] In some embodiments, after loading the first target module based on the load request and determining the first target call interface set, the method further includes: deleting the call interface in the first target call interface set that does not allow the FRS to call, or replacing the call interface in the first target call interface set that does not allow the FRS to call with throwing an exception. The interface of the first target module is filtered by deletion or replacement to determine the call interface in the first target module that allows FRS to call.
[0024] In some embodiments, the method further includes: after the first target module is loaded, sending the first target call interface set to the FRS. By sending the first target call interface set to the FRS, the FRS can use the module's functions by calling the callable interface.
[0025] In some embodiments, the method further includes: rendering the second card corresponding to the first application of the terminal or the third card of the second application of the terminal through FRS, receiving a second loading request of the FRS, the second loading request being used to request loading a second target module, the loading request being formed when the FRS renders the second card corresponding to the first application of the terminal or the FRS renders the third card corresponding to the second application of the terminal; loading the second target module based on the second loading request and determining a third target calling interface set, the third target calling interface set including a calling interface of at least one calling interface of the target module that is allowed to be called by the FRS. When FRS renders an application card, it needs to load the module corresponding to the application. When rendering different cards of the same application or cards of different applications, it may be necessary to load the same module (in this case, the second target module and the first target module are the same terminal module), or different modules (in this case, the second target module is different from the first target module). Due to different applications or different cards (for example, different cards of the same application), the control strategy for FRS loading modules may also be different. For example, when FRS renders card 1 and card 2, it needs to load the internationalization module; however, when rendering card 1, FRS can call the calling interface corresponding to the three functions of the internationalization module: obtaining the current time format, setting the time format, and obtaining the date format; when rendering card 2, FRS can call the calling interface corresponding to the function of obtaining the current time format of the internationalization module. Therefore, a new target calling interface set needs to be determined based on the new loading request. When rendering cards of different applications or different cards of the same application, the control strategy for FRS can also change in real time.
[0026] In a second aspect, an application management method is provided, which is applied to a terminal and includes:
[0027] The system application runs the code of the third-party application; based on the system application's request to load the target module, the system application loads the target module; the target module is a module that needs to be loaded to run the code of the third-party application; the system application calls the target interface in the target module; the target interface includes an interface in the target module that is allowed to be called by the code of the third-party application.
[0028] In some embodiments, the method further includes: acquiring first configuration information of the system application; and determining the target interface according to the first configuration information.
[0029] In some embodiments, the first configuration information is the configuration information corresponding to the system application in a first scenario, the first scenario includes at least one of the running status of the system application, the working mode of the terminal, the running time period of the terminal, and the number of times the target module is allowed to be called by the system application, and the running status of the system application includes the system application being a foreground application and the system application being a background application; the method also includes: when the scenario corresponding to the system application changes to a second scenario, obtaining second configuration information corresponding to the system application in the second scenario; reloading the target module, and determining a second target calling interface set based on the second configuration information, the second target calling interface set including at least one calling interface in the target module that is allowed to be called by the system application in the second scenario.
[0030] In some embodiments, the method further includes: determining a replacement module corresponding to the target module according to the first configuration information, and loading the replacement module.
[0031] In some embodiments, determining the first target calling interface set based on the first configuration information includes: receiving the calling interface of the target module sent by the target module; and determining the first target calling interface set in the calling interface of the target module based on the first configuration information.
[0032] In some embodiments, determining the first target call interface set based on the first configuration information includes: determining the control strategy of the system application for the target module based on the first configuration information; sending the control strategy to the target module; obtaining the export object of the target module, the export object is determined by the target module based on the control strategy, and the export object includes the first target call interface set.
[0033] In some embodiments, after determining the second target call interface set based on the second configuration information, the method also includes: obtaining transition data of the first target module loaded by the system application in the first scenario; and importing the transition data into the target module loaded by the system application in the second scenario.
[0034] In some embodiments, before reloading the target module, the method further includes: determining whether the control strategies of the system application for the target module in the first configuration information and the second configuration information are the same; when the control strategies of the system application for the target module in the first configuration information and the second configuration information are different, reloading the target module.
[0035] In some embodiments, before loading the target module based on the loading request, the method further includes: determining whether the system application is allowed to load the target module based on the first configuration information; when the system application is allowed to load the target module, loading the target module based on the loading request.
[0036] In some embodiments, obtaining the first configuration information of the system application includes: querying a module loading checker whether the system application is allowed to load the target module, the module loading checker being generated based on the configuration file of the system application; obtaining the query result, if the system application is allowed to load the first target module, the query result carries the first configuration information.
[0037] In some embodiments, the first configuration information describes a control strategy of the system application on the first target module, and the configuration file describes a control strategy of the system application on the module of the terminal.
[0038] In some embodiments, after loading the first target module based on the first load request and determining the first target call interface set, the method further includes:
[0039] The calling interface in the target calling interface set that is not allowed to be called by the system application is deleted, or the calling interface in the target calling interface set that is not allowed to be called by the system application is set to throw an exception.
[0040] In some embodiments, the method further comprises:
[0041] When the first target module is loaded, the first target call interface set is sent to the system application. In a third aspect, a terminal is provided, comprising: a memory, the memory comprising computer-readable instructions;
[0042] A processor in communication with the memory, the processor being configured to execute the computer-readable instructions so that the terminal executes the application management method according to any one of the first aspect or the second aspect.
[0043] In a fourth aspect, a computer-readable storage medium is provided, comprising a program or instruction, which, when executed by a processor, implements the application management method as described in any one of the first aspect or the second aspect.
[0044] In a fifth aspect, a chip is provided, comprising a processor for calling and executing instructions stored in a memory, so that a terminal equipped with the chip executes the application management method described in any one of the first aspect or the second aspect.
[0045] The beneficial effects brought about by each possible implementation method of the application management method provided in the second aspect, the terminal provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the chip provided in the fifth aspect of the embodiment of this application can be referred to the description of the various possible implementation methods in the first aspect, and will not be repeated here one by one. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] FIG1 is a schematic diagram of the operating principle of a service card;
[0047] FIG2 is a schematic diagram of an application management scenario provided by an embodiment of the present application;
[0048] FIG3 is a flow chart of an application management method provided in an embodiment of the present application;
[0049] FIG4 is a flow chart of an application management method provided in an embodiment of the present application;
[0050] FIG5 is a flow chart of an application management method provided in an embodiment of the present application;
[0051] FIG6 is a flow chart of an application management method provided in an embodiment of the present application;
[0052] FIG7 is a flow chart of an application management method provided in an embodiment of the present application;
[0053] FIG8 is a schematic diagram of the structure of an application management device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0054] The technical solutions in this application will be described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of this specification, rather than all the embodiments.
[0055] It is easy to understand that the service card of the terminal is a quick service provided by an intelligent service assistant. It can display more content than the application icon. Users can set the card corresponding to the application on the desktop or the negative one screen so that users can view more content related to the application. For example, weather cards can display current weather information, and memo cards can display to-do event information or memo event information, etc. Service cards need to start the card provider application to obtain related operations (such as rendering of service cards). For example, pulling up a weather-related third-party application to obtain weather information. Each time the application process is pulled up, power consumption is high and the response time is prolonged; for example, a weather service card needs to start a third-party weather application to obtain weather-related information.
[0056] Figure 1 is a schematic diagram of the operating principle of a service card. In Figure 1, the card user is the host application that displays the service card content and is used to control the location of the card in the host; the card provider is the application that provides the display content of the service card and is used to control the display content of the card, etc.; the card management service is a resident proxy service for managing the cards added to the system, providing interface capabilities for the card provider (formProvider) and the card user (formHost), while also providing capabilities such as the management and use of card objects and periodic card refresh. The card rendering service (FormRenderService, hereinafter referred to as FRS) is used to manage card rendering instances, and the rendering instances are bound one-to-one to the card components on the card user. FRS sends the rendered data to the card component corresponding to the card user. FRS is managed by the card management service. Each card component of the card user corresponds to a rendering instance in the card rendering service.
[0057] When rendering a card component, the FRS needs to run the page code of the card provider's application corresponding to the card component. During the execution of the page code of the card provider's application, the corresponding functional modules may need to be loaded. For example, when running the page code of the map application, the terminal's global positioning system (GPS) module, microphone module, etc. need to be loaded; when running the page code of the antenna-related application, the internationalization module needs to be loaded. Since each module of the terminal has multiple functions, for example, the internationalization module includes multiple functions such as obtaining the current time format, setting the time format, and obtaining the date format, when rendering the card component, the FRS may only need one of the functions, such as obtaining the current time format. Then, when loading modules, the existing FRS uses the module as the control unit. For example, the application can load the internationalization module but cannot load the alarm module. However, when the application (also known as the application program) loads the module, the application does not need all the functions of the module. In some scenarios, the application only needs one of the functions of the module. The existing control strategy cannot control the loading strategy of each module based on user needs or the actual needs of the application.
[0058] Based on the above problems, an embodiment of the present application provides an application management method. When an application loads a target module, the target module is loaded based on the application's application loading request and a target call interface set in the target module is determined, wherein the target call interface set includes at least one call interface in the target module that is allowed to be called by the application; since the module supports multiple call interfaces, each call interface supports a specific function; by determining the call interface that the application is allowed to call, the module is loaded with the interface as the management unit, thereby achieving more refined interface call control and meeting the user's diverse configuration requirements for application interface call restrictions. By controlling the module loading of the application, the risk of excessive module loading can also be reduced.
[0059] It is easy to understand that the calling interface here can be the exported object of the module. The application can use the corresponding functions of the module through the exported object. The exported object can be a function, variable, etc., where the function is used to perform specific tasks or operations and can receive parameters and return values. The variable may contain configuration information, constants or other data that needs to be shared in multiple places. The application can use some functions of the module by calling the module's functions or variables.
[0060] Please refer to Figure 2, which is a schematic diagram of an application management scenario provided in an embodiment of the present application. In Figure 2, the application, module management (or module management system) and multiple modules (such as module one, module two, and module three in Figure 2) belong to the same terminal.
[0061] The application here can be any application of the terminal. For ease of understanding, FRS is used as an example. When FRS renders a card component, it needs to run part of the code of the application corresponding to the card component. For example, when FRS renders a weather card component, it needs to run part of the code of the weather application. When running part of the code of the weather application, it needs to load the internationalization module to use the internationalization module's function of obtaining the current time format and date format. Since the internationalization module has multiple functions, such as obtaining the current time format, setting the time format, obtaining the date format, setting the current application preferred language, etc.; when FRS requests the module management to load the internationalization module, the module management obtains the corresponding configuration information of FRS, determines the calling interface allowed to be called by FRS among the multiple calling interfaces of the internationalization module based on the configuration information, and returns the calling interface allowed to be called by FRS to FRS. Here, the calling interface allowed to be called by FRS can be the calling interface corresponding to the function of obtaining the current time format. The module management determines the management and control policy of the application through the corresponding configuration information of the application, thereby realizing the control of the application loading of the target module by using the interface as the management and control unit.
[0062] Optionally, when the application loads the target module, the application, module management and target module may be in the same process. For example, the FRS, module management and internationalization modules involved in the FRS rendering of the card component are all in the same rendering process.
[0063] Please refer to Figure 3, which is a flow chart of an application management method provided in an embodiment of the present application. The following is an explanation using the module management in Figure 3 as an example. The application management method in Figure 3 includes: S301-S302.
[0064] S301: Receive a loading request from an application, where the loading request is used to request loading a target module.
[0065] It is easy to understand that when FRS renders the card component of the service card, it needs to run part of the code of the application corresponding to the card component. In the process of running part of the code of the application, one or more modules need to be loaded. For example, when rendering weather-related card components, part of the program of the third-party weather application needs to be run. In the process of running part of the program of the third-party weather application, the internationalization module and the camera module need to be loaded. In this case, FRS can send a loading request to the module management to load the corresponding module.
[0066] Optionally, the load request includes an identifier of the module (such as a module name or identifier) so that the module manager can identify and locate the required module based on the identifier.
[0067] S302: Load the target module based on the load request and determine a first target call interface set, where the first target call interface set includes at least one call interface in the target module that is allowed to be called by the application.
[0068] It's easy to understand that each module supports at least one function, each with a corresponding call interface. Applications can use the module's functionality by calling the corresponding call interface, for example, calling the internationalization module's call interface to obtain the terminal's current time format. Based on the load request, the module manager can determine which call interfaces the application is allowed to call and which are not allowed to call from the target module's multiple call interfaces.
[0069] Optionally, after the module is loaded, a calling interface that allows the application to call is sent to the application so that the application can call the calling interface that allows the application to call.
[0070] It is easy to understand that after the module management receives the loading request of the application, the module management loads the target module. The loading process may include: obtaining the location of the target module, and then searching for the module file based on the location of the target module; after finding the module file, parsing the module file, parsing the calling interface in the module file, such as checking the definition and reference of the calling interface, the dependency between the calling interfaces, etc.; it can also allocate necessary memory space for the target module, and load the module code and data into the corresponding memory, and then initialize the module after loading is complete. After initialization is complete, other applications can use the functions provided by the module by calling the calling interface of the module. Here, by determining the interfaces that applications are allowed to call and the interfaces that applications are not allowed to call in the calling interface of the module, so that applications can call the calling interface that is allowed to be called, thereby realizing restrictive loading of the module.
[0071] In this way, when the application loads the target module, the target module is loaded based on the application's application loading request and the target call interface set in the target module and the call interface that the application is not allowed to call are determined, wherein the target call interface set is the call interface in at least one call interface of the target module that is allowed to be called by the application, so that the application calls the call interface in the module that the application is allowed to call; since the module supports multiple call interfaces, each call interface supports specific functions; by determining the call interface that the application is allowed to call, the module is loaded with the interface as the management unit, achieving more refined control of application interface calls, and meeting the user's diverse application interface call restriction configuration requirements. By controlling the module loading of the application, the risk of excessive module loading can also be reduced.
[0072] It's easy to understand that when an application requests to load a target module, the application can include its control policy for the target module in the load request. Module management can then determine, based on the control policy, which of the target module's multiple call interfaces the application is allowed to call. Alternatively, configuration information can be pre-configured for each application, limiting the permissions allowed and / or not allowed for the application. For example, the FRS can load the internationalization module's function for obtaining the current time format, but prohibit the loading of the internationalization module's function for modifying the time format. When an application requests to load a module, module management obtains the application's corresponding first configuration information and then, based on this information, selects the call interface within the target module that the application is allowed to call. Each module has multiple functions, each with a corresponding call interface. By using the application's corresponding first configuration information to limit the call interface that the application can call, a control policy for application module loading is implemented, using interfaces as the control unit. Furthermore, each application has corresponding configuration information. Based on this configuration information, targeted interface call restrictions are imposed on the application, enabling more refined control over the functions accessible to the application.
[0073] It is easy to understand that after the module management obtains the first configuration information corresponding to the application, it can determine whether the application is allowed to load the target module based on the first configuration information. If the application does not allow the target module to be loaded, the process ends, that is, there is no need to load the module; if the application allows the target module to be loaded, the target module is loaded, and during the target module loading process, the first configuration information corresponding to the application is used to limit the calling interface that the application can call and the calling interface that the application cannot call. It is easy to understand that the target module loading process in the embodiment of the present application refers to any period between receiving the load request and loading the target module.
[0074] Optionally, if it is determined based on the first configuration information that the application is not allowed to load the target module, there is no need to load the shared object corresponding to the target module, and a rejection message (such as an empty object) is returned to the application to reject the application from loading the target module.
[0075] It can be understood that service cards include multiple types of card components, such as weather cards and map cards. When rendering each card component, the FRS needs to run a portion of the corresponding application's code. Executing each card component requires loading the corresponding module, such as the internationalization module for the weather card and the location and microphone modules for the map card. To comprehensively restrict the functionality available to the FRS, the corresponding FRS configuration file includes control policies for multiple modules. However, since the FRS only renders one or more service cards at a time, the first configuration information only needs to include the configuration information for the target module currently being requested by the FRS. The module manager first obtains the application's configuration file, which describes the control policies for the application's corresponding modules. For example, the configuration file includes control policies for modules related to the FRS. The module manager then determines the first configuration information corresponding to the target module based on the configuration file. Thus, upon receiving an application's load request, the module manager first obtains the application's configuration file and then selects the control policy for the target module from the configuration file, thereby obtaining the first configuration information. Since the first configuration information only includes controls for the callable interfaces or accessible functions corresponding to the target module, it facilitates subsequent targeted loading restrictions based on the first configuration information.
[0076] Optionally, after the module manager obtains the configuration file of the application, it generates a module loading checker (ModuleLoadChecker) according to the configuration file corresponding to the application. After the module manager receives the loading request of the application, it obtains the first configuration information corresponding to the target module through the ModuleLoadChecker.
[0077] It is easy to understand that the terminal's application has multiple scenarios, which include at least one of the following: the FRS's operating status, the terminal's operating mode, the terminal's operating time period, and the number of times the target module is allowed to be called by the FRS. The FRS's operating status includes FRS as a foreground application and FRS as a background application. The scenario can be the application's operating status, such as FRS running in the background, FRS running in the foreground, or FRS as a foreground application or background application; the scenario can also be the terminal's operating mode, such as the terminal in normal mode, or the terminal in flight mode, or the terminal in power saving mode; the scenario can also be the terminal in different time periods, such as 7:00 am to 9:00 pm, or 12:00 pm to 5:00 am. The application scenario can also limit the number of calls to the target module, such as the number of times the FRS is allowed to call the target module, for example, allowing the application to call the internationalization module only twice within 24 hours. The configuration information corresponding to different application scenarios may vary, that is, the application's corresponding scenario and corresponding application control policy may also differ. For example, when rendering an alarm card, the FRS may load the interface corresponding to the vibration function and the ringing function of the alarm module between 7:00 AM and 9:00 PM; but may only load the interface corresponding to the vibration function of the alarm module between 12:00 PM and 5:00 AM. Therefore, before obtaining the configuration information corresponding to the application, the module manager may first obtain the current scenario corresponding to the application, and then obtain the first configuration information corresponding to the current scenario. In this way, because the first configuration information is determined based on the current scenario of the application and describes the control policy for the application in the current scenario, the callable interfaces allowed to be loaded by the application in the current state are determined based on the first configuration information, enabling targeted control of the application's callable interfaces based on the current scenario, thereby enabling control of the application's available functions according to the application's current scenario.
[0078] In some examples, if the application scenario includes at least two of the FRS's operating status, the terminal's operating mode, the terminal's operating time period, and the number of times the target module is allowed to be called by the FRS; if at least one of the at least two scenarios currently corresponding to the application determines that the application is prohibited from loading the target module, then the application is prohibited from loading the target module; if all of the at least two scenarios currently corresponding to the application allow the application to load the target module, then the application is allowed to load the target module.
[0079] It can be understood that since the application has multiple scenarios, each scenario has corresponding configuration information. For example, the configuration information corresponding to the current scenario of the FRS is the first configuration information, and the target module is loaded based on the first configuration information. When the FRS is transformed from a foreground application to a background application, the scenario corresponding to the FRS changes, and the control policy corresponding to the FRS may also change. Then, the second configuration information corresponding to the scenario after the FRS transformation is obtained. The second configuration information describes the control policy of the FRS after the scenario changes. The module management needs to reload the target module for the application based on the second configuration information so that the loaded module corresponds to the control policy of the current scenario of the FRS. Please refer to Figure 4, which is a flow chart of an application management method provided in an embodiment of the present application. If the first configuration information is the control policy or configuration information of the application in the first scenario, after the target module is loaded, the method described in Figure 4 also includes: S401-S402.
[0080] S401: If the scene corresponding to the application is changed to a second scene, obtain second configuration information corresponding to the second scene.
[0081] Among them, the second scene is different from the first scene.
[0082] It is easy to understand that if the module management detects that the application scenario has changed, the application's management and control strategy may also change due to the change in the application scenario, and the configuration information corresponding to the application will also change accordingly. The module management will then re-acquire the configuration information of the application, that is, obtain the second configuration information corresponding to the current scenario of the application.
[0083] Optionally, when the application scenario changes, the application may send a notification message to the module management to inform the module management that the state of the application has changed.
[0084] Optionally, module management is also used to detect the scenario corresponding to the application, such as detecting whether the scenario of the terminal has changed, detecting changes in time, and detecting changes in the state of the application itself (such as changes between foreground applications and background applications). Module management can periodically send detection messages to other applications or modules, and receive detection responses sent by the application or other modules, and determine whether the scenario corresponding to the application has changed through the detection response.
[0085] Optionally, the module management can also monitor the application scenario based on the first configuration information. For example, the first configuration information carries an associated time period: 7:00 am to 9:00 pm. When the module management detects that the current time of the terminal is not in the associated time period, it determines that the application scenario has changed.
[0086] S402: Reload the target module, and determine, based on the second configuration information, a calling interface in the target module that is allowed to be called by the application in the second scenario.
[0087] It is easy to understand that when the configuration information of the application changes, the module management reloads the target module. During the reloading process of the target module, the calling interface that the application is allowed to call and the calling interface that the application is not allowed to call are selected from the multiple calling interfaces in the loaded module based on the configuration information corresponding to the current scenario (for example, the second scenario), so that the application can use the module's functions by calling the calling interface.
[0088] Optionally, after the target module is reloaded, the module management is further used to unload the previously loaded target module (ie, the target module loaded when the application is in the first scenario).
[0089] In this way, after the target module is loaded according to the configuration information, if the application's corresponding scenario changes, the configuration information corresponding to the application's current scenario (or the changed scenario) is obtained, and the target module is reloaded according to the configuration information corresponding to the current scenario. Because the application's control strategy may vary in different scenarios, after the application's scenario changes, the module is reloaded according to the current scenario to achieve real-time control of the application's control strategy based on the application's scenario changes.
[0090] It can be understood that some applications are in different scenarios, and the control strategies for specific modules are the same. In this case, when it is detected that the application scenario has changed, there is no need to reload the target module; if the control strategies corresponding to the configuration information of the two scenarios before and after the application change are different, the target module can be reloaded according to the new configuration information. After S401, the method also includes: determining whether the control strategies of the target module applied in the first configuration information and the second configuration information are the same; if the control strategies of the target module applied in the first configuration information and the second configuration information are the same, no processing is performed, that is, the target module does not need to be reloaded; if the control strategies of the target module applied in the first configuration information and the second configuration information are different, step S402 is executed.
[0091] It is easy to understand that after the module management loads the target module according to the first configuration information, transition data is obtained due to the user's operation or the processing of the target module itself. The transition data can be some temporary files or some user data. After the application scenario changes, the target module is reloaded, and the module management can obtain the transition data of the previously loaded target module. For example, the transition data can be exported from the target module loaded when the application is in the first scenario, and the transition data can be sent to the reloaded target module (or the target module loaded when the application is in the second scenario) or the transition data can be imported into the reloaded target module so that the reloaded target module can use the transition data, or so that the user or application can use the transition data through the target module.
[0092] In some embodiments, after importing the transition data into the reloaded target module, the module management may unload the target module loaded when the application is in the first scenario.
[0093] Optionally, after the module management receives the loading request of the application, the module management executes the loading of the target module, and during the loading process of the target module, determines the first target call interface set based on the first configuration information. Since each module may support multiple functions and each function has a corresponding call interface, the application uses the function of the module by calling the call interface. The module management side may select the call interface that the application is allowed to call from the multiple call interfaces of the module based on the first configuration information. Then, determining the call interface that the application is allowed to call from the multiple call interfaces of the target module based on the first configuration information includes: the module management obtains the call interface of the target module, and determines the call interface that the application is allowed to call from the call interface of the target module based on the first configuration information. In this way, the module management side filters the multiple call interfaces of the module to select the call interface that can be called by the application from the multiple call interfaces of the module. By selecting the corresponding call interface, the functions of the module that can be used by the application are limited, thereby realizing the restriction of the accessible functions of the application.
[0094] Exemplarily, the target module supports three functions, and each function corresponds to a calling interface, then the module management obtains the three calling interfaces of the target module; then the module management determines, based on the first configuration information, that the application only supports calling one of the calling interfaces, and by limiting the calling interface called by the application, it implements the restriction of the functions of the module used by the application.
[0095] Optionally, during the loading process of the target module, the module management may initialize the target module to obtain the export object of the target module by initializing the target module. The export object includes the calling interface of the target module. The module management filters the export object based on the first configuration information to determine the calling interface in the export object that can be loaded by the application.
[0096] Optionally, the export object obtained by the module management includes the calling interface of the target module, and the calling interface of the target module includes the calling interface that the application is allowed to call and the calling interface that the application is not allowed to call. The calling interface that the application can call in the calling interface of the target module can be determined through the first configuration information, and then the calling interface that the application is not allowed to call is deleted.
[0097] Of course, other methods can also be used to handle the calling interface of the target module that the application is not allowed to call. For example, the calling interface of the target module that the application is not allowed to call is replaced by throwing an exception. In this way, when the application calls the interface, the called object is not returned, but an exception is thrown to handle the error, simplifying the code logic and making the handling of non-callable interfaces clearer and more unified.
[0098] Optionally, after the module management obtains the loading request of the application, the module management executes the loading of the target module. During the loading of the target module, the module management determines the control policy of the application for the target module based on the first configuration information; and sends the control policy to the target module, so that the target module determines the calling interfaces that the application is allowed to call and the interfaces that the application is not allowed to call in the calling interface of the target module based on the control policy. Then, the target module sends an export object to the module management, and the export object carries the calling interfaces that the application is allowed to call in the calling interface of the target module. In this way, by sending the control policy of the application corresponding to the target module to the target module, the target module determines the calling interface that the application is allowed to call from the multiple calling interfaces of the target module based on the control policy, that is, the target module only needs to return the calling interface corresponding to the function allowed by the application to the module management.
[0099] In some embodiments, when the target module determines, based on the control policy, which call interfaces in the target module's call interface are allowed to be called by the application, the call interfaces that the application is not allowed to call may be deleted, so that the exported object only includes the call interfaces that the application is allowed to call. Of course, other methods can also be used to handle the call interfaces in the target module's call interface that the application is not allowed to call, for example, setting the call interfaces in the target module's call interface that the application is not allowed to call to be set to throw an exception.
[0100] It can be understood that when an application requests to load a target module, sometimes in order to simulate some virtual scenarios, the loaded module can be replaced by configuration information. For example, an application requests to load module A, but due to the application's management policy or test environment requirements, after the module management receives the application's request to load module A, the module management determines the actual module to be loaded (module B) based on the first configuration information corresponding to the application, and then the module management executes the loading of module B. After the loading is completed, the calling interface in module B that allows the application to call is returned to the application. After the module management obtains the first configuration information, the method also includes: determining the replacement module corresponding to the target module based on the first configuration information, and loading the replacement module. In this way, by pre-configuring the replacement module of each module in the configuration information, when the application requests to load the module, the loading of the replacement module can be executed according to the configuration information, wherein the replacement module can be a simulation (MOCK) module or any module specified by the user.
[0101] In some embodiments, the first configuration information may include not only the replacement module corresponding to the target module but also the configuration module's management policy for the application. This allows the module manager to select, from among the replacement module's multiple call interfaces, a call interface that the application is permitted to call, when loading the replacement module based on the first configuration information.
[0102] It is easy to understand that in the terminal applications, each application may have multiple cards. For example, Card 1 of a weather application includes weather, and Card 2 of a weather application includes weather and the current time. Different applications have different cards. When FRS renders the cards, for cards of different applications or different cards of the same application, FRS may need to load different modules, or it may need to load the same module. For example, when rendering Card 1 and Card 2 of Application 1, and Card 3 of Application 3, FRS needs to load the GPS module. Since different applications or cards have different functions, when rendering different cards, if FRS loads the same module, the FRS control strategy corresponding to the module may also be different. For example, when FRS renders Card 1 and Card 2, it needs to load the internationalization module. However, when rendering Card 1, FRS can call the internationalization module's three functions corresponding to the call interface for obtaining the current time format, setting the time format, and obtaining the date format. When rendering Card 2, FRS can call the internationalization module's one function corresponding to obtaining the current time format. When FRS triggers the rendering of other cards during the rendering of the current card, the other cards here may be another card of the current application or a card of another application. When FRS renders the card, it forms a new loading request to load the module corresponding to the card. The module may be the target module or another module different from the target module. Since the FRS control policy applied to the modules loaded by FRS may be different during the rendering of different cards, the module management must determine a new target call interface set based on the new loading request in the process of loading modules, that is, the calling interface allowed to be called by FRS in the new module. When FRS renders the card of an application, it needs to load the module corresponding to the application. When rendering different cards of the same application or cards of different applications, it may be necessary to load the same module or different modules. Due to different applications or different cards (for example, different cards of the same application), the control policy for FRS loading modules may also be different. In the process of loading the same module, the new target call interface set is different from the first target call interface set in S302.
[0103] Please refer to Figure 5, which is a flow chart of an application management method provided by an embodiment of the present application. In Figure 5, module management includes ModuleManager, which is used to manage low-level programming interfaces such as module loading and unloading and event response. During the module loading process, ModuleLoadChecker is used to detect whether the application is allowed to load the module. If it is detected that the application is allowed to load the module, ModuleManager executes the loading of the module. ModuleLoadChecker is also used to filter the module's calling interface to determine the calling interface of the module that the application is allowed to call. The application management method includes the following steps:
[0104] S501: When an application is detected to be started, the ModuleManager loads the application's profile, which includes the application's control policies for certain modules or all modules, such as allowing the use of the internationalization module's function to obtain the current time.
[0105] S502: ModuleManager parses the configuration file and generates a module loading checker (ModuleLoadChecker) based on the parsed configuration file. ModuleLoadChecker is used to detect the loading status of the module and handle errors during the loading process.
[0106] S503: When the application needs to load a module, it sends a loading request to the ModuleManager.
[0107] For example, when FRS renders a card component and executes an application corresponding to the card component, it needs to load the modules required to execute the application.
[0108] S504: Load the target module through the ModuleManager. The ModuleManager can obtain the location of the target module and retrieve the module file from the target module's location. The ModuleManager then parses the module file and allocates memory for the target module to facilitate loading. During the module loading process, the ModuleManager uses the ModuleLoadChecker to check whether the application is allowed to load the target module.
[0109] S505. ModuleLoadChecker returns the detection result to ModuleManager.
[0110] If the detection result is that the application is not allowed to load the target module, the ModuleManager returns a rejection message (for example, an empty message) to the application to reject the application from loading the target module, and the process ends.
[0111] If the detection result is that the application is allowed to load the target module, the detection result also includes the application's control policy for the target module.
[0112] S506: If the detection result indicates that the application is allowed to load the target module, the ModuleManager loads the ModuleLibrary. The primary purpose of loading the ModuleLibrary is to provide a unified interface that facilitates application access to modules and related operations, while also providing additional functionality to manage the module loading and usage process. Furthermore, the ModuleManager is used to generate the moduleLibrary loading results.
[0113] S507, ModuleManager calls the register callback function (registercallback) to establish a communication mechanism with the module to initialize the module;
[0114] S508: The module returns an export object to the ModuleManager. The export object includes a calling interface of the target module.
[0115] Optionally, the ModuleManager can obtain the module's export object by calling the module's Init interface.
[0116] S509: Filter the exported object through ModuleLoadChecker to determine the calling interface in the exported object that is allowed to be called by the application.
[0117] Optionally, ModuleLoadChecker determines, based on the first configuration information, calling interfaces in the export object that are allowed to be called by the application, and deletes interfaces that are not allowed to be called by the application.
[0118] S510: ModuleManager returns a calling interface to the application that allows the application to call.
[0119] In this way, when the application of the terminal needs to load a module, the configuration file of the application is obtained, and the terminal is detected based on the configuration file to see whether it allows the target module to be loaded; if the application does not allow the module to be loaded, a rejection message is returned to the application; if the application allows the module to be loaded, the module is loaded, and the calling interface of the module is filtered based on the first configuration file to determine the calling interface that the application is allowed to call, and the calling interface is sent to the application so that the application can use the function of the module based on the received calling interface.
[0120] FIG6 is a flow chart of an application management method provided in an embodiment of the present application. Referring to FIG6 , upon detecting that a change in the application scenario is detected, the application management and control strategy may be different due to the application being in different scenarios. After the application scenario changes, the method further includes:
[0121] S601. ModuleManager reloads the application configuration file.
[0122] Optionally, after detecting that the application scenario has changed, ModuleManager obtains the configuration file corresponding to the current application scenario and reloads the configuration file.
[0123] S602. Optionally, generate a ModuleLoadChecker based on a configuration file of an application in the current scenario.
[0124] S603: Check whether the configuration files corresponding to the application are the same before and after the scene change. Optionally, since each application can load multiple modules and can load multiple modules at the same time, the ModuleManager can compare whether the control policies corresponding to the modules currently loaded by the application have changed.
[0125] If the control policy of the target module currently loaded by the application does not change before and after the scenario changes, no processing is performed.
[0126] S604: If it is detected that the control policy of the target module currently loaded by the application changes before and after the scene changes, the target module with the changed control policy is reloaded.
[0127] Optionally, during the loading process, a calling interface in the target module that is allowed to be called by the application is determined based on the new configuration information, and the calling interface that is allowed to be called by the application is sent to the application.
[0128] S605 , ModuleManager requests the old module to export transition data, where the old module is the target module loaded before the application scenario is changed;
[0129] S606: The old module exports transition data to the ModuleManager.
[0130] S607. ModuleManager sends transition data to the new module so as to import the transition data into the new module. The new module is the target module to be reloaded after the application scenario changes.
[0131] S608: After the new module successfully imports the transition data, it sends the transition data to the ModuleManager to complete the import of the new module.
[0132] Furthermore, after the transition data is imported into the new module, it is also used to perform uninstallation of the old module.
[0133] In this way, after detecting that the application scenario has changed, the configuration file corresponding to the current application scenario is obtained; then the configuration files of the application before and after the scenario change are compared to see if they are the same, that is, whether the control policy of the module currently loaded by the application has changed before and after the scenario change; if the control policy of the module currently loaded by the application has not changed before and after the scenario change, the old target will not be processed; if the control policy of the module currently loaded by the application has changed, the old module with the changed control policy will be reloaded. After the loading is complete, the transition data of the old module will be obtained and imported into the new module so that the application can use the transition data through the new module. Through the above process, the control policy of the application can be controlled in real time according to the changes in the application scenario.
[0134] FIG7 is a flow chart of an application management method provided in an embodiment of the present application. Referring to FIG7 , S701 to S705 in FIG7 are the same as S501 to S505 in FIG5 . For details, please refer to FIG5 , which will not be expanded in detail here. The method further includes:
[0135] S701. When detecting that an application is started, the ModuleManager loads the configuration file (profile) of the application.
[0136] S702. ModuleManager parses the configuration file and generates a module load checker (ModuleLoadChecker) based on the parsed configuration file.
[0137] S703: When the application needs to load a module, it sends a load request to the ModuleManager to load the target module through the ModuleManager.
[0138] S704: During module loading, ModuleManager detects through ModuleLoadChecker whether the application is allowed to load the target module.
[0139] S705. ModuleLoadChecker returns the detection result to ModuleManager.
[0140] If the detection result is that the application is allowed to load the target module, the detection result further includes executing the loading of the replacement module based on the loading request of the application.
[0141] S706: ModuleManager executes loading of the replacement module.
[0142] S707: ModuleManager returns the export object of the replacement module to the application. The export object includes a calling interface in the replacement module that the application is allowed to call.
[0143] In this way, in certain test scenarios or scenarios where users have specific requirements, when the application requests to load the target module, the ModuleLoadChecker generated by the module management based on the first configuration information determines that it is necessary to execute the loading of the replacement module, then executes the loading of the replacement module, and returns the export object of the replacement module to the application, so that the application can use the functions of the replacement module through the calling interface in the export object.
[0144] It can be understood that in the above embodiments, FRS is used as an application for example. It can be understood that in other embodiments, the application can also be other applications of the terminal, such as the system application of the terminal. When the system application runs the third-party application code or the system application runs its own code, it needs to load the target module, then a loading request for the target module is formed and the target module is loaded. After the target module is loaded, the target interface of the target module can be called, and the function of the target module can be used by calling the target interface of the target module. For example, after the terminal receives the user instruction, it runs the map application. Since the map application needs to load the GPS module and the microphone module when it runs, the module management receives the application request of the map application. After the request, obtain the first configuration information corresponding to the map application; determine whether the map application can load the GPS module and the microphone module based on the first configuration information; if not, return a rejection message to the application; if the map application is allowed to load the GPS module and the microphone module, then execute the loading of the GPS module and the microphone module. During the loading of the GPS module and the microphone module, determine the interface in the GPS module and the microphone module that is allowed to be called by the map application based on the first configuration information, and send the interface that is allowed to be called by the map application to the map application. In this way, after the module loading is completed, the map application uses the functions of the GPS module and the microphone module by calling the interface that is allowed to be called. All embodiments of the present application can be implemented through any application of the terminal, that is, the control strategy of any application of the terminal can be managed by the above-mentioned management method.
[0145] It should be understood that the above is only intended to help those skilled in the art better understand the embodiments of the present application, and is not intended to limit the scope of the embodiments of the present application. Based on the above examples given, those skilled in the art can obviously make various equivalent modifications or changes. For example, certain steps in each of the above methods may not be necessary, or certain new steps may be added. Or a combination of any two or any multiple of the above embodiments. Such modifications, changes, or combined solutions also fall within the scope of the embodiments of the present application.
[0146] It should also be understood that the division of the modes, situations, categories and embodiments in the embodiments of the present application is only for the convenience of description and should not constitute a special limitation. The features of various modes, categories, situations and embodiments can be combined without contradiction.
[0147] It should also be understood that the various numerical numbers involved in the embodiments of this application are only for the convenience of description and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0148] It should also be understood that the above description of the embodiments of the present application focuses on emphasizing the differences between the various embodiments. The same or similar points that are not mentioned can be referenced with each other. For the sake of brevity, they will not be repeated here.
[0149] The above description of the method and system embodiments provided by the present application in combination with Figures 1 to 7 is as follows. The module management of the terminal or terminal side provided by the present application embodiment is described below.
[0150] In this embodiment, the terminal can be divided into functional modules according to the above method. For example, each function can be divided into separate functional modules, or two or more functions can be integrated into a single processing module. The integrated modules can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used.
[0151] It should be noted that the relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.
[0152] The terminal provided in the embodiment of the present application is used to execute the application management method provided in the above method embodiment, and thus can achieve the same effect as the above implementation method.
[0153] In other embodiments, when integrated units are used, the terminal may include a processing module, a storage module, and a communication module. The processing module may be used to control and manage the terminal's operations. For example, it may be used to support the terminal in executing steps performed by the processing unit. The storage module may be used to support the storage of program code and data. The communication module may be used to support communication between the terminal and other devices.
[0154] The processing module may be a processor or a controller. It may be a device that implements or executes the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processing (DSP) and a microprocessor, and so on. The storage module may be a memory. The communication module may specifically be a device that interacts with other terminals, such as a radio frequency circuit, a Bluetooth chip, or a Wi-Fi chip.
[0155] Based on the same concept, an embodiment of the present application further provides a terminal. Please refer to FIG8 , which is a schematic structural diagram of the terminal provided in an embodiment of the present application.
[0156] The following first introduces the terminal (ie, the first terminal or the second terminal) involved in the embodiment of the present application. Please refer to FIG4 , which shows a schematic structural diagram of a terminal 800 .
[0157] The terminal 800 may include a processor 810, an external memory interface 820, an internal memory 821, a universal serial bus (USB) interface 830, a charging management module 840, a power management module 841, a battery 842, an antenna 1, an antenna 2, a mobile communication module 850, a wireless communication module 860, a sensor module 870, a button 880, and a display screen 890. The sensor module 870 may include a pressure sensor 870A, a gyroscope sensor 870B, an acceleration sensor 870C, a temperature sensor 870D, a touch sensor 870E, and the like.
[0158] It is understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on terminal 800. In other embodiments of the present application, terminal 800 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.
[0159] The processor 810 may include one or more processing units. For example, the processor 810 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.
[0160] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.
[0161] Processor 810 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 810 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 810. If processor 810 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 810 latency, and thus improves system efficiency.
[0162] In some embodiments, the processor 810 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 subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface.
[0163] The I2C interface is a bidirectional synchronous serial bus that includes a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 810 may include multiple I2C bus lines. The processor 810 may be coupled to the touch sensor 870E, a charger, etc. via different I2C bus interfaces. For example, the processor 810 may be coupled to the touch sensor 870E via the I2C interface, enabling communication between the processor 810 and the touch sensor 870E via the I2C bus interface, thereby implementing the touch function of the terminal 800.
[0164] The UART interface is a universal serial data bus for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is generally used to connect the processor 810 and the wireless communication module 860. For example, the processor 810 communicates with the Bluetooth module in the wireless communication module 860 via the UART interface to implement the Bluetooth function. The MIPI interface can be used to connect the processor 810 to peripheral devices such as the display screen 890. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 810 and the display screen 890 communicate via the DSI interface to implement the display function of the terminal 800.
[0165] The GPIO interface can be configured via software. It can be configured as either a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 810 to the display 890, wireless communication module 860, sensor module 870, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.
[0166] USB interface 830 is an interface that complies with USB standards and specifications, and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. USB interface 830 can be used to connect a charger to charge terminal 800, or to transfer data between terminal 800 and peripheral devices. It can also be used to connect headphones to play audio. This interface can also be used to connect to other terminals, such as AR devices.
[0167] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present application is merely an illustrative description and does not constitute a structural limitation on the terminal 800. In other embodiments of the present application, the terminal 800 may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.
[0168] The charging management module 840 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 840 can receive charging input from the wired charger via the USB interface 830. In some wireless charging embodiments, the charging management module 840 can receive wireless charging input via the wireless charging coil of the terminal 800. While charging the battery 842, the charging management module 840 can also provide power to the terminal via the power management module 841.
[0169] The power management module 841 is used to connect the battery 842, the charging management module 840, and the processor 810. The power management module 841 receives input from the battery 842 and / or the charging management module 840 and provides power to the processor 810, the internal memory 821, the display 890, and the wireless communication module 860. The power management module 841 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 841 can also be provided in the processor 810. In other embodiments, the power management module 841 and the charging management module 840 can also be provided in the same device.
[0170] The wireless communication function of the terminal 800 can be implemented through antenna 1, antenna 2, mobile communication module 850, wireless communication module 860, modem processor and baseband processor.
[0171] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in Terminal 800 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, Antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with a tuning switch.
[0172] The mobile communication module 850 can provide solutions for wireless communications including 2G / 3G / 8G / 5G applied on the terminal 800. The mobile communication module 850 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 850 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 850 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 850 can be set in the processor 810. In some embodiments, at least some of the functional modules of the mobile communication module 850 can be set in the same device as at least some of the modules of the processor 810.
[0173] The modem processor may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium- or high-frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is passed to the application processor. The application processor displays images or videos through the display screen 890. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 810 and be provided in the same device as the mobile communication module 850 or other functional modules.
[0174] The wireless communication module 860 can provide wireless communication solutions 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), infrared technology (IR), etc. applied on the terminal 800. The wireless communication module 860 can be one or more devices integrating at least one communication processing module. The wireless communication module 860 receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 810. The wireless communication module 860 can also receive the signal to be sent from the processor 810, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.
[0175] In some embodiments, antenna 1 of terminal 800 is coupled to mobile communication module 850, and antenna 2 is coupled to wireless communication module 860, so that terminal 800 can communicate with a network and other devices via wireless communication technologies. The wireless communication technologies may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).
[0176] Terminal 800 implements display functions through a GPU, display screen 890, and an application processor. The GPU is a microprocessor for image processing that connects display screen 890 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 810 may include one or more GPUs that execute program instructions to generate or modify display information.
[0177] Display screen 890 is used to display images, videos, and the like. Display screen 890 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-oLed, or a quantum dot light-emitting diode (QLED). In some embodiments, terminal 800 may include one or N display screens 890, where N is a positive integer greater than one.
[0178] The digital signal processor is used to process digital signals. In addition to processing digital image signals, it can also process other digital signals. For example, when the terminal 800 selects a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.
[0179] Video codecs are used to compress or decompress digital video. Terminal 800 may support one or more video codecs. This allows Terminal 800 to play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, and MPEG4.
[0180] The NPU is a neural network (NN) computing processor. Drawing on the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it rapidly processes input information and can continuously self-learn. The NPU enables intelligent cognitive applications on the Terminal 800, such as image recognition, face recognition, speech recognition, and text comprehension.
[0181] The external memory interface 820 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal 800. The external memory card communicates with the processor 810 via the external memory interface 820 to implement data storage functions. For example, files such as videos can be stored in the external memory card.
[0182] The internal memory 821 can be used to store computer executable program codes, which include instructions. The internal memory 821 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as an image playback function, etc.), etc. The data storage area may store data created during the use of the terminal 800 (such as a phone book, etc.), etc. In addition, the internal memory 821 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 810 executes various functional applications and data processing of the terminal 800 by running instructions stored in the internal memory 821 and / or instructions stored in a memory provided in the processor.
[0183] Pressure sensor 870A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 870A can be located on display screen 890. There are many types of pressure sensors 870A, such as resistive, inductive, and capacitive. A capacitive pressure sensor can include at least two parallel plates made of conductive material. When force is applied to pressure sensor 870A, the capacitance between the electrodes changes. Terminal 800 determines the intensity of the pressure based on this change in capacitance. When a touch operation is applied to display screen 890, terminal 800 detects the touch intensity based on pressure sensor 870A. Terminal 800 can also calculate the touch location based on the detection signal from pressure sensor 870A. In some embodiments, touch operations applied to the same touch location but with different touch intensities can correspond to different operation instructions. For example, when a touch operation with an intensity less than a first pressure threshold is applied to a short message application icon, a command to view short messages is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to a short message application icon, a command to create a new short message is executed.
[0184] The gyroscope sensor 870B can be used to determine the motion posture of the terminal 800. In some embodiments, the angular velocity of the terminal 800 around three axes (i.e., the x, y, and z axes) can be determined by the gyroscope sensor 870B. The gyroscope sensor 870B can be used for navigation and somatosensory gaming scenes.
[0185] Accelerometer 870C can detect the magnitude of acceleration of terminal 800 in all directions (generally three axes). When terminal 800 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify terminal posture, enabling applications such as switching between landscape and portrait modes and pedometers.
[0186] The temperature sensor 870D is used to detect temperature. In some embodiments, the terminal 800 uses the temperature detected by the temperature sensor 870D to implement a temperature handling strategy. For example, when the temperature reported by the temperature sensor 870D exceeds a threshold, the terminal 800 reduces the performance of a processor located near the temperature sensor 870D to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is below another threshold, the terminal 800 heats the battery 842 to prevent the terminal 800 from shutting down abnormally due to low temperature. In other embodiments, when the temperature is below yet another threshold, the terminal 800 boosts the output voltage of the battery 842 to prevent the terminal 800 from shutting down abnormally due to low temperature.
[0187] Touch sensor 870E, also known as a "touch device," can be disposed on display screen 890. Touch sensor 870E and display screen 890 form a touch screen, also known as a "touch screen." Touch sensor 870E is configured to detect touch operations applied thereto or in the vicinity thereof. The touch sensor can transmit the detected touch operations to an application processor to determine the type of touch event. Visual output related to the touch operations can be provided via display screen 890. In other embodiments, touch sensor 870E can also be disposed on the surface of terminal 800, at a location different from that of display screen 890.
[0188] Keys 880 include a power button, a volume button, etc. Keys 880 may be mechanical keys or touch keys. Terminal 800 may receive key inputs and generate key signal inputs related to user settings and function control of terminal 800.
[0189] The software system of the terminal 800 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a microservice architecture, or a cloud architecture. For example, the software system of the terminal 800 can adopt an Android operating system (OS), a Harmony OS, or an IOS with a layered architecture. The embodiment of the present application takes the Android system with a layered architecture as an example to illustrate the software structure of the terminal 800.
[0190] The terminal provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effects are similar, which will not be repeated here.
[0191] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method described in the above method embodiment is implemented.
[0192] An embodiment of the present application further provides a computer program product, which, when executed on a terminal, enables the terminal to implement the method described in the above method embodiment.
[0193] An embodiment of the present application provides a chip, including a processor, for calling and executing instructions stored in a memory, so that a communication device equipped with the chip executes the method described in the above method embodiment executed by any terminal provided in the embodiment of the present application.
[0194] The present application also provides a chip system, including a processor coupled to a memory, wherein the processor executes a computer program stored in the memory to implement the method described in the above method embodiment. The chip system can be a single chip or a chip module composed of multiple chips.
[0195] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, hard disk or tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).
[0196] Those skilled in the art will appreciate that all or part of the process steps in the above-described method embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program can include the process steps in the above-described method embodiments. The aforementioned storage medium can include various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.
[0197] The naming or numbering of steps in this application does not mean that the steps in the method flow must be executed in the time / logical sequence indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effects can be achieved.
[0198] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.
[0199] In the 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 / equipment embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0200] It should be understood that in the description of this application and the appended claims, the terms "comprises," "includes," "has," and any variations thereof are intended to cover non-exclusive inclusions and mean "including but not limited to," unless otherwise specifically emphasized. For example, a process, method, system, product, or apparatus that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to the process, method, product, or apparatus.
[0201] In the description of this application, unless otherwise specified, " / " indicates that the objects associated with each other are in an "or" relationship. For example, A / B can represent A or B. "And / or" in this application is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural.
[0202] Furthermore, in the description of this application, unless otherwise specified, "plurality" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, "at least one of a, b, or c" can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural.
[0203] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.
[0204] In addition, in the description of this application specification and the appended claims, the terms "first," "second," etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or precedence, nor should they be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein; and features specified as "first" or "second" may explicitly or implicitly include at least one of such features.
[0205] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.
[0206] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized.
[0207] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.
Claims
1. An application management method, characterized in that: Applied to a terminal, the method comprises: Rendering a first card corresponding to the first application of the terminal through a card rendering service FRS; receiving a first load request from the FRS, where the first load request is used to request loading of a first target module; Based on the first loading request, the first target module is loaded and a first target calling interface set is determined, where the first target calling interface set includes at least one calling interface in the first target module that is allowed to be called by the FRS.
2. The method according to claim 1, characterized in that The step of loading the first target module and determining a first target calling interface set based on the first loading request includes: Acquire first configuration information of the FRS; The first target module is loaded based on the first loading request, and a first target calling interface set is determined according to the first configuration information.
3. The method according to claim 2, characterized in that The first configuration information is configuration information corresponding to the FRS in a first scenario, where the first scenario includes at least one of an operating state of the FRS, an operating mode of the terminal, an operating time period of the terminal, and a number of times the first target module is allowed to be called by the FRS; The method further comprises: When the scene corresponding to the FRS is changed to a second scene, obtaining second configuration information corresponding to the FRS in the second scene; The first target module is reloaded, and a second target calling interface set is determined according to the second configuration information, where the second target calling interface set includes at least one calling interface in the first target module that is allowed to be called by the FRS in a second scenario.
4. The method according to claim 2 or 3, characterized in that: After receiving the first load request of the FRS, the method further includes: A replacement module corresponding to the first target module is determined according to the first configuration information, and the replacement module is loaded.
5. The method according to any one of claims 2 to 4, characterized in that The determining the first target calling interface set according to the first configuration information includes: receiving a calling interface of the first target module sent by the first target module; A first target calling interface set in the calling interface of the first target module is determined according to the first configuration information.
6. The method according to any one of claims 2 to 4, characterized in that The determining the first target calling interface set according to the first configuration information includes: Determining a control strategy of the FRS for the first target module according to the first configuration information; Sending the control strategy to the first target module; The export object of the first target module is obtained, where the export object is determined by the first target module according to the management and control strategy, and the export object includes the first target call interface set.
7. The method according to claim 3, characterized in that After determining the second target call interface set according to the second configuration information, the method further includes: Acquire transition data of a first target module loaded by the FRS in a first scenario; The transition data is imported into a first target module loaded by the FRS in a second scenario.
8. The method according to claim 3 or 7, characterized in that: Before reloading the first target module, the method further includes: Determine whether the control strategy of the FRS for the first target module in the first configuration information and the second configuration information is the same; When the control strategies of the FRS for the first target module in the first configuration information and the second configuration information are different, the first target module is reloaded.
9. The method according to claim 2, characterized in that: Before loading the first target module based on the first loading request, the method further includes: Determining whether to allow the FRS to load the first target module according to the first configuration information; When the FRS is allowed to load the first target module, the first target module is loaded based on the first loading request.
10. The method according to claim 2, characterized in that The obtaining the first configuration information of the FRS includes: querying a module loading checker whether the FRS is allowed to load a first target module, the module loading checker being generated based on a configuration file of the FRS; A query result is obtained. If the FRS is allowed to load the first target module, the query result carries first configuration information.
11. The method according to claim 10, characterized in that The first configuration information describes the control strategy of the FRS for the first target module, and the configuration file describes the control strategy of the FRS for the module of the terminal.
12. The method according to any one of claims 1 to 11, characterized in that After loading the first target module based on the first loading request and determining a first target call interface set, the method further includes: The calling interface in the first target calling interface set that is not allowed to be called by the FRS is deleted, or the calling interface in the first target calling interface set that is not allowed to be called by the FRS is set to throw an exception.
13. The method according to any one of claims 1 to 12, characterized in that The method further comprises: When the first target module is loaded, the first target call interface set is sent to the FRS.
14. The method according to any one of claims 1 to 13, characterized in that The method further comprises: Rendering, by the FRS, a second card corresponding to the first application of the terminal or a third card of the second application of the terminal; receiving a second load request from the FRS, where the second load request is used to request loading of a second target module; The second target module is loaded based on the second loading request and a third target calling interface set is determined, where the third target calling interface set includes at least one calling interface in the second target module that is allowed to be called by the FRS.
15. An application management method, applied to a terminal, characterized in that: The method comprises: System applications run the code of third-party applications; Based on the system application's request to load the target module, the system application loads the target module; the target module is a module that needs to be loaded to run the code of the third-party application; The system application calls the target interface in the target module; the target interface includes an interface in the target module that allows the code of the third-party application to call.
16. The method according to claim 15, characterized in that The method further comprises: Acquire first configuration information of the system application; The target interface is determined according to the first configuration information.
17. The method according to claim 16, characterized in that The first configuration information is configuration information corresponding to the system application in a first scenario, and the first scenario includes at least one of an operating state of the system application, an operating mode of the terminal, an operating time period of the terminal, and a number of calls of the target module allowed by the system application; The method further comprises: When the scene corresponding to the system application changes to a second scene, obtaining second configuration information corresponding to the system application in the second scene; The target module is reloaded, and a second target calling interface set is determined according to the second configuration information, where the second target calling interface set includes at least one calling interface in the target module that is allowed to be called by the system application in a second scenario.
18. The method according to claim 16 or 17, characterized in that The method further comprises: A replacement module corresponding to the target module is determined according to the first configuration information, and the replacement module is loaded.
19. A terminal, characterized in that: include: a memory including computer-readable instructions; A processor in communication with the memory, the processor being configured to execute the computer-readable instructions so that the terminal executes the application management method of any one of claims 1-14 or the application management method of any one of claims 15-18.
20. A computer-readable storage medium, characterized in that: The method comprises a program or an instruction, which, when executed by a processor, implements the application management method according to any one of claims 1 to 14 or the application management method according to any one of claims 15 to 18.
21. A chip, characterized in that: It includes a processor, which is used to call and run instructions stored in the memory from the memory, so that a terminal equipped with the chip executes the application management method according to any one of claims 1 to 14 or the application management method according to any one of claims 15 to 18.
Citation Information
Patent Citations
Method and device for executing functions in application program
CN108717365A
Interface calling method and device, computer device and storage medium
CN109871287A
Application permission management method, device and equipment and storage medium
CN111523136A
Function calling method and device
CN114968384A
Function calling method and device of application program, processor and electronic equipment
CN116909660A