Card display method, electronic device and readable storage medium

Abstract

This application provides a card display method, an electronic device, and a readable storage medium. In this method, a first application displays a card from a second application. A card rendering service sends a card information update request to a target system service, the card information update request being used to request updated card information. The target system service verifies the permissions of the second application. In response to the successful permission verification of the second application, the target system service sends the updated card information to the card rendering service, which in turn sends the updated card information to the first application. The first application displays the updated card based on the updated card information. In this application, when card information is updated, the card rendering service can directly request the updated card information from the target system service, without needing to launch the application process of the second application. The second application requests the updated card information from the target system service, which reduces power consumption and improves card display efficiency.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a card display method, an electronic device, and a readable storage medium. Background Technology

[0002] Cards are a way for electronic devices to display information. Currently, cards can be created on the desktop and application interfaces of electronic devices, and these 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, etc.

[0003] Currently, after a card is created, when the information on the card needs to be updated, the corresponding application process can be launched. This application process can then call the system service's interface to obtain the card's update information, allowing the card to display the updated information promptly. However, each update to the card's information currently requires launching the corresponding application process, resulting in high power consumption and low efficiency. Summary of the Invention

[0004] This application provides a card display method, an electronic device, and a readable storage medium. The card rendering service directly requests card update information from the target system service without launching the application process of a second application, which can reduce power consumption and improve card display efficiency.

[0005] Firstly, embodiments of this application provide a card display method. The executing entity of this card display method can be an electronic device or a chip within an electronic device. The following description uses an 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. 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. The card information update request is used to request updated information for the card. In some examples, for instance, the card rendering service may periodically or intermittently send card information update requests to the target system service.

[0006] In response to a card information update request, the target system service can verify the permissions of the second application. If the permission verification of the second application passes, the target system service sends the updated card information to the card rendering service. The card rendering service then sends the updated card information to the first application, which displays the updated card based on the updated information.

[0007] In this embodiment, when the electronic device updates the card, it is not necessary to launch the application process of the second application and have the second application request the card update information from the target system service. Instead, the card rendering service directly requests the card update information from the target system service, 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, which can be created by the card rendering service. In some examples, the card rendering service can create the virtual machine corresponding to the second application when the electronic device first displays the card of the second application; hereinafter, the virtual machine corresponding to the second application will be simply referred to as the virtual machine.

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

[0010] In this embodiment of the application, the target system service's verification of the second application's permissions may specifically include: in response to a card information update request, the target system service may send a verification request to the authentication service, the verification request including the verification information of the card rendering service and the identifier of the virtual machine. Specifically, in response to the verification request, 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, 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 permissions of the second application, which can improve the security of the verification.

[0012] In one 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. In response to a card information update request, the target system service may invoke the authentication interface of the authentication service to send the verification request to the authentication service. In this embodiment, 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, in response to the verification request, may send the identifier of the virtual machine to the card management service based on the verification information of the card rendering service to request the verification information of the second application. Specifically, in response to the identifier of the virtual machine from the authentication service, the card management service may send the verification information of the second application to 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 this embodiment, the first mapping relationship is stored in the card management service. On the one hand, this can improve the security of the verification information. On the other hand, the first mapping relationship between the verification information of the second application and the identifier of the virtual machine stored in the card management service 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 card update information from the target system service.

[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 system services. In some examples, the permissions of the second application in the second mapping relationship may include the identifier of at least one system service that the second application can call.

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

[0017] In this embodiment, the authentication service can work with the card management service to verify the verification information of the second application, thereby improving verification security.

[0018] In one possible implementation, after the authentication service determines whether the second application has 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 verification 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 card update information to the card rendering service, thereby updating the card.

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

[0020] In this embodiment, by verifying 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 card update information to the card rendering service, thereby updating the card. When the second application does not have the permission to call the target system service, the target system service may not send the card update information to the card rendering service. In this embodiment, it can be ensured that the usage 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 from the second application:

[0022] In one possible implementation, the authentication service may include a registration interface. The second application can call the registration interface of the authentication service to register its verification information. The card rendering service can call the registration interface to register its verification information. In one 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] For example, when a user triggers the first application to display a card of the second application, the first application can send a card creation request to the card management service. The card creation request includes the identifier of the second application and the 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 can then send its verification information to the card management service.

[0024] The card management service can detect whether the verification information of the second application has been stored in the card management service. If the card management service has stored the verification information of the second application, it indicates that the electronic device has already created a card for the second application. The card management service can then send a rendering instruction to the card rendering service, which instructs the card rendering service to obtain the graphical node tree of the card. Alternatively, if the card management service does not store the verification information of the second application, it indicates that the electronic device has not created a card for the second application, or that all cards for the second application have been deleted. The card management service stores the verification information of the second application and sends the rendering instruction to the card rendering service.

[0025] In one 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 can determine whether it includes a virtual machine corresponding to the second application, based on the identifier of the second application.

[0026] When the card rendering service determines that it includes the virtual machine, it can obtain the layout code of the card based on the card's identifier, and then obtain the graphics node tree based on the layout code. Conversely, when the card rendering service determines that it does not include the virtual machine based on the identifier of the second application, it can create the virtual machine and send its identifier to the card management service, allowing the card management service to store the first mapping relationship between the verification information of the second application and the identifier of the virtual machine.

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

