Card display method, electronic equipment and readable storage medium

Abstract

The invention provides a card display method, electronic equipment and a readable storage medium, in the method, a first application displays a card of a second application, a card rendering service sends a card information updating request to a target system service, and the card information updating request is used for requesting updating information of the card. The target system service verifies the permission of the second application, the target system service sends update information of the card to the card rendering service in response to the permission verification passing of the second application, and the card rendering service sends the update information of the card to the first application; and the first application displays the updated card according to the updating information of the card. In the application, when the information of the card is updated, the card rendering service can directly request the update information of the card from the target system service, the application process of the second application does not need to be pulled up, and the second application requests the update information of the card from the target system service, so that the power consumption can be reduced, and the card display efficiency can be improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of terminal technology, and in particular to a card display method, an electronic device, and a readable storage medium. Background Art

[0002] Cards are a way for electronic devices to display information. Currently, cards can be created on the desktop of electronic devices and the interface of application programs, and cards can display information. For example, weather cards, calendar cards, and clock cards can be created on the desktop. Weather cards can display weather information, calendar cards can display calendar information, and clock cards can display time information.

[0003] Currently, after a card is created, when the information in the card needs to be updated, the process of the corresponding application can be started, and the process of the application can call the interface of the system service to obtain the updated information of the card so that the card can display the updated information in time. Currently, each time the information in the card is updated, the process of the corresponding application needs to be started, which consumes a lot of power and has low efficiency. Summary of the invention

[0004] The embodiments of the present application provide a card display method, an electronic device, and a readable storage medium, in which a card rendering service directly requests update information of a card from a target system service without starting an application process of a second application, thereby reducing power consumption and improving card display efficiency.

[0005] In the first aspect, an embodiment of the present application provides a card display method, and the execution subject of the card display method can be an electronic device or a chip in the electronic device. The following description takes the electronic device as an example. The electronic device may include a first application, a second application, a card rendering service, and a target system service. In this method, the first application displays the card of the second application, and when the information in the card needs to be updated, the card rendering service sends a card information update request to the target system service, and the card information update request is used to request the update information of the card. In some examples, for example, the card rendering service may send a card information update request to the target system service periodically or at intervals.

[0006] In response to the card information update request, the target system service may verify the permissions of the second application. In response to the second application passing the permission verification, the target system service sends the updated information of the card to the card rendering service. The card rendering service sends the updated information of the card to the first application, and the first application displays the updated card according to the updated information of the card.

[0007] In an embodiment of the present application, when an electronic device updates a card, there is no need to start the application process of the second application, and have the second application request the target system service for the card update information. Instead, the card rendering service directly requests the target system service for the card update information, which can reduce the power consumption of the electronic device and improve the card display efficiency.

[0008] In one possible implementation, the card rendering service includes a virtual machine corresponding to the second application, and the virtual machine corresponding to the second application can be created by the card rendering service. In some examples, when the electronic device displays the card of the second application for the first time, the card rendering service can create a virtual machine corresponding to the second application, and the virtual machine corresponding to the second application is referred to as the virtual machine below.

[0009] In some examples, the card information update request may include verification information of the card rendering service and an identification of the virtual machine. The electronic device may include an authentication service.

[0010] In an embodiment of the present application, the target system service verifying the permissions of the second application may specifically include: the target system service may send a verification request to the authentication service in response to the card information update request, and the verification request includes the verification information of the card rendering service and the identifier of the virtual machine. Wherein, the authentication service may obtain the verification information of the second application based on the verification information of the card rendering service and the identifier of the virtual machine in response to the verification request, and the authentication service may verify the permissions of the second application based on the verification information of the second application.

[0011] In this implementation, the authentication service in the system service verifies the authority of the second application, which can improve verification security.

[0012] In a possible implementation, the electronic device further includes a card management service. The card management service includes: a first mapping relationship between the verification information of the second application and the identifier of the virtual machine.

[0013] In some examples, the authentication service may include an authentication interface. The target system service may call the authentication interface of the authentication service in response to the card information update request and send the verification request to the authentication service. In an embodiment of the present application, because the card management service stores a first mapping relationship between the verification information of the second application and the identifier of the virtual machine, the authentication service may send the identifier of the virtual machine to the card management service in response to the verification request based on the verification information of the card rendering service to request the verification information of the second application from the card management service. Among them, the card management service may send the verification information of the second application to the authentication service in response to the identifier of the virtual machine from the authentication service based on the identifier of the virtual machine and the first mapping relationship, so that the authentication service can verify the permissions of the second application.

[0014] In an embodiment of the present application, the first mapping relationship is stored in the card management service. On the one hand, it can improve the security of the verification information. On the other hand, the verification information of the second application stored in the card management service and the first mapping relationship of the virtual machine identifier can also assist the authentication service in verifying the permissions of the second application, so as to enable the card rendering service to directly request the target system service for card update information.

[0015] In one possible implementation, the authentication service includes: a second mapping relationship between the verification information of the second application and the permissions of the second application, so that the authentication service can verify the permissions of the second application. In some examples, the permissions of the second application in the second mapping relationship can be understood as: the second application has the permission to call the system service. In some examples, the permissions of the second application in the second mapping relationship can include the identifier of at least one system service that the second application can call.

[0016] The authentication service receives verification information of the second application from the card management service, and the authentication service can determine whether the second application has the authority to call the target system service based on the verification information of the second application and the second mapping relationship.

[0017] In the embodiment of the present application, the authentication service can cooperate with the card management service to verify the verification information of the second application, which can improve the verification security.

[0018] In a possible implementation, after the authentication service determines whether the second application has the permission to call the target system service, when the second application has the permission to call the target system service, the authentication service determines that the permission check of the second application has passed, and sends a verification success message to the target system service. In response to the verification success message, the target system service can send the update information of the card to the card rendering service, so that the card can be updated.

[0019] Among them, after the authentication service determines whether the second application has the permission to call the target system service, when the second application does not have the permission to call the target system service, the authentication service determines that the permission check of the second application has failed and sends a check failure message to the target system service, and the target system service sends a call failure message to the card rendering service.

[0020] In an embodiment of the present application, by checking the permissions of the second application, it can be determined whether the second application has the permission to call the target system service. When the second application has the permission to call the target system service, the target system service can send the update information of the card to the card rendering service, and the card can be updated. When the second application does not have the permission to call the target system service, the target system service may not send the update information of the card to the card rendering service. In an embodiment of the present application, it can be ensured that the use permission of the target system service is only effective for specific applications, thereby improving system security.

[0021] The above describes the process of the first application displaying the updated card. The following describes the process of the first application displaying the card of the second application:

[0022] In a possible implementation, the authentication service may include a registration interface. The second application may call the registration interface of the authentication service to register the verification information of the second application. The card rendering service may call the registration interface to register the verification information of the card rendering service. In a possible implementation, the verification information of the second application is a token, the verification information of the card rendering service is a token, and the identifier of the virtual machine corresponding to the second application is the thread number of the thread in the virtual machine corresponding to the second application.

[0023] Exemplarily, when a user triggers a first application to display a card of a second application, the first application may send a card creation request to the card management service, the card creation request including an identifier of the second application and an identifier of the card. The card management service establishes a connection with the second application based on the identifier of the second application. The second application may send verification information of the second application to the card management service.

[0024] Among them, the card management service can detect whether the verification information of the second application has been stored in the card management service. Among them, when the verification information of the second application has been stored in the card management service, it indicates that the electronic device has created a card for the second application, and the card management service can send a rendering instruction to the card rendering service, and the rendering instruction is used to instruct the card rendering service to obtain the graphic node tree of the card. Alternatively, when the verification information of the second application is not stored in the card management service, it indicates that the electronic device has not created a card for the second application, or the cards of the second application have been completely deleted, and the card management service stores the verification information of the second application and sends the rendering instruction to the card rendering service.

[0025] In a possible implementation, the rendering instruction includes an identifier of the second application and an identifier of the card. In response to the rendering instruction, the card rendering service may determine whether the card rendering service includes a virtual machine corresponding to the second application according to the identifier of the second application.

[0026] Wherein, when the card rendering service determines that the card rendering service includes the virtual machine, the card rendering service can obtain the layout code of the card according to the identification of the card, and obtain the graphic node tree according to the layout code of the card. Wherein, when the card rendering service determines that the card rendering service does not include the virtual machine according to the identification of the second application, the card rendering service can create the virtual machine, and the card rendering service can send the identification of the virtual machine to the card management service so that the card management service stores the verification information of the second application and the first mapping relationship between the identification of the virtual machine.

[0027] When the card rendering service determines, based on the identifier of the second application, that the virtual machine is not included in the card rendering service, the card rendering service may obtain the layout code of the card based on the identifier of the card, and obtain the graphic node tree based on the layout code of the card.

[0028] In the embodiment of the present application, the graphic node tree can represent the layout of the card, and the purpose of the card rendering service obtaining the graphic node tree is to enable the first application to display the card of the second application according to the graphic node tree.

[0029] In a possible implementation, the embodiment of the present application can obtain the information of the card of the second application in the following two ways:

[0030] First, the second application obtains the information of the card of the second application. The second application may send a card information acquisition request to the target system service, and the card information acquisition request is used to request the card information. In response to the card information acquisition request, the target system service may send the card information to the second application. The second application sends the card information to the card rendering service.

[0031] Second, the card rendering service obtains the card information of the second application. The card rendering service may send a card information acquisition request to the target system service, and the card information acquisition request is used to request the card information. The target system service verifies the permission of the second application, and in response to the permission verification of the second application passing, the target system service sends the card information to the card rendering service. The process of the target system service verifying the permission of the second application can refer to the relevant description in the above embodiment.

[0032] In an embodiment of the present application, when creating a card, the card rendering service can also directly request the target system service to obtain the card information. Compared with the method in which the second application requests the target system service to obtain the card information and then sends it to the card rendering service, it can reduce signaling overhead and improve card display efficiency.

[0033] In a possible implementation, after the card rendering service obtains the card information and the graphic node tree, the card rendering service may send the graphic node tree and the card information to the first application, wherein the first application displays the card according to the graphic node tree and the card information.

[0034] In a second aspect, an embodiment of the present application provides an electronic device, which may include: a processor and a memory. The memory is used to store computer executable program code, and the program code includes instructions; when the processor executes the instructions, the instructions cause the electronic device to execute the method in the first aspect.

[0035] In a third aspect, an embodiment of the present application provides an electronic device, which may include a unit, a module or a circuit for executing the method provided in the first aspect above.

[0036] In a fourth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method in the first aspect.

[0037] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a computer, the computer executes the method in the first aspect above.

[0038] The beneficial effects of the possible implementation methods of the second to fifth aspects mentioned above can be referred to the beneficial effects brought about by the first aspect mentioned above, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1A A schematic diagram of the process of creating and displaying an exemplary card;

[0040] Figure 1B A schematic diagram of a process created for an exemplary plurality of cards;

[0041] Figure 2A A schematic diagram of the process of creating and displaying an exemplary card;

[0042] Figure 2B A schematic diagram of a process created for an exemplary plurality of cards;

[0043] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of the structure of another electronic device provided in an embodiment of the present application;

[0045] Figure 5A A flowchart of a card display method provided in an embodiment of the present application;

[0046] Figure 5B A schematic diagram of a card creation process provided in an embodiment of the present application;

[0047] Fig. 6A A flowchart of another card display method provided in an embodiment of the present application;

[0048] Figure 6B A schematic diagram of a card display process provided in an embodiment of the present application;

[0049] Figure 7 A schematic diagram of different card providers having different permissions provided in an embodiment of the present application;

[0050] Figure 8 A schematic diagram of an interface of an electronic device provided in an embodiment of the present application;

[0051] Fig. 9 A schematic diagram of a flow chart of another card display method according to an embodiment of the present application;

[0052] Fig.10 A schematic diagram of the structure of another electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] Definitions of terms used in the embodiments of this application:

[0054] Card / Card Component: A development component in the application framework field that can be embedded in an application and display relevant information. For example, a widget (or small component) is a card component. In some embodiments, cards may include but are not limited to: weather cards, clock cards, calendar cards, memo cards, navigation cards, music cards, gallery cards, etc.

[0055] Card provider: An application that provides card display content. Card providers control the card display content, control layout, and control click events. For example, a weather application is the provider of a weather card.

[0056] Card consumer: The host application that displays the card content. The card consumer is used to control the location of the card in the host application. For example, if the user adds a weather card to the desktop, the desktop application is the card consumer of the weather card.

[0057] In some embodiments, the card user may be a system application; for example, a desktop application, a negative one screen application, or a service center application.

[0058] In other embodiments, the card user may be a third-party application.

[0059] In some embodiments, the card user may be the first application and the card provider may be the second application.

[0060] Form manager service (FMS): is a system service responsible for managing the life cycle of cards and maintaining card data. Operations such as adding, refreshing, and deleting cards are all managed by FMS. FMS is also used to support communication between card providers and card users.

[0061] Form Rendering Service (FRS): is a system service. When creating a card, FMS can start the FRS process to run the card layout code. FRS can parse the card layout code and construct the graphic node tree required for card rendering. FRS can send the graphic node tree to the card user, and the card user can display the card according to the graphic node tree.

[0062] Graphical node tree: represents the card layout in the form of a node tree.

[0063] The electronic device in the embodiments of the present application may be referred to as user equipment (UE), terminal, etc. For example, the electronic device may be a mobile phone, a tablet, a personal digital assistant (PDA), a handheld device with a wireless communication function, a computing device, a vehicle-mounted device or a wearable device, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control, a wireless terminal in a smart home, etc. The form of the electronic device is not specifically limited in the embodiments of the present application.

[0064] The following takes "Creating a weather card on the desktop" as an example to illustrate the current card creation and display process:

[0065] Figure 1A A flow chart showing the creation and display of an exemplary card. Figure 1A , currently the card creation and display process can include:

[0066] S101, the card user sends a card creation request to the FMS.

[0067] Exemplarily, when a user triggers the creation of a weather card on the desktop, the desktop application can act as a card user and send a card creation request to the FMS. The card creation request can include an identifier of the card provider, such as an identifier of a weather application. The identifier of a weather application can be, for example, a name or number of the weather application, which is not described in detail in the embodiments of the present application.

[0068] S102, FMS establishes a connection with the card provider.

[0069] In some embodiments, the card provider may run an application process that is responsible for the card provider's card-related services. Accordingly, the FMS may establish a connection with the card provider's application process based on the card provider's identification in response to a card creation request from the card user. After the FMS card provider's application process is connected, the card user's application process and the card provider's application process may implement inter-process communication through the FMS.

[0070] S103, FMS pulls up FRS.

[0071] In some embodiments, the FMS pulling up the FRS can also be understood as the FMS calling the FRS.

[0072] In some embodiments, S103 is an optional step. For example, in a scenario where multiple cards are created, if the FRS has been pulled up by the FMS, the FMS does not need to pull up the FRS again, and the FRS can directly execute S104.

[0073] There is no order distinction between S102 and S103.

[0074] S104, FRS constructs a graphic node tree according to the layout code of the card.

[0075] The embodiment of the present application does not elaborate on the process of constructing a graphic node tree based on the card layout code of the FRS, and reference may be made to the relevant description in the prior art.