[0028] In this embodiment of the application, the graphic node tree can represent the layout of the card. 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 one possible implementation, embodiments of this application can obtain information about the card of the second application in the following two ways:

[0030] First, the second application obtains card information from the second application. Specifically, the second application may send a card information retrieval request to the target system service, requesting the card information. In response to the card information retrieval request, the target system service may send the card information to the second application. The second application then sends the card information to the card rendering service.

[0031] Secondly, the card rendering service obtains the card information of the second application. Specifically, the card rendering service may send a card information retrieval request to the target system service, the request being used to request the card information. The target system service verifies the permissions of the second application; upon successful permission verification, the target system service sends the card information to the card rendering service. The process of the target system service verifying the permissions of the second application can be referred to the relevant description in the above embodiments.

[0032] In this embodiment of the application, when creating a card, the card rendering service can also directly request the card information from the target system service. Compared with the method of the second application requesting the card information from the target system service and then sending it to the card rendering service, this can reduce signaling overhead and improve card display efficiency.

[0033] In one possible implementation, after the card rendering service obtains the card information and the graphics node tree, it can send the graphics node tree and the card information to the first application. The first application then displays the card based on the graphics node tree and the card information.

[0034] Secondly, embodiments of this application provide an electronic device that may include a processor and a memory. The memory stores computer-executable program code, which includes instructions; when the processor executes the instructions, the instructions cause the electronic device to perform the method described in the first aspect.

[0035] Thirdly, embodiments of this application provide an electronic device that may include units, modules, or circuits for performing the methods provided in the first aspect above.

[0036] Fourthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in the first aspect above.

[0037] Fifthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect.

[0038] The beneficial effects of the various possible implementations of the second to fifth aspects mentioned above can be found in the beneficial effects of the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0040] Figure 1B A flowchart illustrating the creation of an exemplary multi-card system;

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

[0042] Figure 2B A flowchart illustrating the creation of an exemplary multi-card system;

[0043] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the structure of another electronic device provided in an embodiment of this application;

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

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

[0047] Figure 6A A flowchart illustrating another card display method provided in an embodiment of this application;

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

[0049] Figure 7 This is a schematic diagram illustrating different card providers having different permissions, provided as an embodiment of this application.

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

[0051] Figure 9 A flowchart illustrating an embodiment of another card display method provided in this application;

[0052] Figure 10 This is a schematic diagram of the structure of another electronic device provided in an embodiment of this application. Detailed Implementation

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

[0054] Cards / card components: These are development components in the application framework domain that can be embedded within an application to display relevant information. For example, a widget is a type of 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: The application that provides the card display content. The card provider controls the displayed card content, control layout, and control click events. For example, a weather application is a weather card provider.

[0056] Card User: The host application that displays the card's content. The card user controls where the card is displayed within the host application. For example, if a user adds a weather card to their home screen, then the home screen application is the card user for the weather card.

[0057] In some embodiments, the card user can 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 can be a third-party application.

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

[0060] Form Manager Service (FMS) is a system service responsible for managing the lifecycle of cards and maintaining card data. Operations such as adding, refreshing, and deleting cards are all managed by FMS. FMS also supports communication between card providers and card users.

[0061] Form Render Service (FRS): This is a system service that, when a card is created, Form Scripting Service (FMS) can start the FRS process to run the card layout code. FRS can parse the card layout code and construct the graphical node tree required for card rendering. FRS can then send the graphical node tree to the card user, who can then display the card based on the tree.

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

[0063] The electronic devices in this application embodiment can be referred to as user equipment (UE), terminal, etc. For example, electronic devices can be mobile phones, tablets, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices, in-vehicle devices or wearable devices, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in smart homes, etc. The form of the electronic devices is not specifically limited in this application embodiment.

[0064] The following example, "Creating a weather card on the desktop," illustrates the current process of creating and displaying weather cards:

[0065] Figure 1A A schematic diagram illustrating the process of creating and displaying an exemplary card. (Refer to...) Figure 1A Currently, the card creation and display process can include:

[0066] S101, the card uses the direction of the FMS to send a card creation request.

[0067] For example, when a user triggers the creation of a weather card on the desktop, the desktop application can act as the card user and send a card creation request to the FMS. This card creation request may include the identifier of the card provider, such as the identifier of the weather application. The identifier of the weather application may be, for example, the name or number of the weather application; this will not be elaborated upon in this embodiment.

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

[0069] In some embodiments, the card provider may run an application process responsible for handling card-related business. Correspondingly, in response to a card creation request from a card user, the FMS can establish a connection with the card provider's application process based on the card provider's identifier. Once the FMS and the card provider's application process are connected, inter-process communication can be achieved between the card user's application process and the card provider's application process through the FMS.

[0070] S103, FMS pulls up FRS.

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

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

[0073] There is no distinction in the order of S102 and S103.

[0074] S104, FRS constructs a graphical node tree based on the card's layout code.

[0075] The embodiments of this application do not elaborate on the process of constructing a graphical node tree based on the card-based layout code of FRS, but can refer to the relevant descriptions in the prior art.

[0076] In some embodiments, the card layout code can be deployed in the card provider's installation package. After the FRS is launched, the FRS can request the card layout code from the card provider, or the FRS can find the card layout code itself at the location where the card provider's installation package is stored; this application embodiment does not limit this.

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