[0076] In some embodiments, the layout code of the card can be deployed in the installation package of the card provider. After the FRS is pulled up, the FRS can request the layout code of the card from the card provider, or the FRS can search for the layout code of the card by itself at the location where the installation package of the card provider is stored, which is not limited in the embodiments of the present application.

[0077] S105, FRS sends the graphic node tree to the card user.

[0078] Exemplarily, after constructing the graphic node tree of the weather card based on the layout code of the weather card, the FRS may send the graphic node tree of the weather card to the desktop application.

[0079] S106: The card user displays the card according to the graphic node tree.

[0080] Exemplarily, the graphic node tree of the card can be a graphic resource; for example, the resources of each component of the card. The desktop application can display a weather card according to the graphic node tree of the weather card. Exemplarily, the weather card can include: the current temperature, the lowest temperature and the highest temperature today, and pictures representing the weather (such as sunny, cloudy, heavy rain, light rain, etc.).

[0081] After the card user displays the weather card, because the weather information changes in real time, the card user needs to update the weather card in real time. Updating the weather card can be understood as updating the information in the weather card. In some embodiments, the process of updating the weather card can refer to S107-S111:

[0082] S107, FRS sends a card information update request to the card provider.

[0083] In some embodiments, the FRS may periodically send a card information update request to the card provider to request an update of the information in the card.

[0084] In some embodiments, the FRS may send a card information update request at different periods for different card providers. For example, for news cards, the FRS may send a card information update request to the card provider every 3 minutes, and for weather cards, the FRS may send a card information update request to the card provider every 10 minutes. This embodiment of the present application does not limit this.

[0085] In some embodiments, the FRS may send a card information update request to the card provider through the FMS, wherein the FRS may send the card information update request to the FMS, and the FMS may transmit the card information update request to the card provider.

[0086] S108, the card provider calls the system application programming interface (API) to obtain update information.

[0087] In some embodiments, the FMS can launch the application process of the card provider, and the card provider calls the system API to obtain updated information of the card. Exemplarily, in response to a card information update request from the FRS, the FMS can launch the application process of the weather application, and the weather application can call the system API for providing weather information to obtain updated weather information.

[0088] S109: The card provider sends update information to the FRS.

[0089] In some embodiments, the card provider may send update information to the FRS via the FMS, wherein the card provider may send update information to the FMS, and the FMS may transmit the update information to the FRS.

[0090] S110, FRS sends update information to the card user.

[0091] S111, the card user displays the updated card according to the update information.

[0092] exist Figure 1A In the method shown, a unified rendering service, such as FRS, can construct a graphic node tree based on the layout code of the card, and when the information in the subsequent card is updated, FRS can trigger FMS to pull up the application process of the card provider, and the card provider calls the system API to obtain the update information of the card to realize the update of the information in the card.

[0093] In the scenario of creating multiple cards, for example, when creating a weather card, a clock card, and a calendar card on the desktop, the weather card, the clock card, and the calendar card can be used as card 1, card 2, and card 3 respectively. Figure 1B ,based on Figure 1AIn the method shown, FRS can construct a graphic node tree of each card based on the layout code of each card, and the card user can display each card based on the graphic node tree of each card. When the information of the multiple cards needs to be updated, FRS can trigger FMS to pull up the application process of each card provider respectively to obtain the update information, so that the card user can update the multiple cards based on the update information.

[0094] Figure 2A A flow chart showing the creation and display of an exemplary card. Figure 2A , the card creation and display process can include:

[0095] S201, the card user sends a card creation request to the FMS.

[0096] S202, FMS establishes a connection with the card provider.

[0097] S201-S202 may refer to the description in S101-S102.

[0098] S203, the card user constructs a graphic node tree according to the layout code of the card.

[0099] In some embodiments, the card user may request the card layout code from the card provider through the FMS, or the card user may search for the card layout code by himself at the location where the card provider's installation package is stored. This embodiment of the present application does not limit this.

[0100] S204: The card user displays the card according to the graphic node tree.

[0101] S204 may refer to the description in S106.

[0102] After displaying the card, because the information in the card changes in real time, the card user needs to update the card in real time. In some embodiments, the process of updating the card can refer to S205-S208:

[0103] S205: The card user sends a card information update request to the card provider.

[0104] In some embodiments, the card user may periodically send a card information update request to the card provider to request to update the information in the card, and reference may be made to the relevant description in S107.

[0105] In some embodiments, the card user may send a card information update request to the card provider through the FMS, wherein the card user may send the card information update request to the FMS, and the FMS may transmit the card information update request to the card provider.

[0106] S206: The card provider calls the system API to obtain update information.

[0107] S206 may refer to the description in S108.

[0108] S207: The card provider sends update information to the card user via the FMS.

[0109] S208: The card user displays the updated card according to the update information.

[0110] exist Figure 2A In the method shown, the card user can construct a graphic node tree based on the layout code of the card, and when the subsequent information is updated, the card user can trigger the FMS to pull up the application process of the card provider, and the card provider calls the system API to obtain the update information. The card provider can send the update information to the card user through the FMS, and the card user can update the information in the card based on the update information.

[0111] In the scenario of creating multiple cards, for example, when creating a weather card, a clock card, and a calendar card in a desktop application, the weather card, the clock card, and the calendar card can be used as card 1, card 2, and card 3, respectively. Figure 2B ,based on Figure 2A In the method shown, the card user can construct a graphic node tree for each card based on the layout code of each card, and the card user can display each card based on the graphic node tree of each card. When the information of the multiple cards needs to be updated, the card user can trigger FMS to pull up the application process of each card provider respectively, and the card provider calls the system API to obtain the updated information of the card, and the card user can update the multiple cards based on the updated information of the card.

[0112] exist Figure 1A and Figure 2A In the card creation and display method shown, each time the card information is updated, the FMS needs to launch the application process of the card provider, and the card provider obtains the updated information. Frequent launch of the application process easily leads to high power consumption and low efficiency. Figure 1A In the method shown, a unified FRS service constructs a graphic node tree for all cards, and the layout codes of different cards run in one FRS process, which makes it difficult to achieve permission isolation. Cards can only display and update information, and cannot provide more interactive capabilities. The card information is single.

[0113] Accordingly, the embodiments of the present application need to solve the following problems:

[0114] Question 1: Isolation of permissions for different cards.

[0115] Question 2: When updating the card information, FMS needs to start the application process of the card provider, which consumes a lot of power and has low efficiency.

[0116] For questions 1 and 2, in some embodiments, refer to Figure 3 , multiple card APIs can be pre-configured for FRS, and multiple virtual machines (VMs) can be created in FRS. Each virtual machine can correspond to a card API, and each card API can correspond to a card provider. On the one hand, in FRS, the layout code of the cards of the same card provider runs in the same virtual machine, and the layout code of the cards of different card providers runs in different virtual machines. In an embodiment of the present application, the resources and status of different card providers are isolated by the operating environment of the virtual machine. On the other hand, the card provider can call the card API provided by FRS, and trigger FRS to directly call the system API to obtain update information, so that the card can be updated. In this way, FRS directly calls the system API, which can avoid frequently pulling up the application process of the card provider when the card information is updated, and can reduce power consumption and improve card display efficiency.

[0117] Because different card providers may have different permissions, for example, card provider 1 has the permission to use the location system service and can obtain updated location information, and card provider 2 has the permission to use the weather system service and can obtain updated weather information. In some embodiments, when the card provider triggers FRS to directly call the system API, the corresponding system service can perform a permission check on the card provider, and only when the system service determines that the card provider has the corresponding permission will it feed back the updated information to FRS.

[0118] In some embodiments, the card provider's corresponding virtual machine may store the card provider's verification information, such as a token. When calling the system API, the FRS may provide the card provider's token to the corresponding system service, and the system service may verify the card provider's token. When the card provider's token is verified, the system service may feedback update information to the FRS.

[0119] In this embodiment, on the one hand, the card interface provided by FRS is separated from the system API. For the evolving operating system, API separation will lead to architectural corruption and increase the workload of API maintenance. On the other hand, the card provider's token is stored in the virtual machine corresponding to the card provider, and the security of the card provider's token depends on the security of the virtual machine. When the virtual machine is easily hacked, the security of the card provider's token is low.

[0120] In response to the current problems, an embodiment of the present application provides a card display method. On the one hand, a virtual machine is created in the FRS, and the resources and status of different card providers are isolated through the operating environment of the virtual machine. On the other hand, the token can be stored in the system module of the electronic device, such as the FMS, which can improve the security of the token. On the other hand, when the card information is updated, the embodiment of the present application can be used by the FRS to directly call the system API based on the token of the card provider to avoid frequently launching the application process of the card provider, which can reduce power consumption and improve card display efficiency.

[0121] Before introducing the card display method provided in the embodiment of the present application, the structure of the electronic device is first introduced:

[0122] Figure 4 This is a schematic diagram of the structure of another electronic device provided in an embodiment of the present application. Figure 4 , the electronic device may include: a card user, a card provider, an FMS, an FRS, and an authentication service (access token manager service, ATMS). It should be understood that the electronic device may include at least one card user and at least one card provider. Figure 4 In the figure, a card user and two card providers are taken as an example. The two card providers are, for example, card provider 1 and card provider 2 respectively.

[0123] Card consumers are used to trigger the creation of cards and display cards.

[0124] It should be understood that the card provider and the card user may be applications in the electronic device, and the card provider and the card user may be, for example, system applications or third-party applications. In the following embodiments, the card provider 1 is a cycling application, the card provider 2 is a navigation application, and the card user is a desktop application.

[0125] Different card providers have different permissions, which can be understood as different card providers having permissions to call different system APIs. Take the example of a cycling application having permission 1 and a navigation application having permission 2. Exemplarily, permission 1 may include location permissions, network permissions, and cross-device communication permissions. Accordingly, the cycling application can use location permissions to call the system API for providing location information to obtain the current location information of the electronic device. The cycling application can use network permissions to call the system API for providing weather information to obtain the current weather information. The cycling application can use cross-device communication permissions to call the system API for establishing communication with other electronic devices such as watches to obtain information such as the user's heart rate. Exemplarily, permission 2 may include location permissions. Accordingly, the navigation application can use location permissions to call the system API for providing location information to obtain the current location information of the electronic device.

[0126] In some embodiments, the permissions of different card providers may be pre-configured. For example, the installation package of the card provider may carry relevant information of the permissions of the card provider.

[0127] In some embodiments, when the electronic device installs a card provider, the card provider may send relevant information about the permissions that the card provider has to ATMS, so that ATMS can determine the permissions of each card provider in the electronic device. In some embodiments, when the card provider is a system application, the card provider may send relevant information about the permissions that the card provider has to ATMS when the electronic device is powered on or when the electronic device runs the card provider, so that ATMS can determine the permissions of the card provider.

[0128] In some examples, for the same card provider, the card provider may send relevant information about the permissions that the card provider has to ATMS once. For example, when the electronic device is powered on for the first time, or when the electronic device runs the card provider for the first time, the card provider may send relevant information about the permissions that the card provider has to ATMS once. When the electronic device is powered on subsequently, or when the electronic device runs the card provider again, the card provider may not send relevant information about the permissions that the card provider has to ATMS.

[0129] In some embodiments, when the card provider is updated, for example, when the version of the card provider is upgraded, the permissions of the card provider may change. Therefore, when the card provider is updated, the card provider may resend the relevant information of the updated permissions of the card provider to the ATMS so that the ATMS can determine the relevant information of the updated permissions of the card provider.

[0130] In some embodiments, the user can customize the permissions of the card provider. For example, the user can customize the permissions of the card provider in the settings application. For example, after the card provider is installed on the electronic device, when the card provider is run for the first time, the card provider can request to open permissions, and the user can customize to open certain permissions of the card provider. For example, the card provider can request to obtain the device information of the electronic device, request to access the contact information and gallery information of the electronic device, etc.

[0131] In this embodiment, after the user customizes and configures the authority of the card provider, the card provider may send relevant information of the authority of the card provider to the ATMS so that the ATMS can determine the authority of the card provider.

[0132] ATMS is a system service that is responsible for the card provider's authority verification. For example, ATMS can verify the authority of a service or application based on an externally transmitted token.

[0133] In some embodiments, ATMS can provide a registration interface and an authentication interface. The authentication interface is responsible for the authority verification of the card provider, and the registration interface is used for application or service registration verification information. The verification information can be, for example, a token, a verification password, etc. The following embodiments are described using a token as an example.

[0134] In some embodiments, when the card provider is successfully installed, or when the card provider is a system application, the card provider can call the registration interface of ATMS to register its own token when the electronic device is powered on for the first time, or when the electronic device runs the card provider for the first time. ATMS can store the card provider's token. Because the card provider can also send relevant information about the card provider's permissions to ATMS, ATMS can store the card provider's token and the card provider's permissions accordingly.

[0135] In some embodiments, the ATMS may include a mapping relationship between a card provider's token and the card provider's permissions. Exemplarily, the mapping relationship may include: at least one card provider's identification, token, and permissions.

[0136] In some embodiments, when the electronic device creates a card for the first time, that is, when the FMS pulls up the FRS for the first time, the FRS can also call the registration interface of the ATMS to register its own token. In some embodiments, the ATMS can store the token of the FRS.

[0137] The specific functions of FMS, FRS, and ATMS may refer to the relevant descriptions in the following embodiments.

[0138] The card display method provided by the embodiment of the present application is described below in conjunction with specific embodiments. The following embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0139] The following first introduces the process of creating a card:

[0140] Figure 5A A schematic diagram of a flow chart of an embodiment of a card display method provided in an embodiment of the present application. Figure 5A , the card display method provided in the embodiment of the present application may include:

[0141] S501: The card user sends a card creation request to the FMS.

[0142] Taking the creation of a cycling card on the desktop as an example, the desktop application can act as a card user and send a card creation request to the FMS. The card creation request can include the identification of the card provider, such as the identification of the cycling application.

[0143] In some embodiments, the card creation request may further include a card identifier. The identifier of the card provider is used to distinguish different card providers, and the identifier of the card is used to distinguish different cards. Exemplarily, taking a cycling application as an example, the cycling application, as a card provider, may correspond to multiple cards. For example, the multiple cards may include: card 1 for displaying the cycling position and card 2 for displaying information such as the user's heart rate.

[0144] In some embodiments, a card may correspond to a card provider. For example, a cycling card corresponds to a cycling application, and a weather card corresponds to a weather application.

[0145] S502: FMS establishes a connection with the card provider.

[0146] In some embodiments of the present application, the FMS may establish a connection with the card provider according to the identifier of the card provider in the card creation request. The process of establishing the connection may refer to the description in S102.

[0147] In some embodiments, when the card is created, the FMS can be disconnected from the card provider. When the card user triggers the creation of the card provider's card again, the FMS can be connected to the card provider again.

[0148] S503: The card provider sends verification information of the card provider to the FMS.

[0149] Exemplarily, the verification information provided by the card is, for example, a token.

[0150] In some embodiments, after the card provider registers the token through the registration interface of the ATMS, the token can be stored in the kernel of the electronic device. After the card provider establishes a connection with the FMS, the card provider can call the inter-process communication (IPC) interface to obtain the card provider's token from the kernel and send the card provider's token to the FMS.