[0078] For example, FRS can construct a graphical node tree of the weather card based on the layout code of the weather card, and then send the graphical node tree of the weather card to the desktop application.

[0079] S106, the card user displays the card according to the graphical node tree.

[0080] For example, the graphical node tree of the card can be a graphical resource; such as the resources of the various components of the card. A desktop application can display a weather card based on the graphical node tree of the weather card. For example, a weather card may include: the current temperature, today's lowest and highest temperatures, and images representing the weather (such as sunny, cloudy, heavy rain, light rain, etc.).

[0081] After the weather card is displayed to the card user, the weather information changes in real time, so 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, FRS may periodically send card information update requests to the card provider to request updates to the information on the card.

[0084] In some embodiments, the frequency at which the FRS sends card information update requests may differ 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 application embodiment does not impose any limitations on this.

[0085] In some embodiments, the FRS can send a card information update request to the card provider via the FMS. Specifically, the FRS can send the card information update request to the FMS, and the FMS can then forward the card information update request to the card provider.

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

[0087] In some embodiments, the FMS can launch the card provider's application process, which then calls a system API to obtain updated card information. For example, in response to a card information update request from the FRS, the FMS can launch a weather application process, which can then call a system API for providing weather information to obtain updated weather data.

[0088] S109, the card provides direction for sending update information to the FRS.

[0089] In some embodiments, the card provider can send update information to the FRS via the FMS. The card provider can send update information to the FMS, and the FMS can then 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 based on the updated information.

[0092] exist Figure 1A In the method shown, a unified rendering service, such as FRS, can construct a graphical node tree based on the card's layout code. When the information in the card is updated later, FRS can trigger FMS to launch the application process of the card provider, and the card provider can call the system API to obtain the updated information of the card, so as to realize the update of the information in the card.

[0093] In scenarios involving multiple cards, such as creating weather, clock, and calendar cards on the desktop, you can designate the weather card, clock card, and calendar card as Card 1, Card 2, and Card 3, respectively. (See reference...) Figure 1B ,based on Figure 1AThe method shown allows FRS to construct a graphical node tree for each card based on its layout code, and the card user can display each card according to this graphical node tree. When the information of these multiple cards needs to be updated, FRS can trigger FMS to launch the application process of each card provider to obtain the update information, so that the card user can update these multiple cards based on this update information.

[0094] Figure 2A A schematic diagram illustrating the process of creating and displaying an exemplary card. (Refer to...) Figure 2A The card creation and display process may include:

[0095] S201, the card uses the direction of the FMS to send a card creation request.

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

[0097] S201-S202 can be referred to in the descriptions in S101-S102.

[0098] S203, the card user constructs a graphical node tree based on the card's layout code.

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

[0100] S204, The card user displays the card according to the graphical node tree.

[0101] S204 can be referred to the description in S106.

[0102] After the card is displayed, the information on the card changes in real time, so 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 an update to the information in the card, as described in S107.

[0105] In some embodiments, the card user can send a card information update request to the card provider through the FMS. Specifically, the card user can send a card information update request to the FMS, and the FMS can then forward the card information update request to the card provider.

[0106] S206, The card provider calls the system API to obtain updated information.

[0107] S206 can be referred to the description in S108.

[0108] S207, the card provider sends update information to the card user through FMS.

[0109] S208, the card user displays the updated card based on the updated information.

[0110] exist Figure 2A In the method shown, the card user can construct a graphical node tree based on the card's layout code. When information is subsequently updated, the card user can trigger FMS to launch the card provider's application process, allowing the card provider to call the system API to retrieve the update information. The card provider can then send this update information to the card user via FMS, enabling the card user to update the information on the card based on this information.

[0111] In scenarios involving multiple cards, such as creating weather, clock, and calendar cards in a desktop application, the weather card, clock card, and calendar card can be designated as Card 1, Card 2, and Card 3, respectively. (See reference...) Figure 2B ,based on Figure 2A The method shown allows the card user to construct a graphical node tree for each card based on its layout code, and then display each card according to this tree. When the information for these multiple cards needs to be updated, the card user can trigger FMS to launch the application process of each card provider. The card provider then calls the system API to retrieve the updated card information, and the card user can update the multiple cards based on this information.

[0112] exist Figure 1A and Figure 2A In the card creation and display method shown, FMS needs to launch the card provider's application process each time the card information is updated, so that the card provider can obtain the updated information. Frequent launches of the application process can easily lead to high power consumption and low efficiency. Furthermore, in... Figure 1A In the method shown, a unified FRS service constructs the graphical node tree of all cards. The layout code of different cards runs in one FRS process, which makes it difficult to achieve permission isolation. Cards can only display information and update information, and cannot provide more interactive capabilities. The card information is limited.

[0113] Therefore, the embodiments of this application need to solve the following problems:

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

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

[0116] Regarding issues 1 and 2, in some embodiments, reference is made to Figure 3 Multiple card APIs can be pre-configured for FRS, and multiple virtual machines (VMs) can be created within FRS. Each VM can correspond to one card API, and each card API can correspond to one card provider. On one hand, in FRS, the layout code for cards from the same card provider runs in the same VM, while the layout code for cards from different card providers runs in different VMs. In this embodiment, the resources and states of different card providers are isolated through the runtime environment of the VMs. On the other hand, the card provider can update the card by calling the card API provided by FRS, which triggers FRS to directly call the system API to obtain update information. In this method, FRS directly calls the system API, which avoids frequently launching the application process of the card provider when updating card information, thereby reducing power consumption and improving card display efficiency.

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