[0151] S504, FMS determines whether the verification information of the card provider has been stored. If yes, execute S506, if not, execute S505 and then execute S506.

[0152] In some embodiments, the FMS may store the verification information of the card provider and the mapping relationship of the identifier of the virtual machine corresponding to the card provider, and the mapping relationship may be understood as the mapping relationship between the verification information and the identifier of the virtual machine. Exemplarily, the identifier of the virtual machine may be, for example, the serial number of the virtual machine, the thread identifier (TID) of the thread in the virtual machine, etc. In some embodiments, the mapping relationship between the verification information and the identifier of the virtual machine may be referred to as a first mapping relationship.

[0153] In some embodiments, for the card providers that have created the card, each card provider may correspond to a virtual machine, and each virtual machine has its own independent thread. The virtual machine may be created by FRS, and the creation process may refer to the relevant description in S507.

[0154] Taking the verification information of the card provider as a token and the identifier of the virtual machine as the TID of the thread in the virtual machine as an example, the FMS can store the token of the card provider and the mapping relationship between the TID of the thread in the virtual machine corresponding to the card provider. The mapping relationship can be understood as the mapping relationship between the token and the TID. Exemplarily, the mapping relationship between the token and the TID can be stored in the form of a table. For example, it is stored in the form of a key-value table, the key of the key-value table is TID, and the value is token. Among them, the process of FMS storing the mapping relationship between the token and the TID can refer to the relevant description in S508-S509.

[0155] In an embodiment of the present application, the FMS, in response to verification information from the card provider, can query the mapping relationship between the verification information and the identifier of the virtual machine to determine whether the verification information of the card provider is already included in the mapping relationship. If the verification information of the card provider is already included in the mapping relationship, the FMS can determine that the card provider is a card provider that has created a card, and the FRS contains the virtual machine corresponding to the card provider. If the verification information of the card provider is not included in the mapping relationship, the FMS can determine that the card provider is a card provider that has not created a card, or that the card provider is a card provider whose cards have all been deleted, and the FRS does not contain the virtual machine corresponding to the card provider.

[0156] S505, FMS stores the verification information of the card provider.

[0157] Because the mapping relationship between the verification information and the identifier of the virtual machine does not include the verification information of the card provider, the FMS may store the verification information of the card provider.

[0158] S506, the FMS sends a rendering instruction to the FRS.

[0159] The rendering instruction is used to instruct the FRS to construct a graphic node tree of the card. In some embodiments, the rendering instruction may include an identifier of the card provider and an identifier of the card.

[0160] S507: When the virtual machine corresponding to the card provider is not stored in the FRS, the FRS creates a virtual machine corresponding to the card provider.

[0161] When a card is created, the FRS may create a virtual machine corresponding to the card provider, and the FRS may store the virtual machine corresponding to the card provider of the created card. The FRS may respond to a rendering instruction from the FMS and query whether the virtual machine corresponding to the card provider has been stored in the FRS according to the identification of the card provider in the rendering instruction.

[0162] When the virtual machine corresponding to the card provider is not stored in the FRS, the FRS may create a virtual machine corresponding to the card provider.

[0163] In some embodiments, because one card provider corresponds to one virtual machine, when all cards of the card provider have been deleted, for example, when the user deletes all cards of the weather application, the FRS may delete the virtual machine corresponding to the card provider.

[0164] S508, the FRS sends the identifier of the virtual machine corresponding to the card provider to the FMS.

[0165] When the virtual machine corresponding to the card provider is not stored in the FRS, the FRS creates the virtual machine corresponding to the card provider and sends the identification of the virtual machine corresponding to the card provider to the FMS. In some embodiments, the TID of the thread in the virtual machine can be used as the identification of the virtual machine, and the FRS can send the TID of the thread in the virtual machine to the FMS.

[0166] S509, the FMS stores the verification information of the card provider and the identifier of the virtual machine corresponding to the card provider in correspondence.

[0167] In response to the identification of the virtual machine corresponding to the card provider from the FRS, the FMS can store the verification information of the card provider and the identification of the virtual machine corresponding to the card provider in correspondence. Exemplarily, the FMS can add the TID of the thread in the virtual machine corresponding to the card provider and the token of the card provider to the mapping relationship between the TID and the token.

[0168] After the FRS executes S508, it can execute S511. There is no order distinction between S511 and S509.

[0169] S510: When the virtual machine corresponding to the card provider has been stored in the FRS, S511 is directly executed.

[0170] In response to the rendering instruction from the FMS, the FRS may query whether the virtual machine corresponding to the card provider is stored in the FRS according to the identification of the card provider in the rendering instruction. When the virtual machine corresponding to the card provider is stored in the FRS, the FRS may directly execute S511.

[0171] S511, FRS constructs a graphic node tree according to the layout code of the card.

[0172] In the embodiment of the present application, because different cards correspond to different layout codes, the FRS can obtain the layout code of the card according to the card identifier, and the FRS can construct a graphical node tree according to the layout code of the card. The process of the FRS obtaining the layout code of the card can refer to the description in S104.

[0173] S512, FRS sends the graphic node tree to the card user.

[0174] S513: The card user displays the card according to the graphic node tree.

[0175] S511 - S512 may refer to the description in S104 - S106 .

[0176] Figure 5B A schematic diagram of a card creation process provided in an embodiment of the present application. Figure 5B , Figure 5BIn the example, the card user creates a card of card provider 1 and a card of card provider 2 respectively.

[0177] Taking the card of card provider 1 as card 1, when the card user creates card 1, the card user can send a card creation request to FMS. The card creation request can include the identification of card provider 1 and the identification of card 1. In response to the card creation request, FMS can establish a connection with card provider 1 based on the identification of card provider 1, and card provider 1 can send its own token to FMS.

[0178] In some examples, when Card Provider 1 has not created a card, FMS may store the token of Card Provider 1 and send a rendering instruction to FRS. The rendering instruction may include the identification of Card Provider 1 and the identification of Card 1. Based on the identification of Card Provider 1 in the rendering instruction, FRS may determine that the virtual machine corresponding to Card Provider 1 is not included in FRS, and FRS may create a virtual machine corresponding to Card Provider 1 and return the TID of the thread in the virtual machine corresponding to Card Provider 1 to FMS. Figure 5B VM1 represents the virtual machine corresponding to card provider 1.

[0179] In this way, FMS can store the TID of the thread in the virtual machine corresponding to card provider 1 and the token of card provider 1. Accordingly, FRS can construct a graphic node tree according to the layout code of card 1 and send the graphic node tree to the card user. The card user can display card 1 according to the graphic node tree.

[0180] Taking the card of card provider 2 as card 2 as an example, when the card user creates card 2, the card user can send a card creation request to FMS. The card creation request can include the identification of card provider 2 and the identification of card 2. In response to the card creation request, FMS can establish a connection with card provider 2 based on the identification of card provider 2, and card provider 2 can send its own token to FMS. Assume that card provider 2 has created a card, that is, FMS has stored the TID of the thread in the virtual machine corresponding to card provider 2 and the token of card provider 2. Figure 5B VM2 represents the virtual machine corresponding to card provider 2.

[0181] FMS can send a rendering instruction to FRS. The rendering instruction may include the identification of card provider 2 and the identification of card 2. Based on the identification of card provider 2 in the rendering instruction, FRS can determine that FRS contains the virtual machine corresponding to the card provider 2. Therefore, FRS can construct a graphic node tree according to the layout code of card 2 and send the graphic node tree to the card user. The card user can display card 2 according to the graphic node tree.

[0182] In the embodiment of the present application, FRS can create a corresponding virtual machine for each card provider, and isolate the resources of different card providers through the operating environment of the virtual machine, so as to achieve the isolation of card permissions. In addition, each card provider and FRS can call the registration interface of ATMS to register their own verification information, and FMS can also store the mapping relationship between the verification information of the card provider and the identifier of the virtual machine corresponding to the card provider. On the one hand, the verification information of the card provider is stored in FMS, which can improve the security of the verification information. On the other hand, the mapping relationship between the verification information of the card provider in FMS and the identifier of the virtual machine corresponding to the card provider can also assist in realizing FRS to directly call the system API.

[0183] In some embodiments, Figure 5A In the process of card creation shown, the card provider can send a card information acquisition request to the target system service to request the card information. In response to the card information acquisition request, the target system service can send the card information to the card provider. Exemplarily, the card provider can call the system API to send a card information acquisition request to the target system service.

[0184] After the card provider obtains the card information, it can send the card information to the FRS. For example, when the FRS requests the layout code of the card from the card provider, the card provider can send the card information and the layout code of the card to the FRS.

[0185] In some embodiments, S512 may be replaced by: FRS sends the graphic node tree and the card information to the card user. Correspondingly, S513 may be replaced by: the card user may display the card according to the graphic node tree and the card information.

[0186] In some embodiments, the card user can also update the information in the card. Fig. 6A Introducing the process of updating the information in the card by the card user. In some embodiments, refer to Fig. 6A , after S513, it may also include:

[0187] S601, FRS sends a card information update request to the target system service.

[0188] In the embodiment of the present application, when updating the information in the card, there is no need to pull up the application process of the card provider and call the system API, but the FRS directly calls the system API. When the FRS calls the system API, the card information update request first reaches the system service corresponding to the system API, which can be called the target system service. It can be understood that the FRS can send a card information update request to the target system service to request the update information of the card.

[0189] The target system service is used to provide card information. For example, taking a cycling application as an example, the cycling card may include location information, and the target system service may be a system service for providing location information, such as a global positioning system (GPS) system service. Among them, the FRS may send a card information update request to the GPS system service to request to call the system API of the GPS system service to obtain updated location information.

[0190] The card information update request may include the verification information of the FRS and the identifier of the virtual machine corresponding to the card provider.

[0191] S602: The target system service sends a verification request to the ATMS in response to the card information update request.

[0192] The verification request may include verification information of the FRS and an identifier of a virtual machine corresponding to the card provider.

[0193] In some embodiments, when FRS calls the system API, FRS can act as the caller, and the target system service can call the authentication interface of ATMS in response to the card information update request, and at the same time pass the verification information of the caller FRS and the identifier of the virtual machine corresponding to the card provider to ATMS, so that ATMS can verify the authority of the card provider.

[0194] S603, ATMS cooperates with FMS to verify the authority of the card provider based on the verification information of FRS and the identifier of the virtual machine corresponding to the card provider.

[0195] Because FRS has previously called the registration interface of ATMS to register the verification information of FRS, in the embodiment of the present application, ATMS will not use the verification information of FRS to verify the authority of the card provider, but will send the ID of the virtual machine corresponding to the card provider to FMS. Because the mapping relationship between the verification information of the card provider and the ID of the virtual machine corresponding to the card provider is stored in FMS, FMS can query the verification information of the card provider mapped to the ID of the virtual machine corresponding to the card provider based on the mapping relationship. FMS can send the verification information of the card provider to ATMS.

[0196] For example, ATMS can call the callback interface of FMS and take the ID of the virtual machine corresponding to the card provider as an input parameter. After receiving the callback from ATMS, FMS queries the verification information of the card provider in the mapping relationship between the verification information and the virtual machine ID through the ID of the virtual machine corresponding to the card provider, and returns the verification information of the card provider obtained by the query to ATMS.

[0197] Because the mapping relationship between the verification information of the card provider and the authority of the card provider is stored in ATMS, ATMS can verify the authority of the card provider based on the verification information of the card provider returned by FMS and the mapping relationship, that is, ATMS verifies whether the card provider has the authority to call the system API. In some embodiments, the mapping relationship between the verification information of the card provider and the authority of the card provider can be called a second mapping relationship.

[0198] S604, in response to the card provider's authority verification being passed, ATMS sends a verification success message to the target system service.

[0199] When ATMS verifies the authority of the card provider and determines that the card provider has the authority to call the system API, it determines that the authority verification of the card provider has passed, and ATMS can send a verification success message to the target system service. In some embodiments, the card provider has the authority to call the system API, which can also be understood as the card provider has the authority to call or use the target system service.

[0200] S605: The target system service returns the card update information to the FRS.

[0201] In response to the verification success message, the target system service can determine that the card provider has the authority to call the system API, so the target system service can return the card update information to the FRS, that is, the FRS successfully calls the system API to obtain the card update information.

[0202] S606, FRS sends the card update information to the card user.

[0203] S607: The card user displays the updated card according to the updated information of the card.

[0204] S608: When the card provider's authority verification fails, ATMS sends a verification failure message to the target system service.

[0205] S609: The target system service returns a call failure message to the FRS.

[0206] The call failure message is used to indicate that the card provider does not have the authority to call the system API.

[0207] For example, refer to Figure 6B , taking the VM1 corresponding to card provider 1 and the VM2 corresponding to card provider 2 in FRS as an example, the following takes card provider 1 as an example to illustrate the process of FRS directly calling the system API:

[0208] FRS can call the system API, and the card information update request from FRS first reaches the system service. The card information update request can include the FRS token and the TID of the thread in VM1. In response to the card information update request, the system service can call the authentication interface of ATMS, and pass the token of the caller FRS and the TID of the thread in VM1 to ATMS, that is, the system service sends a verification request to ATMS. ATMS calls the callback interface of FMS and takes the TID of the thread in VM1 as an input parameter. After receiving the callback from ATMS, FMS uses the TID of the thread in VM1 to query the token mapped to the TID of the thread in VM1 in the mapping relationship between token and TID, and returns the queried token to ATMS.

[0209] ATMS stores the mapping relationship between token and authority. In response to the token from FMS, ATMS can determine the authority mapped by the token based on the mapping relationship to determine whether the card provider 1 has the authority to call the system API. When the card provider 1 has the authority to call the system API, ATMS can send a verification success message to the system service, and the system service can feedback the card update information to FRS.

[0210] In some embodiments, both the verification success message and the verification failure message can be referred to as verification results.

[0211] In the embodiment of the present application, the mapping relationship between the verification information of the card provider and the identifier of the virtual machine corresponding to the card provider is stored in the FMS, which can improve the security of the verification information on the one hand, and on the other hand, the FMS can provide the verification information of the card provider to the ATMS during the card verification, so as to facilitate the smooth implementation of the authority verification. In the embodiment of the present application, the ATMS can verify the authority of the card provider based on the verification information of the card provider, and when the authority verification passes, the FRS is allowed to directly call the system API, which not only realizes the authority verification of the card provider and reduces power consumption, but also achieves the purpose of isolating the authority of the card provider.

[0212] For example, refer to Figure 7For example, card provider 1 has permission 1, and card provider 2 has permission 2. When updating the information in card 1, FRS calls the system API that requires permission 1. The system service can recognize that card 1 belongs to card provider 1, and the authentication is successful. When updating the information in card 2, if FRS calls the system API that requires permission 1, the system service can reject the call because card provider 2, to which card 2 belongs, does not have permission 1. In the embodiment of the present application, it can be ensured that the permissions between different card providers are minimized, especially for certain sensitive permissions, such as geographic location permissions, contact data reading permissions, camera permissions, etc., it can be ensured that the permissions are only effective for specific card providers, thereby improving system security.