[0118] In some embodiments, the virtual machine corresponding to the card provider may store the card provider's verification information, such as a token. When FRS calls the system API, it can provide the card provider's token to the corresponding system service. The system service can verify the card provider's token, and when the card provider's token verification is successful, the system service can send update information back to FRS.

[0119] In this embodiment, on the one hand, the card interface provided by FRS is separate from the system API. For an evolving operating system, this API separation can lead to architectural decay 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 vulnerable to attack, the security of the card provider's token is low.

[0120] To address the current problems, this application provides a card display method. Firstly, a virtual machine is created within the Functional Resource Controller (FRS), isolating the resources and states of different card providers through the virtual machine's runtime environment. Secondly, the token can be stored in the electronic device's system module, such as the Functional Management System (FMS), improving token security. Thirdly, when updating card information, this application allows the FRS to directly call the system API based on the card provider's token, avoiding frequent restarts of the card provider's application process, reducing power consumption, and improving card display efficiency.

[0121] Before introducing the card display method provided in the embodiments of this application, the structure of the electronic device will be first described:

[0122] Figure 4 This is a schematic diagram of another electronic device provided in an embodiment of this application. (Refer to...) Figure 4 The electronic device may include: a card user, a card provider, an FMS, an FRS, and an 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 Taking one card user and two card providers as an example, the two card providers are, for example, card provider 1 and card provider 2.

[0123] The card user is responsible for triggering card creation and displaying the card.

[0124] It should be understood that the card provider and card user can be applications in an electronic device, such as system applications or third-party applications. The following embodiments use a cycling application as the card provider 1, a navigation application as the card provider 2, and a desktop application as the card user for illustration.

[0125] Different card providers have different permissions, which can be understood as different card providers having the right to call different system APIs. Taking a cycling app with permission 1 and a navigation app with permission 2 as an example: Permission 1 can include location permission, network permission, and cross-device communication permission. Accordingly, the cycling app can use location permission to call the system API that provides location information to obtain the current location information of the electronic device. The cycling app can use network permission to call the system API that provides weather information to obtain the current weather information. The cycling app can use cross-device communication permission to call the system API that establishes communication with other electronic devices such as watches to obtain information such as the user's heart rate. Similarly, permission 2 can include location permission. Accordingly, the navigation app can use location permission to call the system API that provides location information to obtain the current location information of the electronic device.

[0126] In some embodiments, the permissions possessed by different card providers may be pre-configured. For example, the card provider's installation package may carry information related to the permissions possessed by the card provider.

[0127] In some embodiments, when a card provider is installed on an electronic device, the card provider can send information about its permissions to the ATMS, allowing the ATMS to determine the permissions of each card provider within the electronic device. In some embodiments, when the card provider is a system application, it can send information about its permissions to the ATMS when the electronic device is powered on or running, allowing the ATMS to determine the card provider's permissions.

[0128] In some examples, for the same card provider, the card provider may send information about its permissions to ATMS once. For instance, the card provider may send this information to ATMS when the electronic device is first powered on or when the card provider is first running. Subsequent power-ups or re-runs of the card provider may not require the card provider to send this information to ATMS.

[0129] In some embodiments, when the card provider updates, such as when the card provider upgrades its version, the card provider's permissions may change. Therefore, when the card provider updates, the card provider can resend the updated permission information to ATMS so that ATMS can determine the updated permission information.

[0130] In some embodiments, users can customize the permissions of the card provider. For example, users can customize the card provider's permissions within the Settings app. For example, when the card provider is first run after installation on an electronic device, it can request permissions, and users can customize certain permissions granted to the card provider. For instance, the card provider can request access to the electronic device's device information, contact information, and gallery information, etc.

[0131] In this embodiment, after the user customizes the card provider's permissions, the card provider can send relevant information about the permissions it has to ATMS so that ATMS can determine the card provider's permissions.

[0132] ATMS is a system service responsible for verifying the permissions of card providers. For example, ATMS can verify the permissions of a service or application based on an externally passed token.

[0133] In some embodiments, ATMS can provide a registration interface and an authentication interface. The authentication interface is responsible for verifying the card provider's permissions, while the registration interface is used for application or service registration verification information. Verification information can be, for example, a token or a password; the following embodiments use 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, it can call the ATMS registration interface to register its own token upon the first power-on of the electronic device or the first time the card provider is run on the electronic device. ATMS can store the card provider's token. Because the card provider can also send information about its permissions to ATMS, ATMS can store the card provider's token and its corresponding permissions.

[0135] In some embodiments, ATMS may include a mapping between the card provider's token and the card provider's permissions. For example, this mapping may include: at least one card provider's identifier, token, and permissions.

[0136] In some embodiments, when an electronic device creates a card for the first time, i.e., when FMS first initiates FRS, FRS can also call the ATMS registration interface to register its own token. In some embodiments, ATMS can store the FRS's token.

[0137] The specific functions of FMS, FRS, and ATMS can be found in the descriptions in the following embodiments.

[0138] The card display method provided in this application will be described below with reference to specific embodiments. These embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0139] The card creation process will be introduced below:

[0140] Figure 5A This is a flowchart illustrating an embodiment of a card display method provided in this application. (Refer to...) Figure 5A The card display method provided in this application embodiment may include:

[0141] S501, the card uses the direction of the FMS to send a card creation request.

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

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

[0144] In some embodiments, the card may correspond to a card provider; for example, a cycling card corresponds to a cycling app, and a weather card corresponds to a weather app.

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

[0146] In some embodiments of this application, the FMS can establish a connection with the card provider based on the card provider's identifier in the card creation request. The process of establishing the connection can be referred to the description in S102.

[0147] In some embodiments, once a card is created, the FMS can disconnect from the card provider. When the card user triggers the creation of another card from the same card provider, the FMS can reconnect to the card provider.

[0148] S503, the card provider sends the card provider's verification information to the FMS.

[0149] For example, the card provider's verification information, such as a token.

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

[0151] In step S504, FMS determines whether the card provider's verification information has been stored. If yes, proceed to step S506; otherwise, proceed to step S505 followed by step S506.

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

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

[0154] Taking the card provider's verification information as a token and the virtual machine's identifier as the thread's TID within the virtual machine as an example, FMS can store the mapping relationship between the card provider's token and the corresponding thread's TID within the virtual machine. This mapping relationship can be understood as a mapping relationship between token and TID. For example, the mapping relationship between token and TID can be stored in tabular form, such as a key-value table where the key is TID and the value is token. The process of FMS storing the mapping relationship between token and TID can be referred to the relevant descriptions in S508-S509.

[0155] In this embodiment, in response to verification information from the card provider, the FMS can query the mapping relationship between the verification information and the virtual machine identifier to determine whether the mapping relationship already contains the card provider's verification information. If the mapping relationship contains the card provider's verification information, the FMS can determine that the card provider has created cards, and the FRS contains the virtual machine corresponding to that card provider. If the mapping relationship does not contain the card provider's verification information, the FMS can determine that the card provider has not created any cards, or that the card provider has had all its cards deleted, and the FRS does not contain the virtual machine corresponding to that card provider.

[0156] S505, verification information from the FMS storage card provider.

[0157] Because the mapping between verification information and virtual machine identifiers does not include the card provider's verification information, FMS can store the card provider's verification information.

[0158] S506, FMS sends rendering commands to FRS.

[0159] Rendering instructions are used to instruct FRS to construct the graphical node tree of the cards. In some embodiments, rendering instructions may include the identifier of the card provider and the identifier of the card.

[0160] S507: 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.

[0161] When a card is created, FRS can create a virtual machine corresponding to the card provider. FRS can also store the virtual machines corresponding to the card providers for already created cards. In response to rendering commands from FMS, FRS can query whether the virtual machine corresponding to the card provider is already stored in FRS based on the card provider's identifier in the rendering command.

[0162] When the FRS does not store the virtual machine corresponding to the card provider, the FRS can create the virtual machine corresponding to the card provider.

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

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

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

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

[0167] In response to the identifier of the virtual machine corresponding to the card provider from FRS, FMS can store the card provider's verification information and the identifier of the virtual machine corresponding to the card provider. For example, FMS can add the TID of the thread in the virtual machine corresponding to the card provider, and the card provider's token, to the TID and token mapping relationship.

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

[0169] S510: If the virtual machine corresponding to the card provider is already stored in FRS, execute S511 directly.

[0170] The FRS can respond to rendering commands from the FMS and, based on the card provider's identifier in the rendering command, query whether the FRS already stores the virtual machine corresponding to the card provider. If the FRS already stores the virtual machine corresponding to the card provider, it can directly execute S511.

[0171] S511, FRS constructs a graphical node tree based on the card layout code.

[0172] In this embodiment, since different cards correspond to different layout codes, the FRS can obtain the layout code of a card based on its identifier, and the FRS can construct a graphical node tree based on the layout code of the card. The process of the FRS obtaining the layout code of the card can be referred to the description in S104.

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

[0174] S513, the card user displays the card according to the graphical node tree.

[0175] S511-S512 can be referred to in the descriptions in S104-S106.

[0176] Figure 5B This is a schematic diagram illustrating a card creation process provided in an embodiment of this application. (Refer to...) Figure 5B , Figure 5BTaking the example of a card user creating a card for card provider 1 and a card provider 2 respectively.

[0177] Taking card provider 1's card as card 1 as an example, when a card user creates card 1, the card user can send a card creation request to FMS. This card creation request can include the identifier of card provider 1 and the identifier of card 1. In response to the card creation request, FMS can establish a connection with card provider 1 based on card provider 1's identifier, 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 can store card provider 1's token and send a rendering instruction to FRS. This rendering instruction can include the identifier of card provider 1 and the identifier of card 1. Based on the identifier of card provider 1 in the rendering instruction, FRS can determine that it does not contain the virtual machine corresponding to card provider 1. FRS can then create the 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 In this context, VM1 represents the virtual machine corresponding to card provider 1.

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

[0180] Taking card provider 2 as an example, when a card user creates card 2, the card user can send a card creation request to FMS. This card creation request can include the identifier of card provider 2 and the identifier of card 2. In response to the card creation request, FMS can establish a connection with card provider 2 based on its identifier, and card provider 2 can send its token to FMS. Assume that card provider 2 has already created cards, meaning that FMS already stores the TID of the thread in the virtual machine corresponding to card provider 2, as well as card provider 2's token. Figure 5B VM2 represents the virtual machine corresponding to card provider 2.