[0213] In some embodiments, reference Figure 5A In the card creation process shown in FIG. 5 , in S512, FRS can not only construct a graphical node tree according to the layout code of the card, but also send a card information acquisition request to the target system service. The card information acquisition request is used to request the card information, wherein the target system service can verify the authority of the card provider in response to the card information acquisition request, and in response to the card provider's authority verification being passed, the target system service can send the card information to FRS. The process of the target system service verifying the authority of the card provider can refer to Fig. 6A Related description in .

[0214] Exemplarily, FRS can not only construct a graphic node tree according to the layout code of the card, but also call the system API to obtain the card information from the target system service so that the card user can display the information in the card when displaying the card.

[0215] In some embodiments, S601-S607 may be further executed after S512, and accordingly, S513 may be replaced by: the card user may display the card according to the graphic node tree and the card information.

[0216] In an embodiment of the present application, when creating a card, the FRS can also directly call the system API based on the token of the card provider to obtain the card information. Compared with the method in which the card provider calls the system API to obtain the card information and then sends it to the FRS, it can reduce signaling overhead and improve card display efficiency.

[0217] The following describes the card display method provided by the embodiment of the present application in combination with specific application scenarios:

[0218] Taking the mobile phone as an electronic device and the cycling application as an example, many users are accustomed to fixing their mobile phones on the bicycle frame when riding outdoors to view cycling information in real time. The cycling information may include cycling mileage, cycling speed, user heart rate, etc. At present, users can only see this information by opening the cycling application. If the user needs navigation at the same time, since the navigation application and the cycling application cannot be displayed in the foreground at the same time, the user can only switch the navigation application to the background to receive navigation information in the form of voice, which is not as intuitive as displaying the navigation information in the foreground. The card display method provided in the embodiment of the present application can create cycling cards and navigation cards on the desktop, so that users can see cycling information and navigation information on one interface.

[0219] Figure 8 A multi-card combination solution is presented, and different card providers have different permissions. In the embodiment of the present application, based on the verification information of different card providers and their corresponding virtual machines, the permissions of the card providers can be isolated. In this way, the card can safely carry more sensitive permission services, enrich the card information, and the user does not need to open the application, but only needs to use the card to obtain the desired information.

[0220] For example, if a cycling application has geographic location permissions, network permissions, and cross-device communication permissions, then through the card creation and display method provided in the embodiment of the present application, the user can create a cycling card on the desktop of the electronic device, and the cycling card can inherit the permissions of the cycling application. For example, the FRS in the electronic device can directly call the system API corresponding to the geographic location permission to obtain the current location information, travel data, etc. The FRS can directly call the system API corresponding to the network permission to obtain weather information, etc. The FRS can directly call the system API corresponding to the cross-device communication permission to obtain the user's heart rate and other information. Refer to Figure 8 , the card user can display a cycling card, which may include location information, trip data, weather information, and the user's heart rate and other information.

[0221] Similarly, the user can create a navigation card on the desktop of the electronic device, and the navigation card can inherit the permissions of the navigation application. For example, the FRS in the electronic device can directly call the system API corresponding to the navigation permission to obtain the current location information, navigation information, etc. Figure 8 , the card user can display a navigation card, which may include current location information and navigation information.

[0222] In an embodiment of the present application, a user can create multiple cards on an interface of an electronic device, so that the user can obtain rich information based on the multiple cards without opening specific applications, thereby improving the user experience.

[0223] Similarly, users can also add other cards according to their own preferences. Figure 8 For example, a radio station card can be used to listen to the radio station in real time, and a logistics card can be used to pay attention to the express delivery that is about to arrive. In the embodiment of the present application, on the one hand, all cards are run in the FRS process, and there is no need to start multiple application processes. Resource isolation can be achieved based on the virtual machine, and the card information can be enriched while reducing power consumption. On the other hand, when the card information is updated, FRS can directly call the system API without frequently pulling up the application process of the card provider, which reduces power consumption, and can increase the speed at which FRS obtains card information and improve card display efficiency.

[0224] Fig. 9 A flowchart of another card display method provided in an embodiment of the present application. Fig. 9 A method for updating a card by a card user is introduced in . The first application can be understood as the card user, and the second application can be understood as the card provider. Fig. 9 In some embodiments, the card display method provided by the embodiments of the present application may include:

[0225] S901, the first application displays a card of the second application.

[0226] The process of the first application displaying the card of the second application may refer to the relevant description in the above embodiment.

[0227] The card displayed by the first application corresponds to the second application. For example, the card displayed by the first application is a cycling card, and the cycling card corresponds to the second application "cycling application". For example, the card displayed by the first application is a weather card, and the weather card corresponds to the second application "weather application".

[0228] S902: The card rendering service sends a card information update request to the target system service. The card information update request is used to request updated card information.

[0229] In an embodiment of the present application, the card rendering service FRS can directly call the system API without frequently starting the application process of the second application. Calling the system API by the second application can reduce power consumption and increase the speed at which FRS obtains update information of the card, thereby improving card display efficiency.

[0230] In some embodiments, the card rendering service may call the system API periodically or at intervals to send a card information update request to the target system service.

[0231] S903, the target system service verifies the permission of the second application.

[0232] In some embodiments, the target system service may store a mapping relationship between the identifier of the second application and the permissions of the second application. In response to the card information update request, the target system service may determine the permissions of the second application based on the mapping relationship to verify the permissions of the second application and determine whether the second application has the permission to call the system API.

[0233] In some embodiments, in order to improve the verification security of the second application, the electronic device may set an authentication service, and the authentication service is used to perform permission verification on the second application. Among them, the card rendering service includes a virtual machine corresponding to the second application, and the virtual machine corresponding to the second application is created by the card rendering service for the second application. Exemplarily, the card rendering service may include at least one virtual machine corresponding to the second application, and each second application corresponds to a virtual machine.

[0234] The card information update request includes verification information of the card rendering service and the identifier of the virtual machine. In this embodiment, the target system service may send a verification request to the authentication service in response to the card information update request, and the verification request includes verification information of the card rendering service and the identifier of the virtual machine. In some embodiments, the target system service calls the authentication interface of the authentication service and sends the verification request to the authentication service.

[0235] The authentication service, in response to the verification request, may obtain the verification information of the second application according to the verification information of the card rendering service and the identifier of the virtual machine.

[0236] In some embodiments, the authentication service may store a mapping relationship between the verification information of the second application and the identifier of the virtual machine corresponding to the second application, so that the authentication service can obtain the verification information of the second application according to the mapping relationship.

[0237] In some embodiments, in order to improve the authentication security of the second application, the electronic device may set up a card management service, and the card management service includes: a first mapping relationship between the verification information of the second application and the identifier of the virtual machine corresponding to the second application. The authentication service calls the callback interface of the card management service based on the verification information of the card rendering service, and uses the identifier of the virtual machine as an input parameter. In response to the callback of the authentication service, the card management service may return the verification information of the second application corresponding to the identifier of the virtual machine to the authentication service based on the first mapping relationship. The specific process can be referred to. Fig. 6A Description in .

[0238] In an embodiment of the present application, after obtaining the verification information of the second application, the authentication service can verify the permissions of the second application based on the verification information of the second application. In some embodiments, the authentication service may include: a second mapping relationship between the verification information of the second application and the permissions of the second application. The authentication service can determine whether the second application has the permission to call the system API based on the verification information of the second application and the second mapping relationship.

[0239] S904: In response to the second application passing the permission check, the target system service sends the card update information to the card rendering service.

[0240] In some embodiments, when the second application has the permission to call the system API, the authentication service determines that the permission check of the second application has passed, and the authentication service can send a verification success message to the target system service. In response to the verification success message from the authentication service, the target system service can determine that the permission check of the second application has passed, and the target system service sends the card update information to the card rendering service.