[0181] FMS can send rendering instructions to FRS. These instructions can include the identifier of card provider 2 and the identifier of card 2. Based on the identifier of card provider 2 in the rendering instructions, FRS can determine that it contains the virtual machine corresponding to card provider 2. Therefore, FRS can construct a graphical node tree based on the layout code of card 2 and send the graphical node tree to the card user. The card user can then display card 2 based on the graphical node tree.

[0182] In this embodiment, FRS can create a corresponding virtual machine for each card provider. By isolating the resources of different card providers through the virtual machine's runtime environment, card permission isolation can be achieved. Furthermore, each card provider and FRS can call the ATMS registration interface to register their own verification information. FMS can also store the mapping relationship between the card provider's verification information and the identifier of the corresponding virtual machine. On one hand, storing the card provider's verification information in FMS improves the security of the verification information; on the other hand, the mapping relationship between the card provider's verification information and the identifier of the corresponding virtual machine in FMS can also assist in enabling FRS to directly call system APIs.

[0183] In some embodiments, Figure 5A During the card creation process, the card provider can send a card information retrieval request to the target system service to request the card's information. In response to this request, the target system service can send the card information back to the card provider. For example, the card provider can call a system API to send the card information retrieval request to the target system service.

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

[0185] In some embodiments, S512 can be replaced by: FRS sending the graphical node tree and card information to the card user. Correspondingly, S513 can be replaced by: the card user displaying the card based on the graphical node tree and the card information.

[0186] In some embodiments, the card user can also update the information on the card. The following is in conjunction with... Figure 6A This describes the process by which a card user updates information on a card. In some embodiments, refer to... Figure 6A Following S513, it may also include:

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

[0188] In this embodiment, when updating information on the card, it is not necessary to launch the card provider's application process or call the system API; instead, 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 that system API, which can be referred to as the target system service. This can be understood as the FRS sending a card information update request to the target system service to request updated card information.

[0189] The target system service is used to provide card information. For example, in a cycling application, the cycling card may include location information, and the target system service can be a system service that provides location information, such as the Global Positioning System (GPS) service. Specifically, FRS can send a card information update request to the GPS system service to request a call to the GPS system service's system API to obtain updated location information.

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

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

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

[0193] In some embodiments, when the FRS calls the system API, the FRS can act as the caller. In response to the card information update request, the target system service can call the authentication interface of ATMS and 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 card provider's permissions.

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

[0195] Because FRS has pre-registered its verification information using ATMS's registration interface, in this embodiment, ATMS will not use the FRS verification information to verify the card provider's permissions. Instead, it will send the identifier of the virtual machine corresponding to the card provider to FMS. Since FMS stores a mapping between the card provider's verification information and the identifier of the virtual machine corresponding to the card provider, FMS can query the card provider's verification information mapped to the identifier of the virtual machine corresponding to the card provider based on this mapping. FMS can then send the card provider's verification information to ATMS.

[0196] For example, ATMS can call the callback interface of FMS, taking the identifier of the virtual machine corresponding to the card provider as an input parameter. After receiving the callback from ATMS, FMS queries the card provider's verification information in the mapping relationship between verification information and virtual machine identifiers using the identifier of the virtual machine corresponding to the card provider, and returns the retrieved card provider's verification information to ATMS.

[0197] Because ATMS stores a mapping relationship between the card provider's verification information and its permissions, ATMS can verify the card provider's permissions based on the verification information returned by FMS and this mapping relationship. Specifically, ATMS verifies whether the card provider has permission to call system APIs. In some embodiments, the mapping relationship between the card provider's verification information and its permissions can be referred to as a second mapping relationship.

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

[0199] ATMS verifies the card provider's permissions. If it determines the card provider has permission to call system APIs, and the permission verification passes, ATMS can send a verification success message to the target system service. In some embodiments, the card provider's permission to call system APIs can also be understood as the card provider having permission to call or use the target system service.

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

[0201] Upon receiving the verification success message, the target system service can determine that the card provider has the authority to call the system API. Therefore, the target system service can return the card update information to the FRS, indicating that the FRS has successfully called the system API to obtain the card update information.

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

[0203] S607, the card user displays the updated card based on the card's update information.

[0204] S608: When the card provider's authorization 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 FRS.

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

[0207] For example, refer to Figure 6B Taking FRS as an example, which includes VM1 corresponding to card provider 1 and VM2 corresponding to card provider 2, the following explains the process of FRS directly calling the system API, using card provider 1 as an example:

[0208] FRS can call system APIs, and card information update requests from FRS first reach the system service. These requests can include the FRS token and the TID of the thread in VM1. In response, the system service can call the ATMS authentication interface, simultaneously passing the caller's FRS token and the TID of the thread in VM1 to ATMS; that is, the system service sends a verification request to ATMS. ATMS calls the FMS callback interface, passing the TID of the thread in VM1 as an input parameter. Upon receiving the callback from ATMS, FMS uses the TID of the thread in VM1 to look up the token mapped to that thread's TID in the token-TID mapping relationship and returns the retrieved token to ATMS.

[0209] ATMS stores a mapping between tokens and permissions. Responding to a token from FMS, ATMS can determine the permissions associated with that token based on this mapping, thus determining whether card provider 1 has the authority to call the system API. Specifically, when 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 then send updated card information back to FRS.