[0241] In some embodiments, when the second application does not have permission to call the system API, it is determined that the permission check of the second application has not passed, and the authentication service sends a verification failure message to the target system service. In response to the verification failure message from the authentication service, the target system service can determine that the permission check of the second application has not passed, and the target system service can send a call failure message to the card rendering service.

[0242] S905: The card rendering service sends the card update information to the first application.

[0243] S906: The first application displays the updated card according to the update information of the card.

[0244] In the embodiment of the present application, the first application responds to the update information of the card and can display the updated card according to the update information of the card.

[0245] It can be understood that the embodiments of the present application have the same technical effects as the above embodiments, and reference can be made to the relevant descriptions in the above embodiments.

[0246] It should be noted that the data involved in this application (including but not limited to data used for analysis, stored data, displayed data, etc.) are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0247] In one embodiment, the present application also provides an electronic device, referring to Fig.10, the electronic device may include: a processor 1001 (such as a CPU), and a memory 1002. The memory 1002 may include a high-speed random access memory (RAM), and may also include a non-volatile memory (NVM), such as at least one disk memory. The memory 1002 may store various instructions for completing various processing functions and implementing the method steps of the present application.

[0248] Optionally, the electronic device involved in the present application may further include: a power supply 1003, a communication bus 1004 and a communication port 1005. The above-mentioned communication port 1005 is used to realize the connection and communication between the electronic device and other peripherals. In the embodiment of the present application, the memory 1002 is used to store computer executable program code, and the program code includes instructions; when the processor 1001 executes the instruction, the instruction causes the processor 1001 of the electronic device to perform the action in the above-mentioned method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0249] Optionally, the electronic device involved in the present application may further include: a display screen 1006. The display screen 1006 is used to display an interface of the electronic device.

[0250] It should be noted that the modules or components described in the above embodiments may be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, when a module above is implemented in the form of a processing element scheduling program code, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processors that can call program codes, such as a controller. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0251] 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 loading and executing computer program instructions on a computer, the process or function according to 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 devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, a data center, etc. that contains one or more available media integrated. The available medium can be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0252] The term "plurality" in this article refers to two or more than two. The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the previous and next associated objects are in an "or" relationship; in the formula, the character " / " indicates that the previous and next associated objects are in a "division" relationship. In addition, it should be understood that in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

[0253] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0254] It can be understood that in the embodiments of the present application, the size of the serial 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 the present application.

Claims

1. A card display method, characterized in that: Applied to an electronic device, the electronic device includes a first application, a second application, a card rendering service, and a target system service, the method includes: The first application displays a card of the second application; The card rendering service sends a card information update request to the target system service, where the card information update request is used to request update information of the card; The target system service verifies the permission of the second application; In response to the permission check of the second application being passed, the target system service sending update information of the card to the card rendering service; The card rendering service sends update information of the card to the first application; The first application displays the updated card according to the update information of the card.

2. The method according to claim 1, characterized in that The card rendering service includes a virtual machine corresponding to the second application, and the card information update request includes verification information of the card rendering service and an identifier of the virtual machine; the electronic device also includes an authentication service; The target system service verifies the permission of the second application, including: The target system service sends a verification request to the authentication service, where the verification request includes verification information of the card rendering service and an identifier of the virtual machine; The authentication service obtains verification information of the second application according to the verification information of the card rendering service and the identifier of the virtual machine; The authentication service verifies the permission of the second application according to the verification information of the second application.

3. The method according to claim 2, characterized in that The electronic device further includes a card management service, the card management service including: a first mapping relationship between the verification information of the second application and the identifier of the virtual machine; The target system service sends a verification request to the authentication service, including: The target system service calls the authentication interface of the authentication service and sends the verification request to the authentication service; The authentication service obtains verification information of the second application according to the verification information of the card rendering service and the identifier of the virtual machine, including: The authentication service sends the identifier of the virtual machine to the card management service according to the verification information of the card rendering service; The card management service sends verification information of the second application to the authentication service according to the identifier of the virtual machine and the first mapping relationship.

4. The method according to claim 2 or 3, characterized in that: The authentication service includes: a second mapping relationship between the verification information of the second application and the permission of the second application; The authentication service verifies the permission of the second application according to the verification information of the second application, including: The authentication service determines whether the second application has the authority to call the target system service according to the verification information of the second application and the second mapping relationship.

5. The method according to claim 4, characterized in that After determining whether the second application has the permission to call the target system service, the method further includes: When the second application has the permission to call the target system service, the authentication service determines that the permission verification of the second application has passed, and sends a verification success message to the target system service; or, When the second application does not have the permission to call the target system service, the authentication service determines that the permission check of the second application has failed, and sends a check failure message to the target system service; The target system service sends a call failure message to the card rendering service.

6. The method according to any one of claims 3 to 5, characterized in that: Before the first application displays the card of the second application, the method further includes: The first application sends a card creation request to the card management service, where the card creation request includes an identifier of the second application and an identifier of the card; The card management service establishes a connection with the second application according to the identifier of the second application; The second application sends verification information of the second application to the card management service; When the verification information of the second application is stored in the card management service, the card management service sends a rendering instruction to the card rendering service, where the rendering instruction is used to instruct the card rendering service to obtain a graphic node tree of the card; or, When the verification information of the second application is not stored in the card management service, the card management service stores the verification information of the second application and sends the rendering instruction to the card rendering service.

7. The method according to claim 6, characterized in that The rendering instruction includes the identifier of the second application and the identifier of the card. After sending the rendering instruction to the card rendering service, the method further includes: When the card rendering service determines, according to the identifier of the second application, that the card rendering service includes the virtual machine, the card rendering service obtains a layout code of the card according to the identifier of the card; The card rendering service obtains the graphic node tree according to the layout code of the card.

8. The method according to claim 7, characterized in that The method further comprises: When the card rendering service determines, according to the identifier of the second application, that the virtual machine is not included in the card rendering service, the card rendering service creates the virtual machine; The card rendering service obtains the layout code of the card according to the identifier of the card; The card rendering service obtains the graphic node tree according to the layout code of the card; The card rendering service sends the identifier of the virtual machine to the card management service; The card management service stores a first mapping relationship between the verification information of the second application and the identifier of the virtual machine.

9. The method according to claim 7 or 8, characterized in that: The method further comprises: The second application sends a card information acquisition request to the target system service, where the card information acquisition request is used to request the card information; The target system service sends the card information to the second application; The second application sends the card information to the card rendering service.

10. The method according to claim 7 or 8, characterized in that: The method further comprises: The card rendering service sends a card information acquisition request to the target system service, wherein the card information acquisition request is used to request the card information; The target system service verifies the permission of the second application; In response to the permission check of the second application being passed, the target system service sends the card information to the card rendering service.

11. The method according to claim 9 or 10, characterized in that: After the card rendering service obtains the card information, it further includes: The card rendering service sends the graphic node tree and the card information to the first application; The first application displays the card of the second application, including: The first application displays the card according to the graphic node tree and the information of the card.

12. The method according to any one of claims 3 to 11, characterized in that: The method further comprises: The second application calls the registration interface of the authentication service to register the verification information of the second application; The card rendering service calls the registration interface to register the verification information of the card rendering service.

13. The method according to any one of claims 3 to 12, characterized in that: The verification information of the second application is a token, the verification information of the card rendering service is a token, and the identifier of the virtual machine corresponding to the second application is the thread number of the thread in the virtual machine corresponding to the second application.

14. An electronic device, characterized in that: include: Processor and memory; The memory stores computer instructions; The processor executes the computer instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 13.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program or instruction, and when the computer program or instruction is executed, the method according to any one of claims 1 to 13 is implemented.

Images