[0210] In some embodiments, both successful and failed verification messages can be referred to as verification results.

[0211] In this embodiment, the FMS stores a mapping relationship between the card provider's verification information and the identifier of the virtual machine corresponding to the card provider. This improves the security of the verification information and allows the FMS to provide the ATMS with the card provider's verification information during card verification, facilitating smooth permission verification. In this embodiment, the ATMS can verify the card provider's permissions based on the card provider's verification information. When the permission verification passes, the FRS is allowed to directly call the system API. This not only achieves permission verification for the card provider and reduces power consumption but also achieves the goal of isolating card provider permissions.

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

[0213] In some embodiments, refer to Figure 5A The card creation process shown in S512 involves the FRS constructing a graphical node tree based on the card's layout code. The FRS can also send a card information retrieval request to the target system service. This request requests card information. In response, the target system service verifies the card provider's permissions. If the permissions are verified, the target system service sends the card information to the FRS. The process of the target system service verifying the card provider's permissions can be found in [reference needed]. Figure 6A The relevant description in the document.

[0214] For example, FRS can not only construct a graphical node tree based on the card's layout code, but it can also call system APIs to obtain card information from target system services so that card users can display the information in the card when displaying the card.

[0215] In some embodiments, S601-S607 can be executed after S512, and correspondingly, S513 can be replaced by: The card user can display the card according to the graphical node tree and the card information.

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

[0217] The card display method provided in this application embodiment is described below in conjunction with specific application scenarios:

[0218] Taking a mobile phone as an example, and specifically a cycling app, many users are accustomed to mounting their phones on their bicycle frames while cycling outdoors to view real-time cycling information, such as mileage, speed, and heart rate. Currently, users can only view this information by opening the cycling app. If a user also needs navigation, since the navigation app and cycling app cannot be displayed simultaneously in the foreground, the user must switch the navigation app to the background and receive navigation information via voice, which is less intuitive than displaying navigation information in the foreground. The card display method provided in this application allows the creation of cycling cards and navigation cards on the desktop, enabling users to view both cycling and navigation information on a single interface.

[0219] Figure 8 This paper presents a multi-card combination scheme where different card providers have different permissions. In this embodiment, based on the verification information of each card provider and their corresponding virtual machines, permission isolation between card providers can be achieved. This allows cards to securely carry more sensitive permission-based services, enriching the information on the cards, and allowing users to obtain the desired information simply by using the card without opening the application.

[0220] For example, if a cycling application has location permissions, network permissions, and cross-device communication permissions, then using the card creation and display method provided in this application, a user can create a cycling card on the desktop of an electronic device, and the cycling card can inherit the permissions of the cycling application. For example, the Free Response System (FRS) in the electronic device can directly call the system API corresponding to the location permission to obtain current location information and trip 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 information such as the user's heart rate. (See also...) Figure 8 The user can display a cycling card, which may include location information, trip data, weather information, and the user's heart rate, among other things.

[0221] Similarly, users can create navigation cards on the desktop of their electronic devices, and these navigation cards can inherit the permissions of navigation applications. For example, the FRS in an electronic device can directly call the system API corresponding to the navigation permissions to obtain current location information and navigation information, etc. (See reference...) Figure 8 The user can display a navigation card, which can include the current location information and navigation information.

[0222] In this embodiment, a user can create multiple cards on one interface of an electronic device. Based on these multiple cards, the user can obtain rich information without opening a specific application, which can improve the user experience.

[0223] Similarly, users can add other cards according to their own preferences. For example, see... Figure 8 For example, radio cards can be used to listen to radio stations in real time, and logistics cards can be used to track upcoming deliveries. In this embodiment, on the one hand, all cards run within the FRS process, eliminating the need to launch multiple application processes and enabling resource isolation based on a virtual machine. This reduces power consumption while enriching card information. On the other hand, when updating card information, FRS can directly call system APIs without frequently launching the card provider's application process, reducing power consumption and increasing the speed at which FRS acquires card information, thus improving card display efficiency.

[0224] Figure 9 This is a flowchart illustrating another card display method provided in an embodiment of this application. Figure 9 This document describes a method for card users to update their cards. The first application can be understood as the card user, and the second application as the card provider. (See reference...) Figure 9 In some embodiments, the card display method provided in this application may include:

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

[0226] The process of the first application displaying the card of the second application can be referred to the relevant description in the above embodiments.

[0227] In this application, the cards displayed by the first application correspond to those displayed by the second application. For example, the cards displayed by the first application may be cycling cards, which correspond to the second application "Cycling Application". Similarly, the cards displayed by the first application may be weather cards, which correspond 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 this embodiment, the Card Rendering Service (FRS) can directly call the system API without frequently launching the application process of the second application. The second application calling the system API can reduce power consumption and improve the speed at which the FRS obtains updated card information, thereby improving card display efficiency.

[0230] In some embodiments, the card rendering service may periodically or intermittently call the system API to send card information update requests to the target system service.

[0231] S903, the target system service verifies the permissions 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 a card information update request, the target system service can determine the permissions of the second application based on this mapping relationship to verify the permissions of the second application and determine whether the second application has permission to call the system API.

[0233] In some embodiments, to improve the verification security of the second application, the electronic device may set up an authentication service for verifying the permissions of the second application. The card rendering service includes a virtual machine corresponding to the second application, which is created by the card rendering service for the second application. For example, the card rendering service may include at least one virtual machine corresponding to each second application, with one virtual machine for each second application.

[0234] The card information update request includes verification information from the card rendering service and the identifier of the virtual machine. In this embodiment, in response to the card information update request, the target system service may send a verification request to the authentication service. The verification request includes verification information from 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 to send a verification request to the authentication service.

[0235] The authentication service responds to the verification request and can 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.

[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 based on the mapping relationship.

[0237] In some embodiments, to improve the authentication security of the second application, the electronic device may set up 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 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, taking the virtual machine identifier as an input parameter. Responding to the callback of the authentication service, the card management service can return the verification information of the second application corresponding to the virtual machine identifier to the authentication service according to the first mapping relationship. The specific process can be found in [reference needed]. Figure 6A The description in the text.

[0238] In this embodiment, 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. 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 permission to call system APIs based on the verification information of the second application and the second mapping relationship.

[0239] S904, in response to the successful permission verification of the second application, the target system service sends the card update information to the card rendering service.

[0240] In some embodiments, when a second application has permission to call a system API, the authentication service determines that the second application's permission verification has passed, and the authentication service may send a verification success message to the target system service. Upon receiving the verification success message from the authentication service, the target system service can determine that the second application's permission verification has passed, and the target system service sends 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 verification of the second application has failed, and the authentication service sends a verification failure message to the target system service. Upon receiving the verification failure message from the authentication service, the target system service can determine that the permission verification of the second application has failed, and the target system service can send a call failure message to the card rendering service.

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

[0243] S906, the first application displays the updated card based on the card's update information.

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

[0245] It is understood that the embodiments of this application have the same technical effects as the embodiments described above, and the relevant descriptions in the embodiments above can be referred to.

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

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

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

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

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

[0251] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0252] The term "multiple" in this document refers to two or more. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, the character " / " in this document generally indicates an "or" relationship between the preceding and following related objects; in formulas, " / " indicates a "division" relationship. Additionally, it should be understood that in the description of this application, words such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order.

[0253] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

[0254] It is understood that, in the embodiments of this application, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

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 card rendering service is configured with multiple card system application programming interfaces (APIs), and each virtual machine in the card rendering service corresponds to one API, and each API corresponds to a card provider. The method includes: The first application displays the card of the second application; The card rendering service sends a card information update request to the target system service, the card information update request being used to request updated information for the card; The target system service verifies the permissions of the second application; In response to the successful permission verification of the second application, the target system service sends the card update information to the card rendering service; The card rendering service sends the card update information to the first application; The first application displays the updated card based on the card's update information.

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 the verification information of the card rendering service and the identifier of the virtual machine; the electronic device also includes an authentication service. The target system service verifies the permissions of the second application, including: The target system service sends a verification request to the authentication service. The verification request includes the verification information of the card rendering service and the identifier of the virtual machine. The authentication service obtains the verification information of the second application based on the verification information of the card rendering service and the identifier of the virtual machine; The authentication service verifies the permissions of the second application based on 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, which includes 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 to send the verification request to the authentication service; The authentication service obtains the verification information of the second application based on 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 based on the verification information of the card rendering service; The card management service sends the verification information of the second application to the authentication service based on 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: the verification information of the second application and a second mapping relationship between the permissions of the second application; The authentication service verifies the permissions of the second application based on the verification information of the second application, including: The authentication service determines whether the second application has permission to call the target system service based on 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 permission to call the target system service, the method further includes: When the second application has permission to invoke 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 permission to call the target system service, the authentication service determines that the permission verification of the second application has failed and sends a verification 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 claim 3 or 5, characterized in that, Before the first application displays the card of the second application, it also includes: The first application sends a card creation request to the card management service. The card creation request includes the identifier of the second application and the 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 sends its verification information to the card management service; When the card management service has stored the verification information of the second application, the card management service sends a rendering instruction to the card rendering service. The rendering instruction instructs the card rendering service to obtain the graphical node tree of the card; or... When the card management service does not store the verification information of the second application, 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 process further includes: When the card rendering service determines that the virtual machine is included in the card rendering service based on the identifier of the second application, it obtains the layout code of the card based on the card's identifier. The card rendering service obtains the graphic node tree based on the layout code of the card.

8. The method according to claim 7, characterized in that, The method further includes: If the card rendering service determines, based on the identifier of the second application, that the card rendering service does not include the virtual machine, then it creates the virtual machine. The card rendering service obtains the layout code of the card based on the card's identifier; The card rendering service obtains the graphic node tree based on 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 includes: The second application sends a card information retrieval request to the target system service, the card information retrieval request being used to request information about the card; 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 includes: The card rendering service sends a card information retrieval request to the target system service, and the card information retrieval request is used to request information about the card. The target system service verifies the permissions of the second application; In response to the successful permission verification of the second application, the target system service sends the card information to the card rendering service.

11. The method according to claim 10, characterized in that, After obtaining the card information, the card rendering service also includes: The card rendering service sends the graphics node tree and the card information to the first application; The first application displays a card from the second application, including: The first application displays the card based on the graphical node tree and the card information.

12. The method according to any one of claims 3, 5, 7-8, characterized in that, The method further includes: 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, 5, 7-8, characterized in that, The verification information for the second application is a token, the verification information for 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 computer instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed, implement the method as described in any one of claims 1-13.

Images